Subject: [Idr] draft-ietf-idr-as-pathlimit-03.txt

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 7 Jun 2007 14:02:09 -0700

Hi Tony,

I had a small doubt regarding the use of AS_PATHLIMIT attribute in
case the routes are getting aggregated. If the AS_PATHLIMIT is
different for different routes, what would be the AS_PATHLIMIT for the
aggregated route?

I think it should be the minimum of the component routes.

Thanks,
Vishwas

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

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Jun 2007 14:47:49 -0700

> I think it should be the minimum of the component routes.

Hi Vishwas,

Thank you for your question.

As you probably surmised, we did not specify that behavior.  This is  
pretty much intentional, leaving it up to the implementation to  
decide what policy it will select by default.

The propagation of an aggregate may have no relationship to the  
desired propagation of the component routes, so manual intervention  
is probably the best alternative.  For typical aggregates, global  
flooding is unlikely to be an issue.  The problem that we have is  
quite the opposite...  global flooding of more specifics.  Trading a  
number of specifics for one aggregate is a net win.

Tony

---

From: Erblichs <[email-masked]>
Date: Thu, 07 Jun 2007 16:27:10 -0700

Group, et al,

	I disagree with the min for propogation.

	I can see that due to the fact that
	the attribute is transitive, then it should be passed
	no matter what. So, appling the min would effectively
	decrease the propogation to a non-transitive type attr
	based on the min value. We are trying to make sure that
	the attr is passed even if it is not understood. Thus,
	we SHOULD be able to reach the dst of PATHLIMITs based
	from our source. If we aggregate to the min, with
	periodicly changing aggregates, should we sometimes be
	able to reach a dst or should it be always? I fault
	for a consistent propogation distance of max with ALWAYS.

	Secondly, COULD a value ??0?? be chosen that defers its value
	to another value if present due to expected or possible
	aggregation, and use the TTL of the IP hdr if not 
	aggregated? MY assumption is that the TTL initial
	value COULD be set to a smaller than expected value.

	However, I have a larger concern with the attribute
	itself. Should the attribute also be decremented when
	traversing Confederations? Aren't two ASs essentially
	two sub/logical/virtual ASs and thus propogation of routing
	info be controllable at the entrance of a Confederation?

	Would you allow it to cross ONLY 3 ASs and keep going after
	100 Confederations because only 2 ASs were crossed?

	Would this then be able to stop routing loops
	within the AS if it repeatedly recrosses the same
	Confederations?

	Or should two counting fields be allocated for AS_PATHLIMIT,
	to count the number of Confederations traversed and
	to stop routing loops within a AS? So, if we set the value
	to three, do we stop when the sum of either is reached
	OR 3 of either ASs or Confiderations are traversed in
	sucession? If it was the later, loop mitigation would then
	be added as a secondary benefit, IMO.

	Mitchell Erblich
	------------------

---

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Sun, 10 Jun 2007 13:34:09 -0700

Hi all,

I had a question regarding the "meshedClient" value of
bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How
does a route-reflector know whether the RR client is in full-mesh with
other clients? Please let me know if I'm missing something.

I've pasted the description of this field below.

DESCRIPTION
            "This value indicates whether the given peer is a
             reflector client of this router, or not.  A value of
             nonClient indicates that this peer is not a reflector
             client.  A value of client indicates that this peer is a
             reflector client that is not fully meshed with other
             reflector clients.  A value of meshedClient indicates
             that the peer is a reflector client and is fully meshed
             with all other reflector clients.
 
             This value must be nonClient (0) for BGP external peers."

Thanks,

Kalpesh

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 10 Jun 2007 18:05:23 -0400

Kalpesh,

The same way you know if something is a route-reflector: By
configuration.

-- Jeff

> other clients? Please let me know if I'm missing something.

-- Jeff