On Sun, Dec 30, 2012 at 4:34 PM, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > There are a couple of easy ways to ensure the WITHDRAW is not missed: > - Pack all the WITHDRAW stuff at the start > - Require that no UPDATE be sent in the same MESSAGE as a WITHDRAW, and > preferably limit WITHDRAW to one AFI/SAFI per MESSAGE
The change you are proposing is sensible and has minimal cost to the control-plane CPU. BGP already can only have one, two, or three AFI/SAFI per Message. The reason it's "one, two, or three" is there can be native NLRI and MP-NLRI in one Message. You are not allowed to send more than one Attribute of the same Type Code in a BGP Message. There can't be two MP_REACH_NLRI or two MP_UNREACH_NLRI. The rule about one attribute per type code is kind of buried in RFC4271 section 6.3 paragraph 14. I imagine not everyone is aware of this because it really is not written into the spec in a way that it jumps out at you! Here is how this plus MP-BGP combine to allow up to three NLRI in the same Message: 1) native NLRI which are either reachable or withdrawn 2) NLRI inside an MP_REACH_NLRI Attribute 3) NLRI inside an MP_UNREACH_NLRI Attribute All three of those could possibly have distinct AFI/SAFI today. But it's not like it is possible to have NLRIs for 10 different AFIs in one Message today. I'm sure this discussion is related to draft-ietf-idr-error-handling. This draft does not call for a BGP Capability Code. It needs one if it expects the neighbor to behave in a certain way which differs from existing BGP requirements. I have posted some discussion about this on the IDR list recently but I do not read GROW. -- Jeff S Wheeler <j...@inconcepts.biz> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
