Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-25.txt

[Greg Skinner <[e-mail]>]

I have a few nits, some suggestions, and some general thoughts about the draft.

Some nits (in diff format):

*** original text	2018-05-23 17:09:06.000000000 -0700
--- new text      	2018-05-23 18:53:18.000000000 -0700
***************
*** 77,83 ****
  
     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  BGP Extended Message  . . . . . . . . . . . . . . . . . . . .   2
!    3.  Extended message Capability for BGP . . . . . . . . . . . . .   3
     4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Changes to RFC4271  . . . . . . . . . . . . . . . . . . . . .   4
--- 77,83 ----
  
     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  BGP Extended Message  . . . . . . . . . . . . . . . . . . . .   2
!    3.  Extended Message Capability for BGP . . . . . . . . . . . . .   3
     4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Changes to RFC4271  . . . . . . . . . . . . . . . . . . . . .   4
***************
*** 96,102 ****
     newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is
     a need to extend the maximum message size beyond 4096 octets.  This
     draft provides an extension to BGP to extend its current message size
!    limit from 4096 octets to 65535 octetsfor all except the OPEN
     message.
  
  2.  BGP Extended Message
--- 96,102 ----
     newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is
     a need to extend the maximum message size beyond 4096 octets.  This
     draft provides an extension to BGP to extend its current message size
!    limit from 4096 octets to 65535 octets for all except the OPEN
     message.
  
  2.  BGP Extended Message
***************
*** 114,120 ****
  Internet-Draft      Extended Message support for BGP            May 2018
  
  
! 3.  Extended message Capability for BGP
  
     To advertise the BGP Extended Message Capability to a peer, a BGP
     speaker uses BGP Capabilities Advertisement [RFC5492].  By
--- 114,120 ----
  Internet-Draft      Extended Message support for BGP            May 2018
  
  
! 3.  Extended Message Capability for BGP
  
     To advertise the BGP Extended Message Capability to a peer, a BGP
     speaker uses BGP Capabilities Advertisement [RFC5492].  By
***************
*** 137,144 ****
     Extended Message Capability from that peer.
  
     The Extended Message Capability only applies to all messages except
!    for the OPEN message.  This exception is reduce compexity of
!    providing backward compatibility
  
     An implementation that advertises support for BGP Extended Messages
     MUST be capable of receiving a message with a length up to and
--- 137,144 ----
     Extended Message Capability from that peer.
  
     The Extended Message Capability only applies to all messages except
!    for the OPEN message.  This exception is made to reduce the
!    complexity of providing backward compatibility.
  
     An implementation that advertises support for BGP Extended Messages
     MUST be capable of receiving a message with a length up to and
***************
*** 150,163 ****
  
     A BGP announcement will, in the normal case, propagate throughout the
     BGP speaking Internet; and there will undoubtedly be BGP speakers
!    which do not have the Extended Message capability.  Therefore putting
!    an attribute which can not be decomposed to 4096 octets or less in an
!    Extended Message is a likely path to routing failure.
  
     It is RECOMMENDED that BGP protocol developers and implementers are
     conservative in their application and use of Extended Messages.
     Future protocol specifications will need to describe how to handle
!    peers which can only accomodate 4096 octet messages.
  
  
  
--- 150,163 ----
  
     A BGP announcement will, in the normal case, propagate throughout the
     BGP speaking Internet; and there will undoubtedly be BGP speakers
!    which do not have the Extended Message capability.  Therefore,
!    putting an attribute which can not be decomposed to 4096 octets or
!    less in an Extended Message is a likely path to routing failure.
  
     It is RECOMMENDED that BGP protocol developers and implementers are
     conservative in their application and use of Extended Messages.
     Future protocol specifications will need to describe how to handle
!    peers which can only accommodate 4096 octet messages.
  
  
  
***************
*** 204,210 ****
  
  7.  IANA Considerations
  
!    The IANA has made an early allocation for this new BGP BGP Extended
     Message Capability referring to this document.
  
     Registry:  BGP Capability Code
--- 204,210 ----
  
  7.  IANA Considerations
  
!    The IANA has made an early allocation for this new BGP Extended
     Message Capability referring to this document.
  
     Registry:  BGP Capability Code
***************
*** 227,233 ****
  
  
     Section 5 allowed a receiver to accept an Extended Message even
!    though they had not advertised the capability.  This slippery slope
     will surely lead to sloppy implementations sending Extended Messages
     when the receiver is not prepared to deal with them, e.g. to peer
     groups.  At best, this will result in errors; at worst, buffer
--- 227,233 ----
  
  
     Section 5 allowed a receiver to accept an Extended Message even
!    though it had not advertised the capability.  This slippery slope
     will surely lead to sloppy implementations sending Extended Messages
     when the receiver is not prepared to deal with them, e.g. to peer
     groups.  At best, this will result in errors; at worst, buffer

Some suggestions:

Section 5:

   A BGP speaker that does not advertise the BGP Extended Messages
   capability might also genuinely not support Extended Messages.  Such
   a speaker would be expected to follow the error handling procedures
   of [RFC4271] if it receives an Extended Message.  Similarly, any
   speaker that treats an improper Extended Message as a fatal error,
   MUST treat it similarly.

Since this draft updates 4271, why not make the second sentence normative, such
as: Such a speaker MUST follow the error handling procedures of [RFC4271] ...


Section 8:

   Section 5 allowed a receiver to accept an Extended Message even
   though they had not advertised the capability.  This slippery slope
   will surely lead to sloppy implementations sending Extended Messages
   when the receiver is not prepared to deal with them, e.g. to peer
   groups.  At best, this will result in errors; at worst, buffer
   overflows.

The second sentence is (understandably) pessimistic.  Perhaps it could be toned
down a bit, such as: This slippery slope could lead to sloppy implementations …

   Due to increased (over [RFC4272]) memory requirements for buffering,
   there may be increased exposure to resource exhaustion, intentional
   or unintentional.

I wasn't sure what "over [RFC4272]" was referring to, because I couldn't find
any mention of "memory requirements for buffering" (or words to that effect)
in 4272.


Some general thoughts:

After reading many idr list messages and the datatracker history of the draft, and reviewing it myself, I am concerned that what has been proposed needs more input, especially from the ops community, before being published.   However, I understand that there are people who have worked very hard on the draft and would like to see it published.  A good deal of the commentary is operational in nature. Perhaps two separate drafts are needed, focusing on the protocol specification and operations, similarly to how 7947 and 7948 were handled, respectively.  On the other hand, I hope this would not impact the entire effort too much.

Regards,
Greg 

> On May 21, 2018, at 9:14 AM, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>        Title           : Extended Message support for BGP
>        Authors         : Randy Bush
>                          Keyur Patel
>                          Dave Ward
> 	Filename        : draft-ietf-idr-bgp-extended-messages-25.txt
> 	Pages           : 6
> 	Date            : 2018-05-21
> 
> Abstract:
>   The BGP specification mandates a maximum BGP message size of 4096
>   octets.  As BGP is extended to support newer AFI/SAFIs and other
>   features, there is a need to extend the maximum message size beyond
>   4096 octets.  This document updates the BGP specification RFC4271 by
>   providing an extension to BGP to extend its current maximum message
>   size from 4096 octets to 65535 octets for all except the OPEN
>   message.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-25
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-extended-messages-25
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-25
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>