Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

["Susan Hares" <[e-mail]>]

Alvaro:

 

Just to let you know that the text below:

 

“A peer which does not advertise this capability MUST NOT send BGP                                  

   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

 

was added due to comments on the IDR WG list from reviewers and operators.   

 

The peer is a “BGP peer” and it was debated on list that since this alters RFC4271 that this text was appropriate to indicate how BGP peers (which are not supporting Extended Messages” .     

 

Sue 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Wednesday, July 31, 2019 8:20 AM
To: Enke Chen (enkechen); Randy Bush
Cc: Mirja Kühlewind via Datatracker; [e-mail]; [e-mail]; The IESG; [e-mail]
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

 

On July 30, 2019 at 9:53:36 PM, Enke Chen (enkechen) ([e-mail]) wrote:

 

Enke:

 

Hi!

 

Here is a patch that would clarify the capability definition, the issue that I brought up before. 
It also include changing "BGP listener" to "BGP speaker" in two places. 

I looked at the changes and they look good tome.  I think that generalizing to “speaker” does help.

Thanks!!

Alvaro.

 

 

*** bgp-large-msg-34.txt.orig  <http://airmail.calendar/2019-07-30%2018:24:32%20GMT-4> Tue Jul 30 18:24:32 2019 
--- bgp-large-msg-34.txt  <http://airmail.calendar/2019-07-30%2018:34:07%20GMT-4> Tue Jul 30 18:34:07 2019 
*************** Internet-Draft Extended Message sup 
*** 120,148 **** 
defined with Capability code 6 and Capability length 0. 

To advertise the BGP Extended Message Capability to a peer, a BGP 
speaker uses BGP Capabilities Advertisement [RFC5492]. By 
advertising the BGP Extended Message Capability to a peer, a BGP 
! speaker conveys that it is able to send, receive, and properly 
handle, see Section 4, BGP Extended Messages. 

- A peer which does not advertise this capability MUST NOT send BGP 
- Extended Messages, and BGP Extended Messages MUST NOT be sent to it. 
- 
Peers that wish to use the BGP Extended Message capability MUST 
support Error Handling for BGP UPDATE Messages per [RFC7606]. 

4. Operation 

The Extended Message Capability applies to all messages except for 
the OPEN and KEEPALIVE messages. The former exception is to reduce 
the complexity of providing backward compatibility. 

! A BGP speaker that is capable of sending and receiving BGP Extended 
Messages SHOULD advertise the BGP Extended Message Capability to its 
peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker 
! MAY send Extended Messages to a peer if the Extended Message 
Capability was received from that peer. 

An implementation that advertises the BGP Extended Message capability 
MUST be capable of receiving a message with a Length up to and 
including 65,535 octets. 
--- 120,145 ---- 
defined with Capability code 6 and Capability length 0. 

To advertise the BGP Extended Message Capability to a peer, a BGP 
speaker uses BGP Capabilities Advertisement [RFC5492]. By 
advertising the BGP Extended Message Capability to a peer, a BGP 
! speaker conveys that it is able to receive, and properly 
handle, see Section 4, BGP Extended Messages. 

Peers that wish to use the BGP Extended Message capability MUST 
support Error Handling for BGP UPDATE Messages per [RFC7606]. 

4. Operation 

The Extended Message Capability applies to all messages except for 
the OPEN and KEEPALIVE messages. The former exception is to reduce 
the complexity of providing backward compatibility. 

! A BGP speaker that is capable of receiving BGP Extended 
Messages SHOULD advertise the BGP Extended Message Capability to its 
peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker 
! MAY send Extended Messages to a peer only if the Extended Message 
Capability was received from that peer. 

An implementation that advertises the BGP Extended Message capability 
MUST be capable of receiving a message with a Length up to and 
including 65,535 octets. 
*************** Internet-Draft Extended Message sup 
*** 157,168 **** 
4,096 octet pre- Extended Message limit, so as not to require 
downstream routers to decompose for peers that do not support 
Extended Messages. See Section 8.. 

If a BGP message with a Length greater than 4,096 octets is received 
! by a BGP listener who has not advertised the Extended Message 
! Capability, the listener will generate a NOTIFICATION with the Error 
Subcode set to Bad Message Length ([RFC4271] Sec 6.1). 



Bush, et al. Expires January 31, 2020 [Page 3] 
--- 154,165 ---- 
4,096 octet pre- Extended Message limit, so as not to require 
downstream routers to decompose for peers that do not support 
Extended Messages. See Section 8. 

If a BGP message with a Length greater than 4,096 octets is received 
! by a BGP speaker who has not advertised the Extended Message 
! Capability, the speaker will generate a NOTIFICATION with the Error 
Subcode set to Bad Message Length ([RFC4271] Sec 6.1). 



Bush, et al. Expires January 31, 2020 [Page 3] 
*************** Internet-Draft Extended Message sup 
*** 175,190 **** 
speakers which may not support Extended Messages. Therefore, an 
announcement in an Extended Message where the size of the attribute 
set plus the NLRI is larger than 4,096 octets may cause lack of 
reachability. 

! A BGP speaker with a mixture of peers some of which have advertised 
! the BGP Extended Message capability and some which have not, may 
! receive an UPDATE from one of its capable peers that produces an 
ongoing announcement that is larger than 4,096 octets. When 
propagating that UPDATE onward to a neighbor which has not advertised 
! the BGP Extended Message capability, the sender SHOULD try to reduce 
the outgoing message size by removing attributes eligible under the 
"attribute discard" approach of [RFC7606]. If the message is still 
too big, then it must not be sent to the neighbor ([RFC4271], 
Section 9.2). Additionally, if the NLRI was previously advertised to 
that peer, it must be withdrawn from service ([RFC4271], 
--- 172,187 ---- 
speakers which may not support Extended Messages. Therefore, an 
announcement in an Extended Message where the size of the attribute 
set plus the NLRI is larger than 4,096 octets may cause lack of 
reachability. 

! A BGP speaker that has advertised 
! the BGP Extended Message capability to its peers, may 
! receive an UPDATE from one of its peers that produces an 
ongoing announcement that is larger than 4,096 octets. When 
propagating that UPDATE onward to a neighbor which has not advertised 
! the BGP Extended Message capability, the speaker SHOULD try to reduce 
the outgoing message size by removing attributes eligible under the 
"attribute discard" approach of [RFC7606]. If the message is still 
too big, then it must not be sent to the neighbor ([RFC4271], 
Section 9.2). Additionally, if the NLRI was previously advertised to 
that peer, it must be withdrawn from service ([RFC4271],