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

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. 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,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Anger kills as surely as the other vices.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr