[Lsvr] Fwd: Error Handling for BGP-LS with Segment Routing

[Alvaro Retana <[e-mail]>]

Hi!

I sent this message to the idr and spring WGs yesterday.  It was suggested
that this WG should be interested in the topic as well.  I’m hoping that
most of you are also subscribed to the idr list; if possible, please reply
to the original thread:
https://mailarchive.ietf.org/arch/msg/idr/0qsjuVaEhroKInHZMohP6HnsWd8

Thanks!

Alvaro.

On December 18, 2018 at 4:09:07 PM, Alvaro Retana ([e-mail])
wrote:

Dear idr and spring WGs:

tl;dr  I don't think that BGP-LS, with error handling as specified
("attribute discard"), can provide the robustness that an application (like
SR), with direct impact on the forwarding in the network, needs.  [Jump to
the bottom for discussion.]


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?


The error handling mechanism specified in rfc7752 is "attribute discard"
[rfc7606].  If an error is detected, then the information in the controller
may be, at best, incomplete, but it could also be out of date...resulting
in "segment routes" that don't follow the best available path or that may
even end in a black hole.

It seems clear to me that this is one of the cases that rfc7606 warned
about:

   o  Attribute discard: In this approach, the malformed attribute MUST
      be discarded and the UPDATE message continues to be processed.
      This approach MUST NOT be used except in the case of an attribute
      that has no effect on route selection or installation.

      ...
   For any malformed attribute that is handled by the "attribute
   discard" instead of the "treat-as-withdraw" approach, it is critical
   to consider the potential impact of doing so.  In particular, if the
   attribute in question has or may have an effect on route selection or
   installation, the presumption is that discarding it is unsafe unless
   careful analysis proves otherwise.  The analysis should take into
   account the tradeoff between preserving connectivity and potential
   side effects.


There was a related discussion as a result of my AD review of
draft-ietf-idr-ls-distribution (= rfc7606) [1][2].  At that time (2015),
the consensus on the list was (paraphrasing): if there's a malformed
attribute we won't be able to recover, but that's ok because BGP-LS is
"purely application-level data that has no immediate corresponding
forwarding state impact", and there won't be an impact on critical AFI/SAFI
for network operations.   No one else argued against that...so I ended up
in the rough...

I think the situation has now changed because BGP-LS is carrying SR
information that is used to define paths in the network -- even if
isolation exists, as described in rfc7752:

                 ...    Furthermore, it is anticipated that
   distribution of this NLRI will be handled by dedicated route
   reflectors providing a level of isolation and fault containment
   between different NLRI types.

...the BGP-LS information could still be incomplete, stale, etc..


After all that...  I don't think that BGP-LS, with error handling as
specified ("attribute discard"), can provide the robustness that an
application (like SR), with direct impact on the forwarding in the network,
needs.

What now?  I see several potential paths forward (there are probably more):

(1) "fix" BGP-LS to mandate (MUST) isolation and change the error handling
approach

(2) change the error handling approach...maybe just when used with SR

(3) the controller should only use the SR information received from routing
protocols (IGP/BGP, e.g. draft-ietf-idr-bgp-prefix-sid)

(4) ..??


I didn't find a specific discussion about this topic in the archive...but I
may have missed it in between other related ones.  If I did, please point
me to it.

Thoughts/ideas/comments?

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/FomvQV2DqjaaRiAcLYLn3LcIdYM
[2] https://mailarchive.ietf.org/arch/msg/idr/wbPNQ-HM2NeR75gR2Or948J9o1I