Alvaro, The proposed changes seem reasonable, but I want to make sure that I understand the path forward clearly.
My understanding is that if we were to reach a future where draft-ietf-idr-bgp-extended-messages is widely deployed, then the BGP speaker's maximum message size will just be larger (than it is today) and as a result we avoid reaching the point where Section 9.2 (of 4271) guidance is needed. Is my understanding correct? (I want to make sure that future implementers will find our text clear and we won't need to revise this spec to add clarity if extended messages ends up in widespread use.) - Matt Lepinski On Tue, Apr 4, 2017 at 12:15 PM, Alvaro Retana (aretana) <aret...@cisco.com> wrote: > Dear sidr WG: > > > > As has been discussed in the mailing list and at the sidrops meeting last > week in Chicago, there is interest to not have the BGPsec document > (draft-ietf-sidr-bgpsec-protocol) depend normatively on the Extended > Messages work (draft-ietf-idr-bgp-extended-messages). Based on that > discussion, Sriram and I have come up with proposed diffs – please see the > attachment (-23 has not been posted yet). > > > > To summarize, the changes are: (1) remove mention/references of/to > draft-ietf-idr-bgp-extended-messages, and (2) add the following text in > Section 4.1. (General Guidance): > > > > All BGPsec update messages MUST conform to BGP's maximum message > > size. If the resulting message exceeds the maximum message size, > > then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be > > followed. > > > > [For easier reference, I put the relevant text from 9.2 below.] > > > > The result is then that draft-ietf-sidr-bgpsec-protocol doesn’t depend on > draft-ietf-idr-bgp-extended-messages. Instead, when referring to the size > of the messages, it depends on rfc4271. > > > > Please let me know if you have any concerns. I will wait a week before > proceeding. > > > > Given that this document has already been approved by the IESG, the process > going forward is: > > > > - consult the WG (this thread) > > - inform the IESG of the intent > > - inform the IETF (i...@ietf.org) of the changes > > - publish an updated draft > > - continue the publication process > > > > Each step may, obviously, require additional discussion and could result in > changes to the current plan. > > > > Thanks!! > > > > Alvaro. > > > > > > > > > > https://tools.ietf.org/html/rfc4271#section-9.2 > > > > 9.2. Update-Send Process > > > > … > > If, due to the limits on the maximum size of an UPDATE message (see > > Section 4), a single route doesn't fit into the message, the BGP > > speaker MUST not advertise the route to its peers and MAY choose to > > log an error locally. > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
