[Idr] Clarification points for rfc4893-bis

"Samita Chakrabarti" <samitac@ipinfusion.com> Thu, 26 March 2009 02:26 UTC

Return-Path: <samitac@ipinfusion.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBDB28C22B for <idr@core3.amsl.com>; Wed, 25 Mar 2009 19:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3VZ5cLqt0WO for <idr@core3.amsl.com>; Wed, 25 Mar 2009 19:26:07 -0700 (PDT)
Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id F2A8728C265 for <idr@ietf.org>; Wed, 25 Mar 2009 19:26:06 -0700 (PDT)
Received: from [68.142.200.226] by n11.bullet.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 02:27:00 -0000
Received: from [68.142.201.246] by t7.bullet.mud.yahoo.com with NNFMP; 26 Mar 2009 02:26:59 -0000
Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 02:26:59 -0000
X-Yahoo-Newman-Id: 781128.35817.bm@omp407.mail.mud.yahoo.com
Received: (qmail 86741 invoked from network); 26 Mar 2009 02:26:59 -0000
Received: from unknown (HELO samitacD630) (samitac@130.129.16.141 with login) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2009 02:26:58 -0000
X-YMail-OSG: TqGkB2wVM1lbu3vROVr5tmUVfYiTvqs42WW8YRV_zDNAO0mZd_1fLbtAnHB6HkuR_wp5liKa6z95p5fjvVKuvK2TeTpizJ98yDWYlJ0DHoXSmK2G79v39dqOPhgBxwMbdf9W_9YoBfLjOgQRbBKOXPAjhNTvtIWlvnQ_7RewVRAFI98GSe2vliIE
X-Yahoo-Newman-Property: ymail-3
From: Samita Chakrabarti <samitac@ipinfusion.com>
To: enkechen@cisco.com
Date: Wed, 25 Mar 2009 19:26:58 -0700
Message-ID: <065b01c9adba$56d5bc20$04813460$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_065C_01C9AD7F.AA76E420"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmtulZjlkfqEMXbRbekghFsuwBDCw==
Content-Language: en-us
Cc: idr@ietf.org
Subject: [Idr] Clarification points for rfc4893-bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 02:26:12 -0000

Hi Enke,

 

This is a follow-up from the idr meeting comments. I'd like to thank you for
your kind consideration in taking into some of the comments addressed in
draft-chakrabarti-idr-rfc4893-mod.

 

Here are few cases that I propose to clarify in the next revision of the
rfc4893-bis and I think these will be helpful for new readers and
implementers especially considering the fact that 2byte ASes and 4byte ASes
are going to co-exist for sometime.

 

Clarification 1:

Section 3: "My AS Number" field

Currently it says:

"  and "We denote this special AS number as AS_TRANS for ease of

   description in the rest of this specification.  This AS number is

   also placed in the "My Autonomous System" field of the OPEN message

   originated by a NEW BGP speaker, if the speaker does not have a

   (globally unique) 2-octet AS number."

 

   The clarification would be useful : 1) When 4-byte AS number capability
message is
   present and the receiver is able to process the capability message,
   should it ignore the AS number field in the OPEN message and use the
AS-number present in the capability message?
 
 
Clarification 2:
Minor nit: "truly 4-octet" should be defined as a quantity higher
   than 65535.
 
   Should the NEW BGP speaker send a NOTIFICATION message when it
   receives a OPEN message with AS_TRANS but without any corresponding
   capability message ?  Note that although AS_TRANS(23456) is a
   reserved number now, it is still possible to receive a OPEN message
   with AS_TRANS value from an OLD BGP speaker or from a ill-behaving
   NEW BGP speaker.
 
Proposal for a NOTIFICATION message
 
   When two BGP speakers correspond with each other by sending AS_TRANS
   value in the 'My AS number' field, then the OPEN message MUST contain
   the 4-octet AS number capability option.  If the 4-octet capability
   is missing in OPEN message where the 'My AS Number' field contains
   AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification
   with code=2, subcode=2 [bad peer AS] to the sender of the OPEN
   message.
 
 

Clarification on section 6 (Transition)

How about some more text on PE-CE cases? Especially the AS_OVERRIDE issue as
identified in

http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please
check-out slide 11]

 

 

Thanks,

-Samita