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

The IESG <> Fri, 05 October 2012 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7205121F8766; Fri, 5 Oct 2012 11:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vgk3MJX1t49Z; Fri, 5 Oct 2012 11:24:05 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id AAEBC21F8555; Fri, 5 Oct 2012 11:24:00 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-rfc4893bis-07.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <>
Date: Fri, 05 Oct 2012 11:24:00 -0700
Cc: idr mailing list <>, idr chair <>, RFC Editor <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Oct 2012 18:24:07 -0000

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:

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.


  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
This document obsoletes RFC 4893.
This document obsoletes RFC 4893 and updates RFC4271


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

<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 
[] can continued to be 
used,  with a new template record, specifying the new length of 4 bytes.


Please add informational reference 


At the end of the Introduction

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

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


Please delete Appendix A