Re: [Idr] Question about RFC4893

[Enke Chen <[e-mail]>]

Hi, Samita:

Samita Chakrabarti wrote:
> Hi Enke,
>
> You are right in pointing out that there is no change from RFC4893 merging
> text into the bis versions . I replied too fast. It's been a long time since
> we implemented this, but I remember it was not clear at that time and we had
> to do some interpretation of the text in RFC.
>
> Below, you have discussed the merged AS-PATH examples with the sample
> scenarios I provided.
> Do you think you can include some of those examples in the text for
> clarification? That might be helpful for the future implementations for
> clarity. Just a suggestion...
>   

If we agree that the merge algorithm described in the document is 
applicable for
these examples (mostly with crafted, inconsistent data), then I am not 
sure if there
is still value in including them in rfc4893bis.

Regards,   -- Enke

> Thanks,
> -Samita
>
>   
>> -----Original Message-----
>> From: Enke Chen [mailto:[e-mail]]
>> Sent: Friday, October 09, 2009 12:11 PM
>> To: Samita Chakrabarti
>> Cc: [e-mail]; [e-mail]; Enke Chen
>> Subject: Re: [Idr] Question about RFC4893
>>
>> 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
>>>
>>>
>>>       
>
>
>
>