Re: [Idr] Question about RFC4893

["Samita Chakrabarti" <[e-mail]>]

Hi Enke,

I am OK with the current text in rfc4893-bis that you already pointed out.

I provided some additional examples for clarification and for the purpose of
discussion.

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