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.
Combining your comments on (2), and earlier comments - one can be liberal in
terms of accepting any prefix to a neighbour, however, if we have a 4-byte ASN
in the path that is manipulating routing data that is important to it (i.e.
AS4_PATH) incorrectly, should we not treat this as we treat invalid data in the
AS_PATH? I believe our suggested approach (treating the UPDATE as WITHDRAWL) is
closer to how rfc4893 currently deals with the invalid data, but takes into
account the optional transitive nature of AS4_PATH. Is the intended behaviour
to be permissive in handling invalid AS4_PATH data where we are not so with
AS_PATH? It is worth considering that the loss of connectivity is only to a
prefix that has no valid method of propagating itself via RFC-compliant BGP
speakers.