Re: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

"Samita Chakrabarti" <> Thu, 06 March 2008 01:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB6E228C5ED; Wed, 5 Mar 2008 17:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.851
X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_55=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUe1GfyP-Fbz; Wed, 5 Mar 2008 17:12:13 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id CECD628C5F5; Wed, 5 Mar 2008 17:12:13 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2F7928C5F5 for <>; Wed, 5 Mar 2008 17:12:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USzg4Ua+z4V4 for <>; Wed, 5 Mar 2008 17:12:12 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 125F828C5ED for <>; Wed, 5 Mar 2008 17:12:11 -0800 (PST)
Received: from samitacD600 ([]) by (8.11.6/8.11.6) with ESMTP id m261Bhc28261; Wed, 5 Mar 2008 17:11:43 -0800
From: Samita Chakrabarti <>
To: 'Geoff Huston' <>
References: <> <005b01c87e67$926edf10$89000a0a@samitacD600> <>
Date: Wed, 05 Mar 2008 17:11:46 -0800
Message-ID: <004501c87f27$0fab5d40$89000a0a@samitacD600>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Ach+fxUZoqAmW4TyRrG5ydnIfayv6wApcs3A
In-Reply-To: <>
Cc: 'idr' <>
Subject: Re: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Geoff,

>>    When transition is over, a BGP speaker can use AS4_PATH only. It is a
>> simple concept and no overloading.
>But there is no way for any individual BGP speak to know when transition
>is "over". I have to agree with Enke in observing that the proposal is
>indeed backwards.
[SC>]  I did not mean that a BGP speaker would know when the transition is
over. I mentioned that transition period would be long. During that period
both AS_PATH and AS4_PATH will exist and the transition border NEW BGP
speaker does not need to do 2byte<->4byte AS_PATH, AS_AGGREGATOR conversion.

But, Enke mentions that similar proposal was discussed before and not
adopted. In that case I'll not push for this particular proposal. But it is
true that RFC 4893 is overloading AS_PATH sometimes with 2byte and sometimes
with 4bytes values, the NEW speaker will have to carefully take care of this
situation. It could lead into error-prone implementations.

>>>-) On Issue - 4:
>> */[SC>] I talked with a few people at NANOG who experienced that
>> AS_TRANS value was used often as AS number in the current BGP
>> deployment. We can not expect that every operator or administrator is
>> fully aware of reserved AS_TRANS value for this special purpose.
>I'm sorry, but this is a specious line of reasoning.
>Overall I see noting of use in this draft to warrant modification of

[SC>] What is the objection against introducing a notification message to
the OLD BGP speaker from a NEW BGP speaker when it receives AS_TRANS in OPEN
message without AS4 capability?  This is quite useful for transition.


Idr mailing list