On January 4, 2019 at 3:48:38 PM, Rob Shakir ([email protected]) wrote: 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:
We would need something like it in every bgp-ls-sr draft…or a pointer back to draft-ietf-idr-bgp-ls-segment-routing-ext... "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. [This is probably not the right place to wordsmith, but I don’t know how “MUST/SHOULD consider” can be normatively enforced.] Because it is implementation/deployment specific, some examples of the cases where there could be more (or less) potential issues would be ideal. As Robert’s example: "In my view SR controller is mainly used as optimization not as critical element - well at least in the deployment models I would personally recommend to use.” This last part could end up making the document significantly longer…and it doesn’t really give me a warm fuzzy feeling adding it after WGLC…to an idr document...and without it being properly reviewed by the spring WG. But these are details we can take care of as we move forward [*]. Thanks! Alvaro. [*] I haven’t finished my AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
