Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-rfc4893bis-07.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'BGP Support for Four-octet AS Number Space'
  (draft-ietf-idr-rfc4893bis-07.txt) as Proposed Standard

This document is the product of the Inter-Domain Routing Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/




Technical Summary

  The Autonomous System (AS) number is encoded as a two-octet entity in
  the base BGP specification. This document describes extensions to BGP
  to carry the Autonomous System numbers as four-octet entities.

  The primary difference between RFC 4893 and this draft is the
  introduction of a detailed Error Handling section. Several other
  requirements are also clarified or added. 

Working Group Summary

  One working group member, John Leslie, contributed a detailed review
  of the draft which suggested extensive changes in terminology. The
  authors disagreed as to the need for the changes. When the chairs put
  the question to the WG directly, there was no support for pushing
  forward with the changes, and some opposition.
  
  During IETF Last Call one reviewer objected to the paragraph in section
  6 stating :
   
  "In addition, the path segment types AS_CONFED_SEQUENCE and
   AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute
   of an UPDATE message.  A NEW BGP speaker that receives these path
   segment types in the AS4_PATH attribute of an UPDATE message from an
   OLD BGP speaker MUST discard these path segments, adjust the relevant
   attribute fields accordingly, and continue processing the UPDATE
   message.  This case SHOULD be logged locally for analysis."

  There was no support for this position and several emails validating
   its inclusion.

Document Quality
 
 The protocol (extension) has been implemented and fielded
  for years and it is generally considered to be a requirement
  for a serious BGP implementation.

Personnel

  The Document Shepherd is John Scudder.
  The Responsible Area Director is Stewart Bryant.


RFC Editor Note

In the metadata please add "Updates: RFC4271" 

=====

In the Abstract
Old
This document obsoletes RFC 4893.
New
This document obsoletes RFC 4893 and updates RFC4271
End

=====

Before section 8 add a new section with the following title and 
text:

<heading> Manageability Considerations

If  BGP-4 MIB [RFC4273] is supported, there are no additional 
manageability concerns that arise with from the use of four octet AS 
numbers, since the  InetAutonomousSystemNumber textual convention is 
defined as an  unsigned32.

When IPFIX export [RFC5101] is supported, there are no additional 
manageability concerns that arise from the use of four octet AS numbers. 
The bgpSourceAsNumber and  bgpDestinationAsNumber information elements 
[http://www.iana.org/assignments/ipfix/ipfix.xml] can continued to be 
used,  with a new template record, specifying the new length of 4 bytes.

===

Please add informational reference 
[http://www.iana.org/assignments/ipfix/ipfix.xml]

===

At the end of the Introduction

OLD:
   This document obsoletes RFC 4893, and a comparison with RFC 4893 is
   provided in Appendix A.

NEW:
   This document obsoletes RFC 4893. It includes several clarifications 
   and editorial changes, and specifies the error handling for the new 
   attributes.
END

===

Please delete Appendix A

===