Re: [sidr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Matt,

I think slide 4 of this presentation (SIDROPS, IETF 98) addresses your questions/concerns: 
https://www.ietf.org/proceedings/98/slides/slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf 

Please take a look at slide 3 also (BGP & BGPsec update sizes). 

Also, Alvaro's post from March 15 should be helpful:  
https://www.ietf.org/mail-archive/web/sidr/current/msg08506.html 

Sriram

-----Original Message-----
From: Matthew Lepinski [mailto:[e-mail]] 
Sent: Tuesday, April 04, 2017 12:45 PM
To: Alvaro Retana (aretana) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

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) <[e-mail]> 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 ([e-mail]) 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.
>
>