[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
- [Idr] Clarification points for rfc4893-bis Samita Chakrabarti
- Re: [Idr] Clarification points for rfc4893-bis Enke Chen
- Re: [Idr] Clarification points for rfc4893-bis Samita Chakrabarti
- Re: [Idr] Clarification points for rfc4893-bis Enke Chen