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

[Robert Raszuk <[e-mail]>]

Hi Alvaro,

What comes as #1 question to your points is a comparison of SR controller
with regular BGP RR.

I think it is safe to assume that error handling on SR controller would be
no more aggressive then on RRs. So if there is error the updates may be
dropped on the RRs itself, logged and proper NOC alarm generated.

IMO this is no different regardless if you use SR with BGP-LS or just plane
regular BGP routing.

So unless your goal here is to point out the deficiency of BGP error
handling RFC I am not sure what is so specific to BGP-LS and SR.

Yes I am not big proponent of using BGP-LS all together, but not because it
has inherited BGP error handling.

Regards,
R.



On Tue, Dec 18, 2018 at 10:09 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
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>