Re: [Idr] [spring] Error Handling for BGP-LS with Segment Routing

[Alvaro Retana <[e-mail]>]

On December 18, 2018 at 6:10:21 PM, [e-mail] (
[e-mail]) wrote:

Bruno:

Hi!


...

1) shouldn’t BGP-LS error handling be also discussed in the LSVR WG?

https://tools.ietf.org/html/draft-ietf-lsvr-bgp-spf-03#section-5.7 does not
seem to cover this.

And this document was under WGLC till yesterday.

Yes, good point.

I wanted to focus on SR’s use, but I think you’re right to point out that
other applications may have the same needs.  I think/hope that people on
the lsvr list are also on the idr list (at least), so I’ll forward a
pointer to this thread just in case.


2) Regarding BGP-LS error handling, it’s not clear to me that “treat as
withdraw” would be “safer” than “Attribute Discard”. “Session reset” is
safer from an inconsistency standpoint but definitely also “has a direct
effect on how traffic is forwarded in the network” and a sever one.

[Not sure about the ending “…and a sever one”.]

I agree.  I don’t want to rehash the discussion from rfc7606 about the
types of approached and whether there should be more or not (or what those
could be)…. I’m just pointing out that I think the current approach is not
the right one for all applications.

3)

> The BGP-LS extensions for SR (e.g.
draft-ietf-idr-bgp-ls-segment-routing-ext) are, as explained in that draft,
used so that "an external component (e.g., a controller) then can collect
SR information from across an SR domain and construct the end-to-end path
(with its associated SIDs) that need to be applied to an incoming packet to
achieve the desired end-to-end forwarding."



> To me, that obviously implies that use of BGP-LS for SR has a direct
effect on how traffic is forwarded in the network.  Does any one see it
differently?



a) IMHO that implication would be the same without SR, e.g., with RSVP-TE.
In fact, the effect on how traffic is forwarded is coming from the PCE
computation using partial/incorrect topology information, not how the
forwarding is enforced.

b) IMHO RFC7606 was more concerned about forwarding loops/black holing
–especially for IBGP-, rather than changing the path of the traffic.
(as ““treat as withdraw “ or “sessions reset” would also have “a
direct effect on how traffic is forwarded in the network”.) Note that
the latter quote is not from RFC760 which uses the terms  “no effect
on route selection or installation” which is a bit different.

Interpreting the difference between “a direct effect on how traffic is
forwarded in the network” and  “no effect on route selection or
installation” is part of the reason this topic is not straight forward.

To me, in the BGP-LS+SR context, because the controller *installs* the
source route at the ingress router, the two phrases apply.

However, other interpretations are possible…which is one of the reasons for
this thread.  For example, during the rfc7752 discussion, a point was made
that the controller (being at the receiving end of the BGP session) would
not have to worry about the effects of attribute discard because any loss
of information would not have an effect on how it (the controller) selected
or installed routes.  That argument is not completely flawed (the
controller does not use the BGP-LS itself for routing), but (my personal
opinion) is that the use of the information (in later programming the
network) is what is important.


c) Coming back to SR, quickly looking at the ToC, the discard of the
SID simply means that the SID can”t be used by the SR source/ingress
node. The discard of the SR node attribute means that the node can’t
be used to forward a global segment. The use of flex-algo is a bit
more touchy as discarding the support for a flex algo will change the
routing along this flex algo. But only from the perspective of the
BGP-LS consumer, so this would not create forwarding loops/black hole,
but only a non expected routing path.

Which ToC?

You’re right…but only if the information is discarded when it was initially
learned.  If the error occurs later, when the information was changing for
example, there is the possibility that the controller will want to use a
node that shouldn’t be used any more….or be calculating
not-the-best-routes.  Sub-optimal routes are not great and may not matter
too much (compared to loops, for example), but some users may have specific
business objectives (application performance, for instance) tied to the
definition of the paths…it will be important to them.


4)  I haven’t checked but it’s not clear to me that IS-IS has a perfect
(better?) error handling.

If you want to discuss this, please do it in the lsr WG. :-)

...

5) BGP-LS and IS-IS have chosen a different granularity to advertise the
LSDB (per link/node vs oer LSP) which very likely will result in a
different error handling hence a different vision of the topology. This
looks like day 1 design choice for BGP-LS, so difficult to address.

Yes…

Thanks!

Alvaro.