[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Idr] Question about RFC4893

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