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

From: [email-masked]
Date: Sat, 21 May 2016 03:48:12 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Extended Message support for BGP
        Authors         : Randy Bush
                          Keyur Patel
                          Dave Ward
	Filename        : draft-ietf-idr-bgp-extended-messages-12.txt
	Pages           : 5
	Date            : 2016-05-21

Abstract:
   The BGP specification mandates a maximum BGP message size of 4096
   octets.  As BGP is extended to support newer AFI/SAFIs, there is a
   need to extend the maximum message size beyond 4096 octets.  This
   document updates the BGP specification in RFC4271 by providing an
   extension to BGP to extend its current message size from 4096 octets
   to 65535 octets.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-12

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/

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 May 2016 14:36:47 +0200

the change was to error handling.  jgs did the heavy lifting, tyvm.

OLD

5.  Error Handling

   A BGP speaker that has the ability to use extended messages but has
   not advertised the BGP Extended Messages capability, presumably due
   to configuration, SHOULD NOT accept such a message.

   However, 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 [RFC4221], Section 6.1, and reset the session
   with a Bad Message Length NOTIFICATION if it receives an extended
   message.  A speaker that treats an improper extended message as a
   fatal error should do likewise.

NEW

5.  Error Handling

   A BGP speaker that has the ability to use extended messages but has
   not advertised the BGP Extended Messages capability, presumably due
   to configuration, SHOULD NOT accept an extended message.  A speaker
   MAY implement a more liberal policy and accept extended messages even
   from a peer that has not advertised the capability.

   However, 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 [RFC4221], Section 6.1, and reset the session
   with a Bad Message Length NOTIFICATION if it receives an extended
   message.  A speaker that treats an improper extended message as a
   fatal error, as described in the preceding paragraph, MUST do
   likewise.

randy