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

Hi, Paul:

Paul Jakma wrote:
> On Wed, 17 Dec 2008, John G. Scudder wrote:
>
>> 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;
>
> Things like private-AS removal technically are broken, I guess, yes.
>
> Also, it's not clear to me whether the "the number of AS numbers" in 
> the reconciliation scheme means literally that or the traditional 
> path-length metric from 4271

It is specified in RFC 4893, Sect. 4.2.3:

   In order to construct the AS path information, it would be necessary
   to first calculate the number of AS numbers in the AS_PATH and
   AS4_PATH attributes using the method specified in Section 9.1.2.2
   [BGP] and [RFC3065] for route selection.

-- Enke

> . I presume it means it literally. That might come into play for 
> things like where an OLD speaker receives:
>
>     1_2_{23456,23456,23456}
>
> and then re-announces the set as, say due to how it implements as-set 
> sorting:
>
>     1_2_{23456}
>
> Though, I guess that's not much of a worry.
>
>> 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.
>
> It's reassuring, that it's robust in this way, yes. It would be more 
> robust if NEW speakers considered AS_TRANS to == any >65535 ASN. E.g. 
> it's not robust if two OLD speakers in a cycle each remove the other's 
> ASN, with the remaining speakers on the cycle all being NEW.
>
> I don't see why we would want to leave loop-detection degraded in this 
> way, given a respin, when it seems so trivial to strengthen it.
>
> But anyway.. :)
>
> regards,

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