Re: [Idr] Question about RFC4893

"Samita Chakrabarti" <samitac@ipinfusion.com> Fri, 09 October 2009 18:06 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 E534428C168 for <idr@core3.amsl.com>; Fri, 9 Oct 2009 11:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 R7gbigO9qO5J for <idr@core3.amsl.com>; Fri, 9 Oct 2009 11:06:01 -0700 (PDT)
Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id 7FD5D28C0F0 for <idr@ietf.org>; Fri, 9 Oct 2009 11:06:01 -0700 (PDT)
Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000
Received: from [68.142.201.69] by t5.bullet.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000
Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000
X-Yahoo-Newman-Id: 57833.52291.bm@omp421.mail.mud.yahoo.com
Received: (qmail 23405 invoked from network); 9 Oct 2009 18:07:44 -0000
Received: from (samitac@65.223.109.250 with login) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 09 Oct 2009 11:07:44 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: 9dS4_6cVM1kafUW9Cu3bCBrhkHyWH6dZlEOSoD6oOycnKWb20EWxhWbH6ofXjyEk_4.eSQ1l_FX5IWETUb0gN4VoKbXFPnh9q.fAv4YWD8ZqGHuYtAxK5ub0GN16hErKcm.WykxOcS7aBXecmBioO8rZuf4l9vkiWD6WJv4jGGAkDY1Ou5OOXhtfG6zbPArV66BhsYgavWmrYWzcj.rNOa6AlNQfAzXjGorJ6FgAtLgX0XN3ZJN6Z0sixI7IRrzaw8gTnqXwBTj7qgkwfIiSyv_47hXFnGts_Q--
X-Yahoo-Newman-Property: ymail-3
From: Samita Chakrabarti <samitac@ipinfusion.com>
To: ben_april@trendmicro.com, idr@ietf.org
References: <4ACF6B32.7030209@trendmicro.com>
In-Reply-To: <4ACF6B32.7030209@trendmicro.com>
Date: Fri, 09 Oct 2009 11:07:42 -0700
Message-ID: <00d801ca490b$65507500$2ff15f00$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpJARgBY55GtpWiQxyQFA/QbJVeLgABVUAQ
Content-Language: en-us
Subject: Re: [Idr] Question about RFC4893
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: Fri, 09 Oct 2009 18:06:03 -0000

Hi Ben,

Please see below:

> If the number of AS numbers in the AS_PATH attribute is larger than or
equal
> to the number of AS numbers in the AS4_PATH attribute, then the AS path
> information SHALL be constructed by taking as many AS numbers and path
> segments as necessary from the leading part of the AS_PATH attribute, and
> then prepending them to the AS4_PATH attribute so that the AS path
> information has an identical number of AS numbers as the AS_PATH
attribute.
> 
> 
> 
> Forgive me, but this all sounds like an awful lot of hand-waving to me.
Has
> anything been done since this RFC was published to better describe in a
more
> formal way the procedure a BGP speaker should follow to re-construct an
> accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on this
> description I can see more than one way to implement this. I would like to
> do so correctly, but I need to know what is correct first.
> 
> Thanks
> Ben
> 
[SC>] 

I agree with you completely this handwaving portion in rfc 4893 is very
problematic to the implementers who were not directly involved in the making
of RFC 4893. I was not one of them.  In 2008, I wrote a draft pointing out
some of the problems we faced during implementation and to request an update
of the RFC for future interoperability. Also presented the draft at WG in
Spring 2008 IETF. Rfc4893-bis has considered some of the problems mentioned
in the draft + others discussed in the working group alias.
http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/

The following interpretation has been made in our implementation after
talking with some other implementers.
I believe rfc4893-bis now has the similar text:
1.	If the number of ASNs in AS_PATH is less than the number of ASNs in
AS4_PATH, then NBGP ignores AS4_PATH  information.
Example:
AS_PATH:   2 23456
AS4_PATH: 70000 70001 70002

2.	If the number of ASNs in AS_PATH attribute is greater than number of

         ASNs in AS4_PATH attribute, then there must be a few AS_TRANS 
        numbers in AS_PATH.  Reconstruct AS_PATH based on the AS4_PATH 
       items corresponding to  AS_TRANS numbers 
      Examples:
      AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456
      AS4_PATH: 65356, 77777
3.	If the number of ASNs in AS_PATH and AS4_PATH attributes is same
then it most likely means that all the AS numbers are AS4-byte unmappable
numbers.  Check the count of AS_TRANS numbers in AS_PATH and count of AS
numbers in AS4_PATH.  If they are the same then reconstruct AS information
from AS4_PATH only (note this case is for AS num == AS4 num). If number of
AS_TRANS in AS_PATH is less than the number in AS4_PATH values, then there
is something wrong done by previous speakers. However, take the non-AS_TRANS
AS values from AS_PATH  and then prepend them with the AS4 values. Some
examples will clarify this case:
AS_PATH:   23456, 23456,  23456
AS4_PATH: 777777, 66666, 88888
Or
AS_PATH: 2, 3, 4, 23456
AS4_PATH: 88888, 99999, 70000, 80000

Thanks,
-Samita