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

[Rob Shakir <[e-mail]>]

The alternative approach is to have an "Operational Considerations" section
of draft-ietf-idr-bgp-ls-segment-routing-ext that simply points out this
consideration. i.e., something like:

"Since the error handling approach defined in RFC7752 specifies 'attribute
discard' as the error handling mechanism for BGP-LS, systems implemented
using BGP-LS for discovery of topological attributes used for path
calculation MUST consider their mode of operation based on incomplete data
being received (due to attribute discard). If an assumption of strong
consistency between the BGP-LS receiver, and the network's topology is
made, system designers and operators SHOULD consider means to detect
erroneous attributes being discarded on a session and act accordingly."

Taking this approach doesn't say "hey, let's change this", and also doesn't
say "here's what the system should do", it just makes sure designers and
operators are aware of the consideration. That said, this is rather
implementation specific.

r.

On Fri, Jan 4, 2019 at 11:39 AM Alvaro Retana <[e-mail]>
wrote:

> On January 3, 2019 at 5:40:23 PM, Rob Shakir ([e-mail]) wrote:
>
> Describing these compromises is, of course, a good idea. However, it's not
> clear where this description would go -- we don't really have a document
> that describes this overall system and how it might be implemented today
> <http://airmail.calendar/2019-01-04%2012:00:00%20EST>.
>
>
> Right…
>
> I started reviewing the documents with BGP-LS extensions for SR…starting
> with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-LS
> extensions document to be sent for Publication where the application is
> explicitly to "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”.  All other BGP-LS extension documents have in
> general followed the “informative” tone of rfc7752.
>
> I don’t necessarily think that the description of the system belongs
> there…but there’s no other place to put it, at least not currently.  The SR
> Problem Statement (rfc7855) and the SR Architecture (rfc8402) both just
> make general statements about the need to support centralized and hybrid
> (and distributed, of course) control planes — they don’t go into more
> specifics…
>
> …
>
> Alvaro.
>