[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] Question about RFC4893
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:enkechen at cisco.com]
> Sent: Friday, October 09, 2009 12:11 PM
> To: Samita Chakrabarti
> Cc: ben_april at trendmicro.com; idr at ietf.org; 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
> >
> >