Subject: [Idr] Next revision of AS_HOPCOUNT

From: Tony Li <[email-masked]>
Date: Wed, 01 Feb 2006 10:57:12 -0800

Hi all,

Surprisingly, my mailbox wasn't full this morning.  For those that
didn't notice, the next revision of the AS_HOPCOUNT draft (now
AS_PATHLIMIT) has been released.  Here's the link:

http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-00.txt

Please comment now...  Given our previous discussions, I can't believe
that there are no further comments.  ;-)

Regards,
Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Erblichs <[email-masked]>
Date: Wed, 01 Feb 2006 17:40:37 -0800

Tony Li, et al,

	1) Do I implicitly read that this new will also
	   limit looping paths to AS_PATHLIMIT?

	2) 5.1 Operations
   If the
   AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH,
   then the route should not be sent.

	I must be dsylexic, I would think that you want the number of
	ASs found to be less or equal to the AS_PATH_LIMIT,

	Thus...

	If the number of ASs found in the AS_PATH exceeds the
        AS_PATHLIMIT value, then the route should not be forwarded.

	As this also seems backward..

	If the attribute value exceeds the number of ASes in the
   AS_PATH, then the route MUST be ignored without further processing.

	3a) Stupid question.

	  Why isn't this AS_PATHLIMIT decremented at each BGP speaker
	  who would examine the route, and when it reaches 0, then
	  the route would be dropped?

	3b) Another stupid question

	   What prevents a BGP speaker from changing this value? Why
	   would a speaker want to change the value or why shouldn't
	   a speaker change this value?

	  Mitchell Erblich

---

From: Tony Li <[email-masked]>
Date: Wed, 01 Feb 2006 18:09:44 -0800

Hi,

> 	   limit looping paths to AS_PATHLIMIT?

I'm not sure I understand the question.  The additional path attribute
is in addition to all existing BGP attributes and mechanisms, and does
not replace or supplant any of them.  Thus, the normal AS_PATH loop
detection should prevent all looping paths even without AS_PATHLIMIT.

>    AS_PATH, then the route MUST be ignored without further processing.

Dyslexia is all mine.  Your corrections are what was intended.  Sorry
about that...

> 	  the route would be dropped?

Not stupid.

The original version operated this way and the concerns about partial
deployment and the subsequent fluctuating semantics led us to conclude
that something a bit more deterministic would be preferred.  Please see
the mailing list archives for more discussion.

> 	   a speaker change this value?

Right now, there is nothing that prevents a BGP speaker from modifying
the value.  This is also true for all other BGP attributes until such
time as we have some type of cryptographic integrity check in place.

There is currently no text here suggesting that an AS cannot modify this
 value, largely because this seems like something that we want to
permit.  An AS may well have a policy reason to impose its own limits.
The only restriction that we felt was necessary was that any such
advertisement should be marked as being originated by the proxy AS.
Thus, the language was crafted to explicitly require the originating AS
number and to permit deletion or replacement of the attribute.

Regards,
Tony

---

From: Erblichs <[email-masked]>
Date: Fri, 03 Feb 2006 00:03:45 -0800

Tony Li, et al,

	Inline..

	This is just a expectation.

	Mitchell Erblich

> detection should prevent all looping paths even without AS_PATHLIMIT.

	I was thinking where the loop is sufficently large that the
	AS_PATHLIMIT is encountered before normal AS_PATH detection.

	Wouldn't it then implicitly also duty as an additional means
	to stop larger loops? Thus, I associate AS_PATHLIMIT equal to
	a TTL size and decrementing by 1 at each BGP speaker.

	Thus, am I right that no loops can completely form (loop onto itself)
	that are larger than AS_PATHLIMIT?

	Somehow, I think this is a good thing.. But during transient
	routing loops distances between Provider Edege boundries may
	increase and the AS_PATHLIMIT may be too short for the route
	to be propagated to the expected destination..

	Mitchell Erblich

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Feb 2006 02:36:02 -0800

Hi Mitchell,

> 	a TTL size and decrementing by 1 at each BGP speaker.

Well, in the sense that AS_PATHLIMIT restricts the path, it will stop
all longer paths, both loops and non-loops.

> 	that are larger than AS_PATHLIMIT?

BGP already prevents all inter-AS loops from forming.  AS_PATHLIMIT is
only operating at the inter-AS level, so it will not do anything to
prevent intra-AS transient loops.

> 	to be propagated to the expected destination..

Presumably, the transient routing loop is within an AS, as part of the
IGP converging.  Assuming that the duration is sufficiently short, this
should not perturb BGP at all.

Tony