Re: Operational Recommendations on Handling Invalid AS4_PATH Attributes

Rob Shakir <rjs <at> eng.gxn.net> wrote:
> 
> ... This behaviour seems to be required by RFC4721 section 6.3, as there
> is no alternative error handling defined in RFC4893.
>...
> Following discussions with a number of operators, we have attempted to
> generate some recommendations relating to the behaviour that would be
> operationally most useful when treating the invalid data in the
> AS4_PATH optional transitive attribute.

   I have no desire to criticize, but I think it may be helpful to step
back for a moment.

   The _useful_ information in AS4_PATH is the 4-byte ASNs where OLD
speakers must place AS_TRANS. We might consider whether that information
is useful in cases where RFC4893's algorithm produces invalid data. (I
frankly doubt we have found all possible cases yet.)

   I can imagine a treatment where we abandon the 4893 algorithm and
simply substitute 4-byte ASNs for AS_TRANS in the AS_PATH received from
an OLD speaker. This would preserve loop-detection for 4-byte ASNs
while matching other characteristics of the NLRI received from our OLD
peer.

   Obviously this would be better than tearing down the session with our
OLD peer; the question is, would it be better than discarding the new
NLRI?

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