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 at ietf.org https://www.ietf.org/mailman/listinfo/idr