Re: [Idr] Question about RFC4893

[Enke Chen <[e-mail]>]

Samita:

We can argue about the presentation style and other portions in 
RFC4893.  However,  IMO the specific
merge algorithm is complete, and precise,  as I pointed out to Ben.

Please see my comments inlined.

Samita Chakrabarti wrote:
> 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
>   

RFC 4893 has the following text in Sect. 4.2.3:

   If the number of AS numbers in the AS_PATH attribute is less than the
   number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
   attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
   as the AS path information.

--------------------------------------------

I am wondering why this portion needed "interpretation" in your 
implementation.


> 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
>   

So what exactly is the problem with following RFC 4893 in this case?   
The (AS_PATH, AS4_PATH) is
not really consistent here -- that is, 65356 is not represented in 
AS_PATH, and there is an extra 23456 in
the middle.  Most likely this is a crafted, lab scenario in which there 
is no single "correct" answer.

> 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
>   

So the merged as-path would consist of the valid AS numbers 777777, 
66666, 88888 based on RFC 4893.
This seems fine.  Isn't it?

> Or
> AS_PATH: 2, 3, 4, 23456
> AS4_PATH: 88888, 99999, 70000, 80000
>   

This again is another inconsistent, artificially crafted scenario.  
Possibly there are more than one "correct"
solutions, some more "correct" than others - depending on how the 
inconsistency was generated. As
the as-path length must be maintained during the merge, no solution can 
possibly include all the valid AS
numbers contained in AS_PATH / AS4_PATH.

RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one.  Why 
wouldn't it be good enough?

Thanks.    -- Enke