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

Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt]



Rob Shakir <rjs at eng.gxn.net> wrote:
> 
> With the AS4_PATH unreadable and therefore discarded the BGP speaker
> cannot know if its AS number was in the path. The only loop free 
> options are:
> (a) treat it as a withdrawal
> (b) treat any AS_TRANS in the AS_PATH as the local AS
> (c) drop the session.
> 
> Option c is the behaviour that has led us to needing a change to the 
> RFC, so is obviously unacceptable.

   Agreed.

> Option a and b are equivalent since the AS4_PATH attribute would not be 
> present if there wasn't an AS_TRANS in the AS_PATH.

   Actually, no.

   Option (a) removes any possibility that you're propagating the error,
at the possible expense of losing reachability to the CIDR block.

   Option (b) removes the possibility of a loop, keeping reachability
in most cases; but does not protects BGP speakers you may pass this
NLRI to.

   The possibility of losing reachability in option (a) is unfortunately
significant, because any NEW speaker receiving this NLRI from your OLD
neighbor will likewise discard it. Note particularly that the OLD speaker
has done nothing wrong (unless you call failure to upgrade it to a NEW
speaker) and that the NLRI you received is its honest "best" route.

   I prefer imlementing option (b) independently of what we do with an
erroneous AS4_PATH, largely because I doubt we can catch all the cases
where a bug may cause AS_TRANS to show up in a (possibly reconstructed)
NLRI.

--
John Leslie <john at jlc.net>
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr