Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

[resending with cropped cc list to get around brain-damaged ietf  
bogosity filter]

On Dec 15, 2008, at 1:11 PM, Jeffrey Haas wrote:
> On Mon, Dec 15, 2008 at 05:51:33PM +0000, cayle.spandon@gmail.com  
> wrote:
>> Because of this an alternative is available: instead of ignoring the
>> update, we can treat these "illegal" routes as unusable, ie no
>> different
>> than -say- a route with an unreachable next-hop.
>
> In that case, the presumption is that you would *ever* want to use it.
> I suggest simply discarding the update.

Discarding updates without processing them as Cayle describes violates  
the loop free property.  Consider the fact that an advertisement of a  
route is also an implicit withdrawal of any previous advertisement,  
and also consider that an update can also carry explicit withdrawals.   
Simply discarding an update is thus equivalent to ignoring a  
withdrawal.  It's not difficult to construct a scenario in which  
persistent forwarding loops ensue.  A scenario with a persistent  
blackhole is trivial.

If you ever get into a state where the only sensible thing you can do  
is discard an update, you're at the point where BGP's most fundamental  
correctness property is broken.  I think you want to think very, very  
hard about whether the "cure" (dropping the update) is worse than the  
disease (dropping the session).  OTOH, I think it's worth continuing  
the discussion about what kinds of other actions can be taken up to,  
but not including, dropping the update.

> On Mon, Dec 15, 2008 at 11:05:46AM -0700, Danny McPherson wrote:
>> Given that we can be certain AS_CONFED_* segments serve NO
>> function in AS4_PATH, I believe discarding only those segments
>> and continuing normal processing is a reasonable response for
>> a receiver.
>
> The presumption is that the path is malformed in some fashion.  Can  
> you
> really trust that the portions to either side of the confederation
> segments are correct?

This has generally been my position in past iterations of this annual  
debate.  I'm starting to moderate it based on the demonstrated  
operational problems caused in particular by bad optional/transitives.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr