Subject: [Idr] AS_PATHLIMIT

From: Tony Li <[email-masked]>
Date: Fri, 12 Jan 2007 13:37:30 -0800

Folks,

Are there any more comments on AS_PATHLIMIT?

Tony

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

---

From: Erblichs <[email-masked]>
Date: Fri, 19 Jan 2007 17:22:08 -0800

Tony Li,

	I have a few concerns/ questions.

	1) I seem to recall in either a non-IETF
	   document of a IETF doc, that AS_PATHLIMIT
	   was already used to determine whether
	   some form of looping was done. With this
	   value the same AS could be added to allow
	   an alternate pathing method.

	   It will limit a non redundant AS looping
	   environment to this LIMIT value. Right?

	   Should a section thne be added for
	   "loop mitigation"?

	2) As was mentioned in the draft, AS_PATHLIMIT
	may be changed by other than the originator.

	Would it then make sense, if the change was
	intentionally done, to suggest a parasitic
	version field. This, COULD then be incremented
	each time a this value was changed because of
	policy mechanisms.

	3) Of of the reasons for this new value is to
	   restrict the propogation of routing information.

	   However, with this restriction, doesn't it
	 limits the ability of a BGP speaker to quickly
	 alternately find another path if the new AS_PATHLIMIT
	 restricts the less specific prefixes.

	4) Can a secondary consequence of this new value lead
	   to more routing information?

	   I can see a router wishing to originate more
	   specific routing information locally and less
	   specific routing information on a non-local basis.

	5) How do you / should you consider that a router that
	   is in a chaotic subnet location may periodicly
	   be decrementing the AS_PATHLIMIT because it
	   understands this new attribute.

	   Thus,  I can see the reach of the prefixes may
	   be in somewhat of a change?

	Mitchell Erblich
	====================

---

From: Tony Li <[email-masked]>
Date: Fri, 19 Jan 2007 17:55:56 -0800

Hi Mitchell,

> 	   Should a section thne be added for

I'm unaware of any other documents (other than prior revs of this  
one) that refer to AS_PATHLIMIT.

In any case, AS_PATHLIMIT should have no impact whatsoever on BGP's  
normal loop prevention mechanisms.  It should only provide an  
additional mechanism for prefix filtering.

> 	may be changed by other than the originator.

More strictly, the AS_PATHLIMIT may be removed by an AS.  Another  
AS_PATHLIMIT can then be added, but it should always include the AS  
number of the domain that added the attribute.

> 	each time a this value was changed because of

While that's certainly possible, I don't see a vital need for this.   
Is there one?

> 	 restricts the less specific prefixes.

Again, as it's only another prefix filtering mechanism, it should  
have no effect on best path computation.  Obviously, if the  
AS_PATHLIMIT has caused the only working path to be filtered, there  
will be a problem finding a path.  However, you have that today with  
simple prefix filters already.

BTW, my expectation is that AS_PATHLIMIT is primarily applied to more  
specifics.  Of course, I could be wrong.

> 	   specific routing information on a non-local basis.

If an administrator wants to do that today, then they are already  
doing so, resulting in global propagation of even the more  
specifics.  The goal here is to provide a scoping mechanism.

> 	   be in somewhat of a change?

Any filtering mechanism is going to implicitly change the reach of  
the prefixes that it filters.

Tony

---

From: Erblichs <[email-masked]>
Date: Fri, 19 Jan 2007 19:12:30 -0800

Tony Li,

	I think you missed my points.

	You were justifying the use of AS_PATHLIMIT
	to limit the scope of specific/local routing
	information to the network.

	0) NEW:  I don't quite see why this new proposed
	   attribute would not be a non-transitive
	   optional category?

	   If the value is unknown by one or more BGP
	   nbrs, shouldn't that restrict the usage to
	   those local BGP spkrs? Without doing so
	   allows the route to be passed along with
	   the result of no AS_PATHLIMIT being set.
	   This clearly was not the intent when the
	   AS-PATHLIMIT was set.
	   Right?

	3)  Summary: Change "MUST" to "SHOULD".

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

	Sorry, IMO, the AS_PATHLIMIT is a origination filter,
	where the normal filters are locally applied based
	on a number of configurable parameters....

	This tells a BGP spkr X+1 ASs distance that you will
	drop the route!!!!! Some routers may want to cache that
	alternate route. 

	Why should 1 router tell other routers
	what to do with the recieved routing information??????

	This is so IMPORTANT, I feel that it needs to be
	mentioned twice in my reply. :(

	   The rest are Inline..

	Mitchell Erblich

> additional mechanism for prefix filtering.
	If a path preference was to prefer transit the same AS twice,
	the AS_PATHLIMIT could be used as a alternate path
	mitigation. I thought this was the original intention
	for this attribute name..

	However, for loop mitigation, it is feasible to know
	that a specific path isn't longer than X AS's in length
	and thus, any alternate route that takes a greater
	number of ASs could be prevented.

	Thus, it should be stuck on almost every route.

> While that's certainly possible, I don't see a vital need for this.

		Doesn't knowing that the AS_PATHLIMIT may have
	        been changed multiple times add information?.

		Secondly, their is/was a course grain Partial bit
		usage, however, to determine that it was changed
		multiple times requires a version number.
		Partial bit set to 1 and version set to 0
		 specifies that the number of changes done
		 to the attribute exceeded the number of
		 bits available for the version number, IMO.

> simple prefix filters already.
	Sorry, IMO, the AS_PATHLIMIT is a origination filter,
	where the normal filters are locally applied based
	on a number of configurable parameters....

	This tells a BGP spkr X+1 ASs distance that you will
	drop the route!!!!! Some routers may want to cache that
	alternate route. 

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

> specifics.  The goal here is to provide a scoping mechanism.

	 Yes, but you have just opened the "pandora's box"
	 to justify at least the doubling of routes. To allow
	 low-hop routers to use one path and to force the use
	 of other's to transit a different path for greater
	 bandwidth but also with greater latency.

	The side effect is to allow the increase of the number of
	routes. Some routes will have a local scope. Some a med
	scope. Some a ISP scope. Some a global scope.

> the prefixes that it filters.

	I didn't get my full intention with this statement. 

	Since the AS_PATHLIMIT is passed along if unknown
	(transitive optional), many ASs may be added to the
	path before the route is finally if ever removed.

	So, with the understanding that we may set the AS_PATHLIMIT
	to X, it may be X+Y before the route is removed. Thus, any
	admin doing #4 above, may not quite realize why his
	concieved routing domains are unindated with additional
	routes.

	Mitchell Erblich

---

From: Tony Li <[email-masked]>
Date: Fri, 19 Jan 2007 21:49:17 -0800

Mitchell,

> 	I think you missed my points.

Sorry.  I'm trying the best that I can.  Please feel free to enclose  
clue.

> 	   attribute would not be a non-transitive

Well, we want it to be transitive as we want it to cross ASes that  
don't understand the attribute.

> 	   This clearly was not the intent when the

If the attribute is not understood by a BGP speaker, then it  
hopefully will be received by some BGP speaker that recognizes it and  
can then filter out the prefix.

>    the AS_PATHLIMIT attribute, then the route MUST be ignored without

For an implementation that supports AS_PATHLIMIT to be in compliance  
with this (future) RFC, this is the required behavior.    
Implementations that choose not to perform this function should not  
claim compliance with the document.

> 	what to do with the recieved routing information??????

The use of AS_PATHLIMIT is not required.  It is only there if a  
router choose to add the attribute.  It is purely intended as a  
mechanism for a router to tell others to drop the prefix.

> 	number of ASs could be prevented.

I'm sorry, you've definitely lost me here.

> 	Thus, it should be stuck on almost every route.

I'd be a bit more conservative and suggest that it should definitely  
be on every more specific.  For less specifics, using the  
AS_PATHLIMIT could constrain reachability unduly.

> 	        been changed multiple times add information?.

True it would.  The question then becomes a) is it useful information  
and b) does the benefit outweigh the costs.  Again, I'm not finding a  
significant benefit.

> 	scope. Some a ISP scope. Some a global scope.

I'm sorry, I don't see how that justifies anything.  Anyone injecting  
a route into the Internet still will need to justify doing so, with  
or within AS_PATHLIMIT.

> 	path before the route is finally if ever removed.

That's unfortunately true.  Hopefully as deployment expands, the  
spread of 'over limit' prefixes will diminish.

> 	concieved routing domains are unindated with additional

It's true that those that do not understand how to use the tool may  
harm themselves or others with it.  Of course, BGP had this property  
on day 1.  As this is an extension of BGP, it too has this property.   
It's unavoidable.

Tony