Subject: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt]

From: Enke Chen <[email-masked]>
Date: Wed, 07 Feb 2007 13:53:15 -0800

Hi, folks:

The revised version addresses several comments from the IESG review, 
including:

      o IANA Considerations
      o Security Considerations
      o Attribute Naming

Please note these changes to the attribute names (the type codes are 
unchanged):

     NEW_AS_PATH             --->   AS4_PATH
     NEW_AGGREGATOR   --->   AS4_AGGREGATOR

Thanks.   -- Enke

-------- Original Message --------
Subject: 	I-D ACTION:draft-ietf-idr-as4bytes-13.txt
Date: 	Wed, 07 Feb 2007 15:50:02 -0500
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]
CC: 	[email-masked]

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

	Title		: BGP Support for Four-octet AS Number Space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-13.txt
	Pages		: 10
	Date		: 2007-2-7
	
Currently the Autonomous System number is encoded as a two-octet
   entity in BGP. This document describes extensions to BGP to carry the
   Autonomous System number as a four-octet entity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-idr-as4bytes-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-as4bytes-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Wed, 7 Feb 2007 19:28:02 -0500

>     NEW_AGGREGATOR   --->   AS4_AGGREGATOR

   I attach an abbreviated diff with context for changes other than those.
Note in Section 4.1 "MAY advertise" becomes "SHOULD advertise", and in
Section 6 "SHOULD NOT use AS_TRANS" becomes "MUST NOT use AS_TRANS".

   Section 7 now includes actual assigned values, and explicitly disclaims
any intent to modify allocation policies and procedures.

   Section 8 adds a Security Consideration, which deserves to be read
carefully.

-------------------------------- cut here --------------------------------
3. Protocol Extensions
     attribute has the same semantics as the AGGREGATOR attribute, except
<    that it carries 4-octet AS numbers.
---
     attribute has the same semantics as the AGGREGATOR attribute, except
>    that it carries a 4-octet AS number.
****
     Currently assigned 2-octet Autonomous System numbers are converted
<    into 4-octet Autonomous System numbers by setting the high-order 2
     octets of the 4-octet field to zero. Such a 4-octet AS number is said
---
     Currently assigned 2-octet Autonomous System numbers are converted
>    into 4-octet Autonomous System numbers by setting the two high-order
     octets of the 4-octet field to zero. Such a 4-octet AS number is said
****
4.1. Interaction Between NEW BGP Speakers
<    A BGP speaker that supports 4-octet Autonomous System numbers MAY
     advertise this to its peers using the BGP Capability Advertisements.
---
>    A BGP speaker that supports 4-octet Autonomous System numbers SHOULD
     advertise this to its peers using the BGP Capability Advertisements.
****
6. Transition
<    An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System
     number.
---
>    An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System
     number.
****
7. IANA Considerations
<    This document makes the four-octet, unsigned integers larger than
<    65535 available for allocation as AS numbers. These AS numbers need
<    to be managed by the IANA "Autonomous System Numbers" registry.
---
>    This document expands the pool for AS numbers from 0 - 65535 to 0 -
>    4294967295.  The AS numbers are managed by the IANA "Autonomous
>    System Numbers" registry.  Other than expanding the AS number pool,
>    this document does not propose any modifications to the existing
>    policies and procedures pertaining to the AS number allocation.
****
     This document uses a BGP Capability code to indicate that a BGP
<    speaker supports the 4-octet AS numbers.  The Capability code has
     been assigned by IANA per RFC 2842.
---
     This document uses a BGP Capability code to indicate that a BGP
>    speaker supports the 4-octet AS numbers.  The Capability Code 65 has
     been assigned by IANA per RFC 2842.
****
     In addition, this document introduces two new BGP optional transitive
<    attributes. The first is the NEW_AS_PATH attribute, which preserves
<    the AS path information with 4-octet AS numbers across old BGP
<    speakers. The second is the NEW_AGGREGATOR attribute, which is
<    similar in use to the current AGGREGATOR attribute but it carries
<    4-octet AS numbers.  The Type Codes for these attributes have been
<    assigned by IANA.
---
     In addition, this document introduces two new BGP optional transitive
>    attributes, and their type codes have been assigned by the IANA.  The
>    first one is the AS4_PATH attribute, value 17, which preserves the AS
>    path information with 4-octet AS numbers across old BGP speakers. The
>    second one is the AS4_AGGREGATOR attribute, value 18, which is
>    similar in use to the current AGGREGATOR attribute but it carries a
>    4-octet AS number.
****
     Finally, this document introduces a reserved 2-octet AS number -
<    AS_TRANS.  The AS number for AS_TRANS has been assigned by the IANA.
---
     Finally, this document introduces a reserved 2-octet AS number -
>    AS_TRANS. The AS number 23456 has been assigned by the IANA for
>    AS_TRANS.
****
8. Security Considerations
     This extension to BGP does not change the underlying security issues
<    inherent in the existing BGP.
---
     This extension to BGP does not change the underlying security issues
>    inherent in the existing BGP, except for the following:
> 
>    The inconsistency between the AS_PATH attribute and the AS4_PATH
>    attribute can create loss of the AS path information, and potential
>    routing loops in certain cases as discussed in the document. This
>    coule be exploited by an attacker.
****
9. Acknowledgments
     The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina,
     and Jeffrey Haas for the numerous discussions which went into the
<    making of this draft.
---
     The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina,
     and Jeffrey Haas for the numerous discussions which went into the
>    making of this document.
****
10. Normative References
     [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
<    4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
---
     [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
>    4 (BGP-4)", RFC 4271, January 2006.
****
12. Authors' Information
     Quaizar Vohra
<    Juniper Networks
<    1194 N. Mathilda Ave
<    Sunnyvale, CA 94089
<
<    Email: [email-masked]
---
     Quaizar Vohra
>    Nuova Systems
>    2600 San Tomas Expressway
>    Santa Clara, CA 95051
> 
>    Email: [email-masked]
-------------------------------- cut here --------------------------------
 
--
John Leslie <[email-masked]>

---

From: "Erik Romijn" <[email-masked]>
Date: Fri, 9 Feb 2007 15:58:04 +0100

> >     NEW_AGGREGATOR   --->   AS4_AGGREGATOR

Perhaps a stupid question, but why not go for "AS4 speaker" and "AS2
speaker" too instread of "NEW/OLD speaker"?

cheers,
-- 
Erik Romijn                 RIPE NCC jr. software engineer
http://www.ripe.net/        Information Services dept.
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Enke Chen <[email-masked]>
Date: Fri, 09 Feb 2007 18:05:26 -0800

Hi, Erik:

> speaker" too instread of "NEW/OLD speaker"?

Because the terminologies "NEW/OLD speaker" do not refer to protocol 
code points . They are used in the document only for the sake of 
presentation, and they seem to be a good fit for the intended purpose.

-- Enke

---

From: Geoff Huston <[email-masked]>
Date: Tue, 13 Feb 2007 15:58:08 +1100

>speaker" too instread of "NEW/OLD speaker"?

And that would change the code to support for these larger AS numbers 
in a BGP implementation in what way?

At some point its time to stop polishing documents in all kinds of 
wonderful and inventive ways and make the pragmatic judgement that 
its good enough to support running inter-operable code. I suspect 
that this particular draft got to that state of adequacy at least 4 
revs ago, and probably more. Lets face it, nothing in the 12 - 13 rev 
changes the code (and yes, I've implemented this spec, so I speak 
with some experience here). So why are we doing this document polishing?

(no, please don't tell me - sadly, I already know the answer!)

regards,

    Geoff