Hi Enke,
Thanks for your reply.
On Mon, Jan 26, 2009 at 03:15:20PM -0800, Enke Chen wrote:
Stripping the confed path segments is pretty straightforward. IMO
an implementation that can deal with the merge of AS_PATH and
AS4_PATH should have no difficult in implementing the stripping.
I concur that stripping the confed path segments should be
straight-forward, but
I feel that considering the bugs that could be feasibly introduced
through the
implementation of a new standard is valuable. After all, one could
say that 4893
was very clear in terms of forbidding AS_CONFED_SET/SEQUENCE from
AS4_PATH, yet
as we have seen here, not all implementations obeyed this.
Here is an excerpt of your proposal posted to the IDR mailing list
last week:
-----------------------------------
There are two cases to consider when an invalid AS4_PATH is received:
(1) A path to the prefix is not already known from that
neighbour. (2) A path to the prefix has already been learnt from
that neighbour; In case (1) we recommend that the BGP speaker
should discard the UPDATE and log
the fact. The log entry should include the received AS_PATH and
AS4_PATH to aid in debugging.
In case (2) we recommend that the BGP speaker should treat the
UPDATE as a
withdrawal of existing path to the prefix. As per case (1) a log
entry should be
raised to indicate that this has occurred.
------------------------------------
The proposal for (1) is incorrect from the protocol aspect. As BGP
update is incremental, we can not just hold on to the old info and
discard the new info.
The proposal for (2) is ok from the *pure* protocol aspect, but it
would cause unnecessary disruption (i.e., loss of connectivity) for
this recoverable, non-fatal error.
In the case of (1), there is no old information to hold onto.
(1) handles the
case whereby a neighbour hands us a new prefix. At the time we
receive this
prefix, we have no path in any RIB that would provide us reachability
to the
prefix via that neighbour. Hence, when we parse the UPDATE message
and find that
there is an invalid AS4_PATH in it, we choose to not treat this path
as valid,
and not add it to any RIB. This ties back to my previous comment that
we should
perhaps penalise those paths to prefixes which contain invalid routing
information.