Re: [Idr] Question about RFC4893

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

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

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