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

["John G. Scudder" <jgs at juniper.net>]

On Jan 27, 2009, at 12:52 PM, Rob Shakir wrote:
> We feel that the general behaviour on an error should be the  
> withdrawal
> of the path, as discarding the attribute is equivalent in effect to
> discarding part of the AS_PATH and may cause loops. Take for example  
> the
> case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH
> attribute. 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:

While intuitively obvious, this isn't correct.  As long as there's no  
corresponding damage to the AS_PATH, the loop free property is  
preserved.  Here's the argument:

On Dec 17, 2008, at 11:52 AM, John G. Scudder wrote:
> On Dec 17, 2008, at 3:13 AM, Paul Jakma wrote:
> > On Tue, 16 Dec 2008, John G. Scudder wrote:
> >
> > > 1. All the ASes in the path are 4-byte capable, in which case the  
> > > issue does not exist.
> > > 2. At least one AS in the path is not 4-byte capable. In that  
> > > case, if there is a loop it will eventually be caught by the  
> > > regular 2-byte AS_PATH.
> > >
> > > In neither case is what you describe needed, AFAICT.
> >
> > We're talking about the case where the AS4_PATH has been removed by  
> > a preceding NEW speaker though.
> >
> > Your 2 seems to suggest that in such paths, loop-detection should  
> > only be done by the OLD speakers (and NEW speakers preceding it may  
> > happily install the path).
>
> That's more or less correct, modulo the adverb :-).  The point is  
> that as long as the loop gets broken, regardless of by whom (in this  
> case the OLD speaker preceding the NEW speaker which removed the  
> AS4_PATH), it will proceed to unwind.  That is to say, it's only a  
> transient loop.
>
> Keep in mind this behavior SHOULD never be seen in the wild since  
> it's predicated on broken behavior along the path someplace to begin  
> with; with luck this is just a chalkboard exercise.  I for one find  
> it heartening that the protocol appears to be robust even in the  
> face of certain types of mangling of the AS4_PATH.

One may still debate whether it's preferable to "fix" the broken route  
by dropping the AS4_PATH or treat the broken route as a withdraw  
(which as you point out is effectively what your options a+b are), but  
if the latter is chosen it should be for some reason other than "may  
cause loops".

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