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

John Leslie <john@jlc.net> Thu, 08 February 2007 00:28 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8x-000181-H1; Wed, 07 Feb 2007 19:28:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8v-00017w-Pr for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEx8u-0001ed-CG for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500
Received: by mailhost.jlc.net (Postfix, from userid 104) id D36F71CC1E; Wed, 7 Feb 2007 19:28:02 -0500 (EST)
Date: Wed, 07 Feb 2007 19:28:02 -0500
From: John Leslie <john@jlc.net>
To: Enke Chen <enkechen@cisco.com>
Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt]
Message-ID: <20070208002802.GD2308@verdi>
References: <45CA4A4B.4040108@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <45CA4A4B.4040108@cisco.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Enke Chen <enkechen@cisco.com> wrote:
> 
> Please note these changes to the attribute names (the type codes are 
> unchanged):
> 
>     NEW_AS_PATH             --->   AS4_PATH
>     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: qv@juniper.net
---
     Quaizar Vohra
>    Nuova Systems
>    2600 San Tomas Expressway
>    Santa Clara, CA 95051
> 
>    Email: qv@nuovasystems.com
-------------------------------- cut here --------------------------------
 
--
John Leslie <john@jlc.net>

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr