Re: [Idr] Question about RFC4893

[Enke Chen <[e-mail]>]

BTW,  based on the on-line IETF track tool, there has been no change in 
the merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and 
to rfc4893bis-01.txt:

          
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-00.txt
          
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-01.txt

Regards,   -- Enke

Enke Chen wrote:
> 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
>
>