Skip to main content

Extended Message Support for BGP
draft-ietf-idr-bgp-extended-messages-36

Revision differences

Document history

Date Rev. By Action
2019-10-08
36 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-10-03
36 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-09-17
36 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-08-23
36 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-08-19
36 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-08-19
36 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-08-16
36 (System) RFC Editor state changed to EDIT
2019-08-16
36 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-08-16
36 (System) Announcement was received by RFC Editor
2019-08-16
36 (System) IANA Action state changed to In Progress
2019-08-16
36 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-08-16
36 Amy Vezza IESG has approved the document
2019-08-16
36 Amy Vezza Closed "Approve" ballot
2019-08-16
36 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2019-08-16
36 Alvaro Retana Ballot approval text was generated
2019-08-16
36 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-16
36 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-36.txt
2019-08-16
36 (System) New version approved
2019-08-16
36 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-08-16
36 Randy Bush Uploaded new revision
2019-08-08
35 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2019-08-08
35 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-08-07
35 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-08-07
35 Roman Danyliw
[Ballot comment]
A nit in Section 4: Per “A BGP UPDATE will (policy, best path, etc., allowing) typically propagate throughout the BGP speaking Internet”, the …
[Ballot comment]
A nit in Section 4: Per “A BGP UPDATE will (policy, best path, etc., allowing) typically propagate throughout the BGP speaking Internet”, the parenthetical “((policy, best path, etc., allowing)” doesn’t parse for me.
2019-08-07
35 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-08-07
35 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-08-07
35 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-08-07
35 Warren Kumari [Ballot comment]
Thank you for writing this.
2019-08-07
35 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-08-06
35 Alissa Cooper
[Ballot comment]
'When propagating that UPDATE onward to a neighbor which has not
  advertised the BGP Extended Message capability, the speaker SHOULD
  try …
[Ballot comment]
'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].'

This might be a bit clearer if it were to explain that "eligibility" is not limited to malformed attributes (since RFC 7606 could be read as having that limitation).
2019-08-06
35 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-08-05
35 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-08-05
35 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-08-02
35 Rich Salz Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rich Salz. Sent review to list.
2019-08-01
35 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-07-31
35 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-35.txt
2019-07-31
35 (System) New version approved
2019-07-31
35 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-07-31
35 Randy Bush Uploaded new revision
2019-07-30
34 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-07-30
34 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-34.txt
2019-07-30
34 (System) New version approved
2019-07-30
34 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-07-30
34 Randy Bush Uploaded new revision
2019-07-30
33 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-07-30
33 Mirja Kühlewind
[Ballot comment]
Some comment on use of normative language:

1) I know what the intention is here but this normative language is not used correctly …
[Ballot comment]
Some comment on use of normative language:

1) I know what the intention is here but this normative language is not used correctly (sec 4):
"A BGP speaker
  MAY send Extended Messages to a peer only if the Extended Message
  Capability was advertised by both peers."
This should be a MUST anyway (and moving the "only"):
"A BGP speaker
  MUST only send Extended Messages to a peer if the Extended Message
  Capability was advertised by both peers."
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g.
"A BGP speaker
  MUST NOT send Extended Messages to a peer if the Extended Message
  Capability was not advertised by both peers. A BGP speaker
  MAY send Extended Messages to a peer if the Extended Message
  Capability was advertised by both peers."

2) sec 4:
"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 MUST treat this as a malformed message, and
  MUST generate a NOTIFICATION with the Error Subcode set to Bad
  Message Length (see [RFC4271] Sec 6.1)."
If this is specified normatively in RFC4271, you should not use normative language here as well.
I suggest s/MUST/will/

3) sec 4:
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/
and
s/it must be withdrawn from service/it MUST be withdrawn from service/

4) sec 4
"In an iBGP mesh, if BGP Extended Messages are to be advertized, all
  peers MUST advertize the BGP Extended Message capability."
Which action(s) should be taken if that is not the case?
2019-07-30
33 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-07-19
33 Cindy Morgan Placed on agenda for telechat - 2019-08-08
2019-07-19
33 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2019-07-19
33 Alvaro Retana Ballot has been issued
2019-07-19
33 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2019-07-19
33 Alvaro Retana Created "Approve" ballot
2019-07-19
33 Alvaro Retana Ballot writeup was changed
2019-07-18
33 Himanshu Shah Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Himanshu Shah. Sent review to list.
2019-07-18
33 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-07-17
33 Min Ye Request for Telechat review by RTGDIR is assigned to Himanshu Shah
2019-07-17
33 Min Ye Request for Telechat review by RTGDIR is assigned to Himanshu Shah
2019-07-17
33 Alvaro Retana Requested Telechat review by RTGDIR
2019-07-17
33 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-07-17
33 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-extended-messages-33. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-extended-messages-33. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Capability Codes registry located at:

https://www.iana.org/assignments/capability-codes/

the temporary registration for value 6, description: BGP-Extended Message will be made permanent and its reference will be changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-07-17
33 Jouni Korhonen Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jouni Korhonen. Sent review to list.
2019-07-15
33 Min Ye Request closed, assignment withdrawn: Harish Sitaraman Last Call RTGDIR review
2019-07-15
33 Min Ye Closed request for Last Call review by RTGDIR with state 'Withdrawn'
2019-07-15
33 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2019-07-15
33 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2019-07-15
33 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2019-07-15
33 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2019-07-08
33 Susan Hares
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed Standard
Note: this updates …
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed Standard
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary
The working had had 3 WG LCs over 3 years.
All of these WG LC indicated some support, but concerns about specific language. 
The last WG LC (2019)  has resolved all issues on this draft:
(https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4)

WG members have report 4 implementations;
(QuggaSRX, BGPSEC-IO, Open Daylight, ExaBGP)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

The BGP additions for BGP-LS may exceed the current BGP
messages size (4096).  Approval of this draft is important for
allowing the BGP-LS and Segment Routing (SR) in Spring to
continue to add more information to the BGP stream.

Document Quality:
Documen thas been review extensively for language. 
The current language is the result of a great deal of discussion
and WG consensus.  ADs should have a strong reason for
suggesting changes.  Each change may require review by the
WG.

4 implementation exist - see above. 
Status:
WG LC1  (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

Problem with version -21 - AD's suggested changes do not align with RFC4271 see:
https://www.ietf.org/mail-archive/web/idr/current/msg17518.html

Second WG LC : (1/29/2019 to 2/15/2019)
https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4
All comments resolved. 

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retana
RTG-DIR Reviewer: Brian Weis


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.
6) Long discussion (version 11 to version 30)
  with WG, authors, chairs, 

WG LC thread for this discussion:
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=Y4Q801vvPpBlbuLhpxQKB8zXns4

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  We have worked through this short document 3-4 times.

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 

Asked again for check on RTG-DIR review with -30.txt (6/3/2019)
from Brian Weis.  Responding pending.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
Open Daylight "just did it" because their users requested.
They report little problems with implementation.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Additional Implementation from ODL (open Day light)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.
All informative references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA has made an early allocation for this new BGP Extended
  Message Capability referring to this document.
  Registry:  BGP Capability Code

  Value    Description                        Document
  6            BGP-Extended Message  [this document]

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just one new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2019-07-04
33 Paul Kyzivat Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Paul Kyzivat.
2019-07-03
33 Jean Mahoney Request for Last Call review by GENART is assigned to Paul Kyzivat
2019-07-03
33 Jean Mahoney Request for Last Call review by GENART is assigned to Paul Kyzivat
2019-07-03
33 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2019-07-03
33 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2019-07-03
33 Luc André Burdet Assignment of request for Last Call review by RTGDIR to Dave Sinicrope was rejected
2019-07-02
33 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2019-07-02
33 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2019-07-02
33 Luc André Burdet Assignment of request for Last Call review by RTGDIR to Himanshu Shah was rejected
2019-07-02
33 Min Ye Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2019-07-02
33 Min Ye Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2019-07-02
33 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-07-02
33 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-07-18):

From: The IESG
To: IETF-Announce
CC: jie.dong@huawei.com, idr@ietf.org, idr-chairs@ietf.org, shares@ndzh.com., aretana.ietf@gmail.com …
The following Last Call announcement was sent out (ends 2019-07-18):

From: The IESG
To: IETF-Announce
CC: jie.dong@huawei.com, idr@ietf.org, idr-chairs@ietf.org, shares@ndzh.com., aretana.ietf@gmail.com, draft-ietf-idr-bgp-extended-messages@ietf.org, jgs@juniper.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extended Message support for BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Extended Message support for BGP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-07-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The BGP specification mandates a maximum BGP message size of 4,096
  octets.  As BGP is extended to support newer AFI/SAFIs and other
  features, there is a need to extend the maximum message size beyond
  4,096 octets.  This document updates the BGP specification RFC4271 by
  extending the maximum message size from 4,096 octets to 65,535 octets
  for all except the OPEN and KEEPALIVE messages.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4272: BGP Security Vulnerabilities Analysis (Informational - IETF stream)



2019-07-02
33 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-07-02
33 Alvaro Retana Requested Last Call review by RTGDIR
2019-07-02
33 Alvaro Retana Last call was requested
2019-07-02
33 Alvaro Retana Ballot approval text was generated
2019-07-02
33 Alvaro Retana Ballot writeup was generated
2019-07-02
33 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-07-02
33 Alvaro Retana Last call announcement was changed
2019-07-02
33 Alvaro Retana Last call announcement was generated
2019-07-02
33 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-33.txt
2019-07-02
33 (System) New version approved
2019-07-02
33 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-07-02
33 Randy Bush Uploaded new revision
2019-07-02
32 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-32.txt
2019-07-02
32 (System) New version approved
2019-07-02
32 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-07-02
32 Randy Bush Uploaded new revision
2019-06-30
31 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-06-30
31 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-31.txt
2019-06-30
31 (System) New version approved
2019-06-30
31 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-06-30
31 Randy Bush Uploaded new revision
2019-06-28
30 Alvaro Retana === AD Review of draft-ietf-idr-bgp-extended-messages-30 ===
https://mailarchive.ietf.org/arch/msg/idr/xG591ks0nXrUHe_iaN4KsM4RLEw
2019-06-28
30 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-06-26
30 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2019-06-03
30 Susan Hares
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed RFC
Note: this updates …
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary
The working had had 3 WG LCs over 3 years.
All of these WG LC indicated some support, but concerns about specific language. 
The last WG LC (2019)  has resolved all issues on this draft:
(https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4)

WG members have report 4 implementations;
(QuggaSRX, BGPSEC-IO, Open Daylight, ExaBGP)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

The BGP additions for BGP-LS may exceed the current BGP
messages size (4096).  Approval of this draft is important for
allowing the BGP-LS and Segment Routing (SR) in Spring to
continue to add more information to the BGP stream.

Document Quality:
Documen thas been review extensively for language. 
The current language is the result of a great deal of discussion
and WG consensus.  ADs should have a strong reason for
suggesting changes.  Each change may require review by the
WG.

4 implementation exist - see above. 
Status:
WG LC1  (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

Problem with version -21 - AD's suggested changes do not align with RFC4271 see:
https://www.ietf.org/mail-archive/web/idr/current/msg17518.html

Second WG LC : (1/29/2019 to 2/15/2019)
https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4
All comments resolved. 

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano
RTG-DIR Reviewer: Brian Weis


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.
6) Long discussion (version 11 to version 30)
  with WG, authors, chairs, 

WG LC thread for this discussion:
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=Y4Q801vvPpBlbuLhpxQKB8zXns4

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  We have worked through this short document 3-4 times.

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 

Asked again for check on RTG-DIR review with -30.txt (6/3/2019)
from Brian Weis.  Responding pending.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
Open Daylight "just did it" because their users requested.
They report little problems with implementation.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Additional Implementation from ODL (open Day light)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.
All informative references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA has made an early allocation for this new BGP Extended
  Message Capability referring to this document.
  Registry:  BGP Capability Code

  Value    Description                        Document
  6            BGP-Extended Message  [this document]

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just one new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2019-06-03
30 Susan Hares IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-06-03
30 Susan Hares IESG state changed to Publication Requested from AD is watching
2019-06-03
30 Susan Hares
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed RFC
Note: this updates …
Status:  Ready for AD Evaluation

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary
The working had had 3 WG LCs over 3 years.
All of these WG LC indicated some support, but concerns about specific language. 
The last WG LC (2019)  has resolved all issues on this draft:
(https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4)

WG members have report 4 implementations;
(QuggaSRX, BGPSEC-IO, Open Daylight, ExaBGP)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

The BGP additions for BGP-LS may exceed the current BGP
messages size (4096).  Approval of this draft is important for
allowing the BGP-LS and Segment Routing (SR) in Spring to
continue to add more information to the BGP stream.

Document Quality:
Documen thas been review extensively for language. 
The current language is the result of a great deal of discussion
and WG consensus.  ADs should have a strong reason for
suggesting changes.  Each change may require review by the
WG.

4 implementation exist - see above. 
Status:
WG LC1  (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

Problem with version -21 - AD's suggested changes do not align with RFC4271 see:
https://www.ietf.org/mail-archive/web/idr/current/msg17518.html

Second WG LC : (1/29/2019 to 2/15/2019)
https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4
All comments resolved. 

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano
RTG-DIR Reviewer: Brian Weis


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.
6) Long discussion (version 11 to version 30)
  with WG, authors, chairs, 

WG LC thread for this discussion:
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=Y4Q801vvPpBlbuLhpxQKB8zXns4

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  We have worked through this short document 3-4 times.

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 

Asked again for check on RTG-DIR review with -30.txt (6/3/2019)
from Brian Weis.  Responding pending.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
Open Daylight "just did it" because their users requested.
They report little problems with implementation.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Additional Implementation from ODL (open Day light)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.
All informative references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA has made an early allocation for this new BGP Extended
  Message Capability referring to this document.
  Registry:  BGP Capability Code

  Value    Description                        Document
  6            BGP-Extended Message  [this document]

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just one new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2019-06-03
30 Susan Hares
Status:
Ready for AD Evaluation
Checking on early RTG-DIR Review prior to submit

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder  …
Status:
Ready for AD Evaluation
Checking on early RTG-DIR Review prior to submit

AD: Alvaro Retano
Shepherd: Susan Hares
WG chairs: Susan Hares, John Scudder 


1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary
The working had had 3 WG LCs over 3 years.
All of these WG LC indicated some support, but concerns about specific language. 
The last WG LC (2019)  has resolved all issues on this draft:
(https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4)

WG members have report 4 implementations;
(QuggaSRX, BGPSEC-IO, Open Daylight, ExaBGP)
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

The BGP additions for BGP-LS may exceed the current BGP
messages size (4096).  Approval of this draft is important for
allowing the BGP-LS and Segment Routing (SR) in Spring to
continue to add more information to the BGP stream.

Document Quality:
Documen thas been review extensively for language. 
The current language is the result of a great deal of discussion
and WG consensus.  ADs should have a strong reason for
suggesting changes.  Each change may require review by the
WG.

4 implementation exist - see above. 
Status:
WG LC1  (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

Problem with version -21 - AD's suggested changes do not align with RFC4271 see:
https://www.ietf.org/mail-archive/web/idr/current/msg17518.html

Second WG LC : (1/29/2019 to 2/15/2019)
https://mailarchive.ietf.org/arch/msg/idr/Y4Q801vvPpBlbuLhpxQKB8zXns4
All comments resolved. 

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano
RTG-DIR Reviewer: Brian Weis


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.
6) Long discussion (version 11 to version 30)
  with WG, authors, chairs, 

WG LC thread for this discussion:
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=Y4Q801vvPpBlbuLhpxQKB8zXns4

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  We have worked through this short document 3-4 times.

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 

Asked again for check on RTG-DIR review with -30.txt (6/3/2019)
from Brian Weis.  Responding pending.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
Open Daylight "just did it" because their users requested.
They report little problems with implementation.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Additional Implementation from ODL (open Day light)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.
All informative references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA has made an early allocation for this new BGP Extended
  Message Capability referring to this document.
  Registry:  BGP Capability Code

  Value    Description                        Document
  6            BGP-Extended Message  [this document]

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just one new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2019-03-27
30 Susan Hares 2 implementations already exit
2019-03-27
30 Susan Hares 2 implementations already exit
2019-03-27
30 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-03-26
30 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-30.txt
2019-03-26
30 (System) New version approved
2019-03-26
30 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-03-26
30 Randy Bush Uploaded new revision
2019-03-10
29 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-29.txt
2019-03-10
29 (System) New version approved
2019-03-10
29 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-03-10
29 Randy Bush Uploaded new revision
2019-02-13
28 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-28.txt
2019-02-13
28 (System) New version approved
2019-02-13
28 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2019-02-13
28 Randy Bush Uploaded new revision
2019-01-25
27 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2018-12-02
27 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-27.txt
2018-12-02
27 (System) New version approved
2018-12-02
27 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2018-12-02
27 Randy Bush Uploaded new revision
2018-10-03
26 Susan Hares IETF WG state changed to WG Document from In WG Last Call
2018-06-06
26 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-26.txt
2018-06-06
26 (System) New version approved
2018-06-06
26 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2018-06-06
26 Randy Bush Uploaded new revision
2018-05-21
25 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-25.txt
2018-05-21
25 (System) New version approved
2018-05-21
25 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2018-05-21
25 Randy Bush Uploaded new revision
2017-11-18
24 Alvaro Retana Notification list changed to jgs@juniper.net, jie.dong@huawei.com, aretana.ietf@gmail.com from jgs@juniper.net, jie.dong@huawei.com, aretana@cisco.com
2017-11-18
24 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-24.txt
2017-11-18
24 (System) New version approved
2017-11-18
24 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2017-11-18
24 Randy Bush Uploaded new revision
2017-11-12
23 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2017-10-30
23 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-23.txt
2017-10-30
23 (System) Forced post of submission
2017-10-30
23 (System) Request for posting confirmation emailed to previous authors: Keyur Patel , David Ward , Randy Bush
2017-10-30
23 Randy Bush Uploaded new revision
2017-08-15
22 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-22.txt
2017-08-15
22 (System) New version approved
2017-08-15
22 (System) Request for posting confirmation emailed to previous authors: Randy Bush , David Ward , Keyur Patel
2017-08-15
22 Randy Bush Uploaded new revision
2017-03-07
21 Alvaro Retana
After reading the messages in this thread [1], I’m returning the document to the WG to finish the discussion there.

Based on the discussion, I …
After reading the messages in this thread [1], I’m returning the document to the WG to finish the discussion there.

Based on the discussion, I think there are some open items that I would like the WG to close on (in no particular order):

- Should this document address all messages or just UPDATES?  [The Chairs asked for feedback from grow.]

- Are any updates needed to the FSM?

- Is it ok to send/accept Extended Messages without having received/advertised the Capability?  This is a significant change in the way BGP operates – and would set an important precedent.

- What about incremental deployment?  Should there be operational guidance?  If so, what should that guidance be?

[1] https://mailarchive.ietf.org/arch/msg/idr/7xk6dDxTx1Ix8jVYQ_KT6r7l6FQ/?qid=bda1d08e1f9cc5150b94e41f8ca48b8b
2017-03-07
21 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2017-03-07
21 Alvaro Retana
After reading the messages in this thread [1], I’m returning the document to the WG to finish the discussion there.

Based on the discussion, I …
After reading the messages in this thread [1], I’m returning the document to the WG to finish the discussion there.

Based on the discussion, I think there are some open items that I would like the WG to close on (in no particular order):

- Should this document address all messages or just UPDATES?  [The Chairs asked for feedback from grow.]

- Are any updates needed to the FSM?

- Is it ok to send/accept Extended Messages without having received/advertised the Capability?  This is a significant change in the way BGP operates – and would set an important precedent.

- What about incremental deployment?  Should there be operational guidance?  If so, what should that guidance be?


[1] https://mailarchive.ietf.org/arch/msg/idr/7xk6dDxTx1Ix8jVYQ_KT6r7l6FQ/?qid=bda1d08e1f9cc5150b94e41f8ca48b8b
2017-03-07
21 Alvaro Retana IESG state changed to AD is watching from AD Evaluation::AD Followup
2017-03-06
21 Susan Hares
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 

Note: Shepherd does not recommend approving draft-ietf-bgp-extended-messages-21.txt.
In the …
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 

Note: Shepherd does not recommend approving draft-ietf-bgp-extended-messages-21.txt.
In the shepherd's opinion (as one of co-authors of RFC4271), the changes suggested by the AD do align with RFC4271.
Please see the  comments.

https://www.ietf.org/mail-archive/web/idr/current/msg17518.html



1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary


Document Quality:
Implementations by 2 BGP-SEC implementations
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Status: WG LC (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

Problem with version -21 - AD's suggested changes do not align with RFC4271 see:
https://www.ietf.org/mail-archive/web/idr/current/msg17518.html

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.
6) Check against RFC4271 FSM - failed in version 21.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 
Shepherd feels that version 21 does not align with RFC4271 and should not be published.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
The existing implementations are for SIDR. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Additional Implementation from ODL on list.

Shepherd suggests that version 21 does not align with the RFC4271.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.

The following Informative references are at the IESG:
draft-ietf-sidr-bgpsec-overview
draft-ietf-sidr-bgpsec-protocol

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA request a code out of the BGP capability code registry.
Codes 1-63 require a IETF draft. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2017-03-04
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-03-04
21 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-21.txt
2017-03-04
21 (System) New version approved
2017-03-04
21 (System) Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Randy Bush , David Ward , Keyur Patel
2017-03-04
21 Randy Bush Uploaded new revision
2017-02-23
20 Alvaro Retana
===== AD Review of draft-ietf-idr-bgp-extended-messages-20 =====

Dear authors:

I just finished reading this document.  I started hoping that this would be a quick and easy …
===== AD Review of draft-ietf-idr-bgp-extended-messages-20 =====

Dear authors:

I just finished reading this document.  I started hoping that this would be a quick and easy read, and it was, but I have some concerns related to the operation of this extension, specifically as it refers to error correction and transition.  Please take a look at the comments below.  I note that these two major concerns were already discussed on the WG list as a result of the RtgDir review [1] and during the WGLC [2], but, while there seemed to be understanding of the points made and good discussion, none of that was reflected in the draft.

I will wait until we resolve what I consider are Major issues before starting the IETF Last Call.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/rtg-dir/6EJK3UC7bFnTps0afdpl2Iw3d5Y/?qid=3668a9f4a846476e78c8992fcd3ce2e6
[2] https://mailarchive.ietf.org/arch/msg/idr/mBxUNwF0qsdGUWpqpUkGYAwJkYg/?qid=18c32eeee917280402a62da361902190



Major:

M1. Section 4. (Operation): “An implementation that supports the BGP Extended Messages MUST be prepared to receive an UPDATE message that is larger than 4096 bytes.“  Only UPDATEs?  I know that the most likely case for exceeding the 4k size is an UPDATE, but why are the other messages not considered?  I think that OPEN/NOTIFICATIONs exceeding 4k would be unusual (and maybe even unnecessary or unwanted), but given the extra space I can imagine the benefits of adding more detailed information in NOTIFICATIONs – not that we should, but we could.  Also, what does “prepared to receive” mean, and how can “MUST be prepared to receive” be enforced?  Given the discussion in Section 5 (Error Handling), you might want to add something like “…even if the Capability is not advertised”.


M2. Section 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.”  This paragraph troubles me a lot because it is in direct contraction with Section 3: “A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”.  However, I think that John Scudder’s reasoning [3] makes sense ("keep the session up at (almost) all costs", and there’s clear precedence in the WG) for the case where the sender did advertise the Capability, but I’m not convinced on the case where it didn’t – please include something like John’s explanation in the text.

M2.1.  Even with John’s explanation, I find myself thinking that this specification could result in some sloppy implementations: if I need to account for receiving unexpected Extended Messages in my code, then maybe I won’t worry too much about controlling what to send to my peers – specially in cases where it would be easy to just replicate an UPDATE (like in a peer-group) and not worry about possible exceptions.  I know that we can’t avoid bad implementations, no matter what text is added – but I think that recognizing the threat (maybe in the Security Considerations section) of someone receiving an Extended Message when they don’t support it would be good.  I know that there’s text in the document already which talks about what to do if the receiver doesn’t support Extended Messages – I’m just worried about potential issues with memory allocation if the receiver was not ready…

[3] https://mailarchive.ietf.org/arch/msg/idr/-_GW6rftabJLrrQnxoxM5XXDGAM/?qid=5e8521fc3a43a5580a3c1e05961dc084


M3. Section 5 (Error Handling).  “…reset the session with a Bad Message Length NOTIFICATION…”  Please be clear and specific: (something like this would be more precise) “...send a NOTIFICATION message with the Error Code set to Message Header Error and the Error Subcode set to Bad Message Type, and close the session”.  Alternatively, you can just remove the text (after the reference to rfc4271) as that is what rfc4271 already says and there’s no need to repeat it here and risk not being precise…


M4. Section 5 (Error Handling).  “Similarly, any speaker that treats an improper extended message as a fatal error, MUST do likewise.”  It sounds that you’re saying that any fatal error will result in a “Bad Message Length NOTIFICATION”.  I hope that is not what you meant – and that other errors should result in the appropriate action from rfc4271/rfc7606.  IOW, the error checking for the message (besides de length) doesn’t change, right?


M5. Section 5 (Error Handling).  “The inconsistency between the local and remote BGP speakers MUST be reported via syslog and/or SNMP.”  SNMP?  AFAIK, there’s no object that can report this inconsistency since there’s no NOTIFICATION generated.  In the proposed text by Gunter Van De Velde [4], SNMP and syslog were mentioned as examples – I suggest you follow that path (no need for all the “flowery language”) and just reference mechanisms by example to avoid having to point at how it would be done.

M5.1. [minor] Gunter had originally suggested that the message that caused the inconsistency be included in the report.  Are you expecting the inconsistency report to just be a “Bob sent me an Extended Message, but I didn’t advertise the Capability to him”-type message, or something more?  It might be useful to provide some guidance indicating what type of information might be useful/interesting.

[4] https://mailarchive.ietf.org/arch/msg/idr/RtcX--cG91_rXZw6Jb3OpSOWI00/?qid=bfc7a8f05a4c86ca9a8c568ec68a9bf5


M6. Updates to rfc4271.  The Abstract/Introduction correctly mention that this document Updates rfc4271.  But I think we need to be more specific, specially where rfc4271 changes and there is normative language involved.  I found two cases:

M6.1. Section 5 doesn’t describe the behavior if the message is longer than 65535.  Please include either an explicit update to rfc4271/Section 6.1 for the use of Extended Messages, or the specific process here.

M6.2. rfc4271: “The value of the Length field MUST always be at least 19 and no greater than 4096”  That needs to be updated to 65535.


M7. What about transition/migration/partial deployment?  What should the behavior be if, for example, an Extended Message UPDATE is received from a peer, but can’t be propagated to others because they don’t support Extended Messages (think route reflectors or simple eBGP -> iBGP)??  There should be some guidance for the general case (i.e. when the total size is >4k due simply to the total amount of information, and not because a single attribute, for example, is really big), and some requirements looking forward to potential new messages/attributes that specifically rely on Extended Messages.

M7.1. This topic was also brought up during WGLC, for example [5] and [6].  There are a couple of suggested actions/text on the list too: [7] and [8] – one of them is: “if the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case)” [8].  A couple of points to highlight: (1) “SHOULD not be announced”: which goes back to Section 5 (and, in this case, sending Extended Messages without receiving the Capability from the neighbors); (2) the behavior can result in inconsistent routing, etc…please mention the potential risks of partial deployment.

M7.2. What should the default be for this extension?  Should it be enabled by default or not?

[5] https://mailarchive.ietf.org/arch/msg/idr/D-0QACWXZIv_MwfNt31-Z0B21kI/?qid=ab2c93d1df016705a4834b4e2fb0c1bf
[6] https://mailarchive.ietf.org/arch/msg/idr/n3UQqkWf5RTsl2FBRKP2oqjzqok/?qid=a35699c937ccd38d9b9054e04351487d
[7] https://mailarchive.ietf.org/arch/msg/idr/Ugdm6XTnNp5JNLaiCUQwfOZNwyI/?qid=af475de36c9d2d6e64b3c5fbf95d8b1e
[8] https://mailarchive.ietf.org/arch/msg/idr/dQryJqArmA4OZUWAHLA2zpwhSN4/?qid=af475de36c9d2d6e64b3c5fbf95d8b1e




Minor:

P1. Abstract: s/extend its current message size from 4096/extend its current maximum message size from 4096

P2. s/I-D.ietf-sidr-bgpsec-overview/I-D.ietf-sidr-bgpsec-protocol

P3. IANA already assigned Code 6 for the Capability.  Please use that value and remind IANA of the early allocation in the IANA Considerations section.

P4. I don’t understand what this means: “Applications generating messages which might be encapsulated within BGP messages MUST limit the size of their payload to take into account the maximum message size.”  The part that is not clear is “messages…encapsulated within BGP messages…”.  What is that?  I guess you’re talking about any stuff that BGP may be transporting, right?  Maybe s/messages which might be/information to be

P5. Security Considerations: I think it would be good to also reference rfc4272 (BGP Security Vulnerabilities Analysis) in this section.


Nits:

N1. “It does enable large BGPsec BGPSEC_PATHs, see [I-D.ietf-sidr-bgpsec-protocol].”  Nice, but superfluous as it refers to this document.
2017-02-23
20 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-02-17
20 Alvaro Retana Notification list changed to jgs@juniper.net, jie.dong@huawei.com, aretana@cisco.com from jgs@juniper.net, jie.dong@huawei.com
2017-02-17
20 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-02-16
20 Susan Hares
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 

Note to Alvaro:  I'm sending this forward to you …
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 

Note to Alvaro:  I'm sending this forward to you without the draft being updated for the latest SIDR drafts in the informative section.  You will find NITS due to that issue. I expect Randy will update on 2/17/2017  after the IESG 2/16 meeting.  I am forwarding this draft to you because you wanted it to be in place for the SIDR Drafts.


1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary


Document Quality:
Implementations by 2 BGP-SEC implementations
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Status: WG LC (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

NITS - version 20
  == Outdated reference: A later version (-08) exists of
    draft-ietf-sidr-bgpsec-overview-02
  == Outdated reference: A later version (-22) exists of
    draft-ietf-sidr-bgpsec-protocol-07

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 
AD should be able to review in parallel since first RTG-QA reviewer
agreed to work.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
The existing implementations are for SIDR. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.

The following Informative references are at the IESG:
draft-ietf-sidr-bgpsec-overview
draft-ietf-sidr-bgpsec-protocol

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA request a code out of the BGP capability code registry.
Codes 1-63 require a IETF draft. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2017-02-16
20 Susan Hares
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 
Status:  awaiting nits (version 19)

Implementations:
      …
Status: Pending nit fixing
AD: Alvaro Retano
Shepherd: Susan Hares
WG chair: Susan Hares, John Scuder 
Status:  awaiting nits (version 19)

Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

1) RFC type: Proposed RFC
Note: this updates RFC 4271 (The Base BGP specification)

(2) The IESG approval announcement includes a Document Announcement
Technical Summary

  The BGP specification (RFC4271) 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 by providing an extension to BGP to extend
  its current message size from 4096 octets to 65535 octets.

Working Group Summary


Document Quality:
Implementations by 2 BGP-SEC implementations
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

Status: WG LC (finished 5/24 -6/16/2016)
https://mailarchive.ietf.org/arch/msg/idr/bDGJGIuYU71I7gAHYMRBp5106-o

NITS - version 18
  == Outdated reference: A later version (-08) exists of
    draft-ietf-sidr-bgpsec-overview-02

  == Outdated reference: A later version (-22) exists of
    draft-ietf-sidr-bgpsec-protocol-07

Personnel
Document Shepherd: Susan Hares
Area Director: Alvaro Retano

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. 

1) IDR Nits run.
2) Read Draft for early allocation
3) considered Security section
4) Routing Directorate QA review
5) Check against implementation report.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

RTG-DIR QA review agreed to changes.
Requesting re-review by RTG-DIR on 2/16/2017
to clarify any extended messages. 
AD should be able to review in parallel since first RTG-QA reviewer
agreed to work.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? 

no.  Normal reviews are fine.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

no.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/RN8TjquVmeU-LOliup8i_8kMXjo

Randy Bush:
https://mailarchive.ietf.org/arch/msg/idr/fgI9I9G2Ve9Tm4lvD3q8A-dK5LY

David Ward:
https://mailarchive.ietf.org/arch/msg/idr/S8lmOBH3zVpkADXEvxh6iS1LYWs


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus.  John Scudder ask about the memory constraints for normal BGP implementations.
The existing implementations are for SIDR. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Shepherd + Jie Dong have reviewed the text and compared with the
Implementations:
            https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

none outside of formal review.

(13) Have all references within this document been identified as
either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are RFCs.

The following Informative references are at the IESG:
draft-ietf-sidr-bgpsec-overview
draft-ietf-sidr-bgpsec-protocol

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
none

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

RFC4271 - base BGP specification is updated.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA request a code out of the BGP capability code registry.
Codes 1-63 require a IETF draft. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new Registries. Just new BGP capability.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no review of automated checks required.
2017-02-16
20 Susan Hares Responsible AD changed to Alvaro Retana
2017-02-16
20 Susan Hares IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-02-16
20 Susan Hares IESG state changed to Publication Requested
2017-02-16
20 Susan Hares IESG process started in state Publication Requested
2017-02-16
20 Susan Hares Notification list changed to jgs@juniper.net, jie.dong@huawei.com
2017-02-16
20 Susan Hares Tag Other - see Comment Log cleared.
2017-02-16
20 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-20.txt
2017-02-16
20 (System) New version approved
2017-02-16
20 (System) Request for posting confirmation emailed to previous authors: "Keyur Patel" , "Randy Bush" , "David Ward" , idr-chairs@ietf.org
2017-02-16
20 Randy Bush Uploaded new revision
2017-02-16
19 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-19.txt
2017-02-16
19 (System) New version approved
2017-02-16
19 (System) Request for posting confirmation emailed to previous authors: "Keyur Patel" , "Randy Bush" , "David Ward" , idr-chairs@ietf.org
2017-02-16
19 Randy Bush Uploaded new revision
2017-02-16
18 Susan Hares Changed document writeup
2017-02-12
18 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-18.txt
2017-02-12
18 (System) New version approved
2017-02-12
18 (System) Request for posting confirmation emailed to previous authors: "Keyur Patel" , "Randy Bush" , "David Ward" , idr-chairs@ietf.org
2017-02-12
18 Randy Bush Uploaded new revision
2017-02-10
17 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-17.txt
2017-02-10
17 (System) New version approved
2017-02-10
17 (System) Request for posting confirmation emailed to previous authors: "Keyur Patel" , "Randy Bush" , "David Ward" , idr-chairs@ietf.org
2017-02-10
17 Randy Bush Uploaded new revision
2017-02-10
16 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-16.txt
2017-02-10
16 (System) New version approved
2017-02-10
16 (System) Request for posting confirmation emailed to previous authors: "Keyur Patel" , "Randy Bush" , "David Ward" , idr-chairs@ietf.org
2017-02-10
16 Randy Bush Uploaded new revision
2017-02-09
15 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-15.txt
2017-02-09
15 (System) New version approved
2017-02-09
15 (System) Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, "Keyur Patel" , "Randy Bush" , "David Ward"
2017-02-09
15 Randy Bush Uploaded new revision
2017-02-09
14 Susan Hares Changed document writeup
2017-02-08
14 Susan Hares Changed document writeup
2017-02-08
14 Susan Hares Changed consensus to Yes from Unknown
2017-02-08
14 Susan Hares Changed document writeup
2017-02-08
14 Susan Hares Changed document writeup
2016-12-13
14 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-14.txt
2016-12-13
14 (System) New version approved
2016-12-13
14 (System) Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, "Randy Bush" , "Keyur Patel" , "David Ward"
2016-12-13
14 Randy Bush Uploaded new revision
2016-08-26
13 Susan Hares Changed document writeup
2016-06-21
13 Susan Hares Awaiting IPR statements from the authors, and implementation reports.
2016-06-21
13 Susan Hares Tag Other - see Comment Log set. Tag Revised I-D Needed - Issue raised by WGLC cleared.
2016-06-21
13 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-13.txt
2016-06-06
12 Susan Hares Tag Revised I-D Needed - Issue raised by WGLC set.
2016-06-06
12 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-05-24
12 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2016-05-21
12 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-12.txt
2015-10-14
11 (System) Notify list changed from "Susan Hares"  to (None)
2015-10-04
11 Susan Hares Tag Revised I-D Needed - Issue raised by WG cleared.
2015-10-04
11 Susan Hares IETF WG state changed to WG Document from In WG Last Call
2015-09-08
11 Jonathan Hardwick Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Brian Weis.
2015-08-25
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Brian Weis
2015-08-25
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Brian Weis
2015-07-24
11 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-11.txt
2015-07-18
10 Susan Hares This is a WG LC for early adoption allocation.
2015-07-18
10 Susan Hares Tag Revised I-D Needed - Issue raised by WG set.
2015-07-18
10 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2015-07-18
10 Susan Hares This document now replaces draft-ymbk-bgp-extended-messages instead of None
2015-07-18
10 Susan Hares Changed document writeup
2015-07-18
10 Susan Hares Intended Status changed to Proposed Standard from None
2015-07-18
10 Susan Hares Notification list changed to "Susan Hares" <shares@ndzh.com.>
2015-07-18
10 Susan Hares Document shepherd changed to Susan Hares
2015-07-06
10 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-10.txt
2015-01-10
09 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-09.txt
2014-07-21
08 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-08.txt
2014-01-27
07 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-07.txt
2013-08-03
06 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-06.txt
2012-12-24
05 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-05.txt
2012-12-24
04 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-04.txt
2012-07-03
03 Randy Bush New version available: draft-ietf-idr-bgp-extended-messages-03.txt
2012-01-10
02 (System) New version available: draft-ietf-idr-bgp-extended-messages-02.txt
2011-12-30
02 (System) Document has expired
2011-06-28
01 (System) New version available: draft-ietf-idr-bgp-extended-messages-01.txt
2011-06-06
00 (System) New version available: draft-ietf-idr-bgp-extended-messages-00.txt