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