[Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.tx

Yakov Rekhter <yakov@juniper.net> Mon, 18 June 2007 13:56 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HiU-0003D4-UV; Mon, 18 Jun 2007 09:56:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HiS-00039Z-Lw for idr@ietf.org; Mon, 18 Jun 2007 09:56:24 -0400
Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HiR-0004CM-T3 for idr@ietf.org; Mon, 18 Jun 2007 09:56:24 -0400
Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Jun 2007 06:56:23 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5IDuFJ42073; Mon, 18 Jun 2007 06:56:19 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200706181356.l5IDuFJ42073@merlot.juniper.net>
To: idr-ads@tools.ietf.org
Subject: [Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.tx
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <37476.1182174975.1@juniper.net>
Date: Mon, 18 Jun 2007 06:56:15 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951
Cc: skh@nexthop.com, 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

Dave and Ross,

The IDR WG completed the Last Call on draft-ietf-idr-rfc3065bis-06.
The document is ready for publication as Draft Standard.

Yakov.
------- Forwarded Message

Date:    Sun, 03 Jun 2007 20:33:07 -0700
From:    Yakov Rekhter <yakov@juniper.net>
To:      idr@ietf.org
Subject: [Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.tx
	  t

Folks,

This is to start the IDR WG Last Call on draft-ietf-idr-rfc3065bis-06.txt.
Please note that the scope of this Last Call is limited to only the 
revised text.  

The Last Call ends on June 17.

Yakov.
- ------- Forwarded Message

Date:    Sun, 03 Jun 2007 22:37:21 -0400
From:    "John G. Scudder" <jgs@bgp.nu>
To:      idr@ietf.org
cc:      John Scudder <jgs@juniper.net>
Subject: [Idr] draft-ietf-idr-rfc3065bis-06.txt editorial change

Folks,

While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the  
vigilant RFC Editor pointed out several nits with the draft.  Most  
can be resolved as minor editorial changes, however, one of them is  
slightly more than that.

Section 4.1 of the draft ("AS_PATH Modification Rules") is  
essentially a cut-n-paste of section 5.1.2 of the base spec, with  
necessary changes for confederations.  Unfortunately, we did not  
revise the draft to match when the base spec was revised.

To correct this, we propose to re-do section 4.1.  There are no  
changes of any substance compared to earlier versions, i.e. the  
intent is still to say "do what the base spec does, only do it with  
confed-type segments", but the text is brought into line with RFC 4271.

The change is extensive enough that we thought it worthwhile to poll  
the WG again.  Chairs, please consider this a request for a WGLC,  
only on this revised text.

Thanks,

- - --John (with Danny and Paul)

Revised section 4.1:

4.1.  AS_PATH Modification Rules

    AS_PATH is a well-known mandatory attribute.  This attribute
    identifies the autonomous systems through which routing information
    carried in this UPDATE message has passed.  The components of this
    list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or
    AS_CONFED_SEQUENCES.

    When a BGP speaker propagates a route it learned from another BGP
    speaker's UPDATE message, it modifies the route's AS_PATH attribute
    based on the location of the BGP speaker to which the route will be
    sent:

    a) When a given BGP speaker advertises the route to another BGP
       speaker located in its own Member-AS, the advertising speaker
       SHALL NOT modify the AS_PATH attribute associated with the
       route.

    b) When a given BGP speaker advertises the route to a BGP speaker
       located in a neighboring autonomous system that is a member of
       the local confederation, the advertising speaker updates
       the AS_PATH attribute as follows:

       1) if the first path segment of the AS_PATH is of type
          AS_CONFED_SEQUENCE, the local system prepends its own  
Member-AS
          number as the last element of the sequence (put it in the
          leftmost position with respect to the position of octets in  
the
          protocol message).  If the act of prepending will cause an
          overflow in the AS_PATH segment (i.e., more than 255 ASes), it
          SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
          prepend its own AS number to this new segment.

       2) if the first path segment of the AS_PATH is not of type
          AS_CONFED_SEQUENCE the local system prepends a new path
          segment of type AS_CONFED_SEQUENCE to the AS_PATH, including
          its own Member-AS Number in that segment.

       3) if the AS_PATH is empty, the local system creates a path
          segment of type AS_CONFED_SEQUENCE, places its own Member-AS
          Number into that segment, and places that segment into the
          AS_PATH.

    c) When a given BGP speaker advertises the route to a BGP speaker
       located in a neighboring autonomous system that is not a  
member of
       the local confederation, the advertising speaker SHALL update the
       AS_PATH attribute as follows:

       1) if any path segments of the AS_PATH are of the type
          AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST
          be removed from the AS_PATH attribute, leaving the sanitized
          AS_PATH attribute to be operated on by steps 2, 3 or 4.

       2) if the first path segment of the remaining AS_PATH is of type
          AS_SEQUENCE, the local system prepends its own AS  
Confederation
          Identifier as the last element of the sequence (put it in
          the leftmost position with respect to the position of
          octets in the protocol message).  If the act of prepending
          will cause an overflow in the AS_PATH segment (i.e., more
          than 255 ASes), it SHOULD prepend a new segment of type
          AS_SEQUENCE and prepend its own AS number to this new
          segment.

       3) if the first path segment of the remaining AS_PATH is of type
          AS_SET, the local system prepends a new path segment of
          type AS_SEQUENCE to the AS_PATH, including its own AS
          Confederation Identifier in that segment.

       4) if the remaining AS_PATH is empty, the local system creates
          a path segment of type AS_SEQUENCE, places its own AS
          Confederation Identifier into that segment, and places
          that segment into the AS_PATH.

    When a BGP speaker originates a route then:

    a) the originating speaker includes its own AS Confederation
       Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH
       attribute of all UPDATE messages sent to BGP speakers located in
       neighboring autonomous systems that are not members of the local
       confederation.  In this case, the AS Confederation Identifier of
       the originating speaker's autonomous system will be the only  
entry
       the path segment, and this path segment will be the only segment
       in the AS_PATH attribute.

    a) the originating speaker includes its own Member-AS Number in a
       path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH  
attribute
       of all UPDATE messages sent to BGP speakers located in  
neighboring
       Member Autonomous Systems that are members of the local
       confederation.  In this case, the Member-AS Number of the
       originating speaker's autonomous system will be the only entry  
the
       path segment, and this path segment will be the only segment in
       the AS_PATH attribute.

    c) the originating speaker includes an empty AS_PATH attribute in
       all UPDATE messages sent to BGP speakers residing within the same
       Member-AS.  (An empty AS_PATH attribute is one whose length field
       contains the value zero).

    Whenever the modification of the AS_PATH attribute calls for
    including or prepending the AS Confederation Identifier or
    Member-AS Number of the local system, the local system MAY
    include/prepend more than one instance of that value in the
    AS_PATH attribute.  This is controlled via local configuration.


Diff vs. draft-ietf-idr-rfc3065bis-06.txt (ends up including pretty  
much the whole section):

3,10c3,12
<
<    When implementing BGP Confederations Section 5.1.2 of [BGP-4] is
<    replaced with the following text:
<
<    When a BGP speaker propagates a route which it has learned from
<    another BGP speaker's UPDATE message, it SHALL modify the route's
<    AS_PATH attribute based on the location of the BGP speaker to which
<    the route will be sent:
- - ---
 >    AS_PATH is a well-known mandatory attribute.  This attribute
 >    identifies the autonomous systems through which routing  
information
 >    carried in this UPDATE message has passed.  The components of this
 >    list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or
 >    AS_CONFED_SEQUENCES.
 >
 >    When a BGP speaker propagates a route it learned from another BGP
 >    speaker's UPDATE message, it modifies the route's AS_PATH  
attribute
 >    based on the location of the BGP speaker to which the route  
will be
 >    sent:
19c21
<       the local confederation, the advertising speaker SHALL update
- - ---
 >       the local confederation, the advertising speaker updates
23,25c25,31
<          AS_CONFED_SEQUENCE, the local system SHALL prepend its own
<          Member-AS Number as the last element of the sequence (put
<          it in the leftmost position).
- - ---
 >          AS_CONFED_SEQUENCE, the local system prepends its own  
Member-AS
 >          number as the last element of the sequence (put it in the
 >          leftmost position with respect to the position of octets  
in the
 >          protocol message).  If the act of prepending will cause an
 >          overflow in the AS_PATH segment (i.e., more than 255  
ASes), it
 >          SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
 >          prepend its own AS number to this new segment.
28c34
<          AS_CONFED_SEQUENCE the local system SHALL prepend a new path
- - ---
 >          AS_CONFED_SEQUENCE the local system prepends a new path
31a38,42
 >       3) if the AS_PATH is empty, the local system creates a path
 >          segment of type AS_CONFED_SEQUENCE, places its own Member-AS
 >          Number into that segment, and places that segment into the
 >          AS_PATH.
 >
40c51
<          AS_PATH attribute to be operated on by steps 2 or 3.
- - ---
 >          AS_PATH attribute to be operated on by steps 2, 3 or 4.
43,51c54,65
<          AS_SEQUENCE, the local system SHALL prepend its own
<          AS Confederation Identifier as the last element of the  
sequence
<          (put it in the leftmost position).
<
<       3) if there are no path segments following the removal of the
<          first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the
<          first path segment of the remaining AS_PATH is not of type
<          AS_SEQUENCE the local system SHALL prepend a new path segment
<          of type AS_SEQUENCE to the AS_PATH, including its own AS
- - ---
 >          AS_SEQUENCE, the local system prepends its own AS  
Confederation
 >          Identifier as the last element of the sequence (put it in
 >          the leftmost position with respect to the position of
 >          octets in the protocol message).  If the act of prepending
 >          will cause an overflow in the AS_PATH segment (i.e., more
 >          than 255 ASes), it SHOULD prepend a new segment of type
 >          AS_SEQUENCE and prepend its own AS number to this new
 >          segment.
 >
 >       3) if the first path segment of the remaining AS_PATH is of  
type
 >          AS_SET, the local system prepends a new path segment of
 >          type AS_SEQUENCE to the AS_PATH, including its own AS
54,63c68,86
<    When a BGP speaker originates a route:
<
<    a) the originating speaker SHALL include an empty AS_PATH attribute
<       in all UPDATE messages sent to BGP speakers residing within the
<       same Member-AS.  (An empty AS_PATH attribute is one whose length
<       field contains the value zero).
<
<    b) the originating speaker SHALL include its own Member-AS  
Number in
<       an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all
<       UPDATE messages sent to BGP speakers located in neighboring
- - ---
 >       4) if the remaining AS_PATH is empty, the local system creates
 >          a path segment of type AS_SEQUENCE, places its own AS
 >          Confederation Identifier into that segment, and places
 >          that segment into the AS_PATH.
 >
 >    When a BGP speaker originates a route then:
 >
 >    a) the originating speaker includes its own AS Confederation
 >       Identifier in a path segment, of type AS_SEQUENCE, in the  
AS_PATH
 >       attribute of all UPDATE messages sent to BGP speakers  
located in
 >       neighboring autonomous systems that are not members of the  
local
 >       confederation.  In this case, the AS Confederation  
Identifier of
 >       the originating speaker's autonomous system will be the only  
entry
 >       the path segment, and this path segment will be the only  
segment
 >       in the AS_PATH attribute.
 >
 >    a) the originating speaker includes its own Member-AS Number in a
 >       path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH  
attribute
 >       of all UPDATE messages sent to BGP speakers located in  
neighboring
65,66c88,102
<       confederation (i.e., the originating speaker's Member-AS Number
<       will be the only entry in the AS_PATH attribute).
- - ---
 >       confederation.  In this case, the Member-AS Number of the
 >       originating speaker's autonomous system will be the only  
entry the
 >       path segment, and this path segment will be the only segment in
 >       the AS_PATH attribute.
 >
 >    c) the originating speaker includes an empty AS_PATH attribute in
 >       all UPDATE messages sent to BGP speakers residing within the  
same
 >       Member-AS.  (An empty AS_PATH attribute is one whose length  
field
 >       contains the value zero).
 >
 >    Whenever the modification of the AS_PATH attribute calls for
 >    including or prepending the AS Confederation Identifier or
 >    Member-AS Number of the local system, the local system MAY
 >    include/prepend more than one instance of that value in the
 >    AS_PATH attribute.  This is controlled via local configuration.
68,74d103
<    c) the originating speaker SHALL include its own AS Confederation
<       Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of
<       all UPDATE messages sent to BGP speakers located in neighboring
<       autonomous systems that are not members of the local
<       confederation.  (In this case, the originating speaker's AS
<       Confederation Identifier will be the only entry in the AS_PATH
<       attribute).



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

- ------- End of Forwarded Message

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

------- End of Forwarded Message

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