Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt

From: Paul Jakma <[email-masked]>
Date: Sun, 1 Jan 2006 11:53:23 +0000 (GMT)

On Sat, 31 Dec 2005, Tony Li wrote:

> I'm not yet convinced of the above.  Consider that most longer 
> prefixes are now being distributed globally.  Folks playing with 
> the new attribute are likely to want to experiment with it by 
> slowly contracting scope.

Agreed.

See the example I gave (Andrew's originally?), the combination of 
AS_HOPCOUNT with peer:action could give the route /wider/ scope than 
either of the two methods on their own, which seems unintuitive.

> An abrupt change in distribution is likely to result in some 
> unanticipated results, which would delay, not encourage deployment.

A fair point.

How likely is it that people are going to experiment with 
announcements that are currently global scope? Surely such 
experiments will be carried out on announcements currently with 
restricted scope (by no-export or by <peer>:<action> communities)?

> Thus, it seems like many providers might want a more liberal 
> interpretation of the semantics. Providing the option of a liberal 
> or strict scoping would seem to give the provider an increased 
> level of control and thus ease deployment.

Yeah...

Though, as it stands it seems to interact poorly with one of the few 
existing restrict-scope traffic-engineering method during transition. 
Is that interaction more important than difference between "X 
hopcount means reaches at least X hops" and "X hopcount means reaches 
/up to/ X hops"? (particularly given the former can never be 
guaranteed anyway). I don't know.

Anyway..

> Tony

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Office Automation:
 	The use of computers to improve efficiency in the office
 	by removing anyone you would want to talk with over coffee.

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

---

From: Tony Li <[email-masked]>
Date: Sun, 1 Jan 2006 10:12:25 -0800

> restricted scope (by no-export or by <peer>:<action> communities)?

Well, I'm always horrible at estimating probabilities of group behavior.

My hope is that restricting the scope of global prefixes becomes the  
predominant
use of the attribute.  Specifically, longer prefixes that are being  
injected for traffic
engineering.  I'm guessing that the predominant use would be proxy  
application
by Tier 1 or 2 providers.

My $.02,
Tony

---

From: Paul Jakma <[email-masked]>
Date: Sun, 1 Jan 2006 19:49:19 +0000 (GMT)

> Well, I'm always horrible at estimating probabilities of group 

;)

> My hope is that restricting the scope of global prefixes becomes 
> the predominant use of the attribute.  Specifically, longer 
> prefixes that are being injected for traffic engineering.  I'm 
> guessing that the predominant use would be proxy application by 
> Tier 1 or 2 providers.

Sure. But if they're restricting scope of a route, they want its 
scope restricted. The covering global scope prefix will be there 
anyway. But who knows, indeed :).

A more focused answer might be to make just the 'ignore no-export' 
part of the draft conditional on the AS_HOPCOUNT attribute being 
complete. Would that be acceptable? That'd solve the no-export 
concerns while still erring on the liberal-scope side.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You will stop at nothing to reach your objective, but only because your
brakes are defective.

---

From: Tony Li <[email-masked]>
Date: Sun, 1 Jan 2006 17:15:55 -0800

> concerns while still erring on the liberal-scope side.

Ok, I don't understand what you're suggesting.  Here's what I think  
you're saying.

If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by  
an AS,
then there are three cases:

1) The AS doesn't support AS_HOPCOUNT and it obeys NO_EXPORT,  
limiting the prefix
to the local domain.

2) The AS does support AS_HOPCOUNT.

a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT.

b) If the hopcount has completed, then the AS would drop the route.

I don't see how the path can ever exit the AS.  I'm guessing that I'm  
being dense, but
I'm not seeing how...

Tony

---

From: Paul Jakma <[email-masked]>
Date: Mon, 2 Jan 2006 01:38:06 +0000 (GMT)

On Sun, 1 Jan 2006, Tony Li wrote:

> Ok, I don't understand what you're suggesting.  Here's what I think you're 
> saying.

> If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by an AS,

> a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT.

Odd, the draft doesn't seem to say this.

> I don't see how the path can ever exit the AS.  I'm guessing that 
> I'm being dense, but I'm not seeing how...

In 3.3:

"   Systems that receive NLRI with both an AS_HOPCOUNT and NO_EXPORT and
    which do implement AS_HOPCOUNT will ignore the NO_EXPORT community
    and propagate the NLRI."

In 5.1:

"   If a BGP speaker receives a route with both the AS_HOPCOUNT attribute
    and the NO_EXPORT community string attribute, then the normal
    semantics of NO_EXPORT do not apply and the route should be processed
    as if NO_EXPORT was not present."

Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT 
/always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z 
action-community + AS_HOPCOUNT example in previous email). I'm saying 
AS_HOPCOUNT should override NO_EXPORT *only* if it is complete.

If it's partial, then NO_EXPORT, IFF present, should be honoured 
instead, because there's no way to know how many hops were "missed" 
in the AS_HOPCOUNT attribute, NO_EXPORT is the only complete 
"scope-reducer" in such case and should hence be obeyed.

Failure could to do so could result in the prefix reaching /further/ 
than intended by anyone, possibly even result in global scope, where 
this was never intended for that prefix.

regards,
Death to all fanatics!

---

From: Tony Li <[email-masked]>
Date: Sun, 1 Jan 2006 18:54:04 -0800

> Odd, the draft doesn't seem to say this.

That was my interpretation of what YOU were suggesting when you said  
that "AS_HOPCOUNT
should override NO_EXPORT *only* if it is complete".  Is that incorrect?

> Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT / 
> always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z  
> action-community + AS_HOPCOUNT example in previous email). I'm  
> saying AS_HOPCOUNT should override NO_EXPORT *only* if it is complete.

Perhaps we might make more progress if you could expand on your  
proposed semantics a bit.

> instead,

If AS_HOPCOUNT is partial, the it implies that it transited an AS  
that did not support AS_HOPCOUNT.
But any such AS should have obeyed NO_EXPORT and thus should never  
have propagated the
path in the first place.

Tony

---

From: John Leslie <[email-masked]>
Date: Mon, 2 Jan 2006 06:57:04 -0500

Tony Li <[email-masked]> wrote:
> have propagated the path in the first place.

   When I first raised this issue, I was thinking of a particular case
(in addition to the general case):

- BGP-speaker at the edge advertises with AS_HOPCOUNT (without NO_EXPORT);
- ISP-A doesn't know AS_HOPCOUNT, adds NO_EXPORT for whatever reason;
- ISP-B recognizes AS_HOPCOUNT, and ignores NO_EXPORT.

   This particular case feels wrong to me.

--
John Leslie <[email-masked]>

---

From: Paul Jakma <[email-masked]>
Date: Tue, 3 Jan 2006 03:30:55 +0000 (GMT)

On Sun, 1 Jan 2006, Tony Li wrote:

> That was my interpretation of what YOU were suggesting

Ah, doh, of course. apologies.

> when you said that "AS_HOPCOUNT should override NO_EXPORT *only* if 
> it is complete".  Is that incorrect?

Yes, that's exactly what I'm arguing for.

> Perhaps we might make more progress if you could expand on your proposed 
> semantics a bit.

As above, sorry.

> that did not support AS_HOPCOUNT. But any such AS should have 
> obeyed NO_EXPORT and thus should never have propagated the path in 
> the first place.

See the examples I gave previously wrt interaction of AS_HOPCOUNT and 
<peer>:<action> communities:

 	X-Y-Z

Z sends prefix with both AS_HOPCOUNT (count >= 2), and also community 
Y:n (where AS Y will attach no-export community for any prefix which 
has Y:n community attached). Y does not support AS_HOPCOUNT. X 
receives the advertisement and ignores no-export, as the draft 
currently stands.

The prefix might now have have global scope, particularly in early 
days of AS_HOPCOUNT deployment (where it may never transit through 
sufficient other AS_HOPCOUNT capable speakers to be stopped). The 
prefix has /wider/ scope because of the combination of AS_HOPCOUNT 
and <peer>:<action> communities, wider than it could ever have with 
either method (presuming everyone supported AS_HOPCOUNT). It'd be a 
surprising effect of AS_HOPCOUNT possibly.

See also the example I gave where Y has some AS_HOPCOUNT capable 
speakers, and some not.

Making the NO_EXPORT override be conditional on AS_HOPCOUNT being a 
complete attribute would solve this case, while not restricting scope 
of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was your 
objection to my earlier 'partial -> set to 0' proposal).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
They are called computers simply because computation is the only significant
job that has so far been given to them.

---

From: Tony Li <[email-masked]>
Date: Tue, 3 Jan 2006 14:45:49 -0800

Paul,

> See the examples I gave previously wrt interaction of AS_HOPCOUNT  
> and <peer>:<action> communities:
>
> 	X-Y-Z
>
> Z sends prefix with both AS_HOPCOUNT (count >= 2), and also  
> community Y:n (where AS Y will attach no-export community for any  
> prefix which has Y:n community attached). Y does not support  
> AS_HOPCOUNT. X receives the advertisement and ignores no-export, as  
> the draft currently stands.
>

Understood, and this is certainly a bad side effect of AS_HOPCOUNT  
and Y:n interaction.

> complete attribute would solve this case, while not restricting  
> scope of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was  
> your objection to my earlier 'partial -> set to 0' proposal).

Yes, but as I pointed out, making the NO_EXPORT override be  
conditional on AS_HOPCOUNT being
complete breaks the NO_EXPORT override for everyone who is NOT  
depending on Y:n semantics.
This begs the question: how many folks are reliant on Y:n semantics?   
Or should we simply remove
the interaction between AS_HOPCOUNT and NO_EXPORT?

Tony

---

From: Danny McPherson <[email-masked]>
Date: Tue, 3 Jan 2006 19:24:00 -0700

On Jan 3, 2006, at 3:45 PM, Tony Li wrote:
> This begs the question: how many folks are reliant on Y:n  
> semantics?  Or should we simply remove

Tony,
I've got a couple of concerns with the current specification, a few
high-level points are provided here as the detailed text below is
admittedly overly verbose (in part because I was trying to wrap my
head around the various scenarios - which I'm still not sure I have).
I have read the entire thread to date and don't believe I'm duplicating
much...

In short, I'd definitely prefer that AS_HOPCOUNT and NO_EXPORT
interaction be removed entirely.  I believe the corner cases where it'd
be useful are fewer than the cases where it could adversely effect
existing deployments.

I'd also think that adapting AS_HOPCOUNT behavior to be much more
akin to that of the NO_EXPORT community string may be desirable.  I.e.,
make AS_HOPCOUNT an egress policy function rather than an ingress
one - as expanded on in the text below.

Finally, I'd strongly suggest that Member-ASes of an AS confederation
NOT be treated like standard external peers, but rather, that the
AS_HOPCOUNT functions only apply to Member-ASes that are
advertising a route to eBGP peers outside of the local confederation.
My reasoning for this is that IBGP AS properties that are only visible
within an AS would now result in routes only being propagated
throughout a subset of a given AS, or an AS_HOPCOUNT being
decremented multiple times in a seemingly single A (AUTONOMOUS)
System....

Imagine a case where a multi-homed AS wanted to employ
AS_HOPCOUNT to scope traffic two ASes upstream from it's two
providers.  One of it's upstream providers employs route reflection
or a full mesh iBGP, while the other has confederations.  As
you can imagine, the confederation could result in the route
never being advertised outside of the AS, or entirely within the AS if
employing confederations, while still being propagated via the other
provider.  In short, it results in behavior that would be seemingly
non-deterministic without intimate knowledge of the the internal
BGP routing architectures of the networks in questions.

I suspect in this case implementers could provide a knob to
decrement AS_HOPCOUNT when advertising to other Member-ASes
of the same AS confederation, but it's not something I'd recommend
as normal default behavior.

I'm still a fan of AS_HOPCOUNT and believe it's a good idea, FWIW.

Further comments below...

-danny

As currently specified, (if I'm interpreting correctly) an eBGP speaker
upon receipt of NLRI that contains both the AS_HOPCOUNT attribute
and NO_EXPORT community:

- if it doesn't understand the AS_HOPCOUNT attribute processing will
continue as usual per it's an optional transitive attribute and  
NO_EXPORT
will likely result in the NLRI NOT being propagated outside the local  
AS.
(note that this required that the eBGP peer transmit both the NO_EXPORT
community AND the AS_HOPCOUNT attribute)

- if it does understand AS_HOPCOUNT it will ignore the NO_EXPORT
(actually, behave as if it doesn't exist?) community and propagate the
route ---> IF the AS_HOPCOUNT value is non-zero.

- NO_EXPORT remains only applicable between adjacent ASes (by it's
very nature)?  I don't see anywhere here that it states NO_EXPORT should
be carried indefinitely if the AS_HOPCOUNT attribute is present?

With that, I'm honestly not sure I understand here where value is gained
by coupling the NO_EXPORT community with the AS_HOPCOUNT
attribute, can you further expand for me?

On that point

In section 3.3 the draft states:

" Further control can be achieved by considering the implications of
using both AS_HOPCOUNT and NO_EXPORT simultaneously.  Since
NO_EXPORT is widely deployed, understood by almost all implementations,
and since AS_HOPCOUNT is not deployed, we can make use of the overlap
in their semantics to provide a powerful transition mechanism."

This introduces a bit of confusion.  With the AS_HOPCOUNT attribute
a route would be dropped as an ingress policy function (i.e., when
receiving a route from an eBGP peer with an AS_HOPCOUNT value
of 0).  Whereas, NO_EXPORT is applied as an egress policy function
(i.e., don't announce a route to an eBGP peer if the NO_EXPORT
community string is present), the latter of which has the advantage
of allowing me to tell an adjacent AS something and being quite
confident that it will not be propagated beyond their AS.  I.e., it
seems non-intuitive to tell someone something if I know they're
going to ignore it.  However, if I know they're going to use it but
not tell anyone else (e.g., as with NO_EXPORT), that makes sense.

So what this would mean is that if I wanted to employ this in a
similar manner to NO_EXPORT with an adjacent peer that
supported the new attribute, I'd set the AS_HOPCOUNT attribute to
1, it'd be decremented on ingress to the adjacent AS AND advertised
to ASes further upstream - *where it previously was not*, and on
ingress to those ASes IF they support the AS_HOPCOUNT attribute
they'll discard the route (a route that would have never been advertised
had the AS_HOPCOUNT behavior not been introduced per the
NO_EXPORT community that existed on ingress to the second AS in
the path).  If they do not support the attribute the route will be
propagated indefinitely.

Perhaps we'd be better off here if we changed the rules a bit
such that NLRI with an AS_HOPCOUNT value of 1 (or 0) MUST
NOT be advertised to eBGP peers, then the semantics overlap much
more cleanly with that of the NO_EXPORT community string.  I'm
trying to think of a case where this might break if BGP speakers
don't support it but nothing comes to mind at the moment....?

Along the same lines, the issue that most of this thread has been
pertaining to regarding ignoring NO_EXPORT if the AS_HOPCOUNT
attribute is present, that concerns me.  Primarily because if a
downstream AS attaches the NO_EXPORT community to a route
but has no knowledge of the existing AS_HOPCOUNT attribute,
then the NO_EXPORT community will be ignored.

According to the text here in section 5.1:

"If a BGP speaker receives a route with both the AS_HOPCOUNT
attribute and the NO_EXPORT community string attribute, then the
normal semantics of NO_EXPORT do not apply and the route should
be processed as if NO_EXPORT was not present."

This has several implications.  The first is that my reading of this
leads me to believe that the NO_EXPORT community string should be
removed from the route.  So, if a transit AS added the NO_EXPORT
community fully intending for the adjacent to propagate the route
entirely throughout the local AS, but didn't recognize the AS_HOPCOUNT
value then policy just changed without their knowledge and the route
MAY be dropped on ingress to the AS, rather than egress (or in some
external AS), depending on the value of the AS_HOPCOUNT attribute.

I'd really prefer that the interactions between AS_HOPCOUNT and
NO_EXPORT be removed altogether as I suspect that this will likely
result in inadvertent propagation of prefixes that were previously
scoped by NO_EXPORT (e.g., as was mentioned in the case where
a transit AS doesn't support AS_HOPCOUNT but attached
NO_EXPORT for whatever reason).   Or, for example, all the routes that
MAY be leaked while I'm upgrading my egress routers to support
AS_HOPCOUNT while the ingress routers have stripped the
NO_EXPORT community.

---

From: Enke Chen <[email-masked]>
Date: Tue, 03 Jan 2006 23:01:56 -0800

> the interaction between AS_HOPCOUNT and NO_EXPORT?

Hi, Tony:

It seems to me that removing the interaction between AS_HOPCOUNT and 
NO_EXPORT would make things simpler and cleaner. So I am in favor of the 
revision.

Also as Danny pointed out,  having the AS_HOPCOUNT as an outbound policy 
(rather than an inbound policy) would make it consistent with the 
commonly understood practice of NO_EXPORT. It seems to be a good idea.

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Wed, 4 Jan 2006 11:42:36 +0000 (GMT)

> conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT 
> override for everyone who is NOT depending on Y:n semantics.

I don't quite see that. Could you expand on this (apologies if you 
did already)?

It will work for fine for the combination of NO_EXPORT and 
AS_HOPCOUNT evisaged in the draft. Where the originator sets both. 
AS_HOPCOUNT will always be complete.

> semantics?  Or should we simply remove the interaction between 
> AS_HOPCOUNT and NO_EXPORT?

I think the draft is right to try modify no-export behaviour 
depending on AS_HOPCOUNT. Lets try find the best way to do so, no?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Life is a gamble at terrible odds, if it was a bet you wouldn't take it.
 		-- Tom Stoppard, "Rosencrantz and Guildenstern are Dead"

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Jan 2006 09:28:39 -0500

> depending on AS_HOPCOUNT. Lets try find the best way to do so, no?

   I believe that any interaction between AS_HOPCOUNT and NO_EXPORT
should be limited to _setting_ NO_EXPORT. Clearing it seems to
introduce too much risk of propagating farther than intended.

   That said, I can imagine a use for setting NO_EXPORT in the case
where AS_HOPCOUNT will reach its limit after one more hop: when the
next hop is suspected of not implementing AS_HOPCOUNT.

   Of course, this only helps during the "transition" to full
implementation of AS_HOPCOUNT -- but that transition, IMHO, will
take a minimum of five years, and any predictability we can add
during the transition is (IMHO) a good thing.

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Jan 2006 13:59:14 -0800

Enke,

> It seems to me that removing the interaction between AS_HOPCOUNT  
> and NO_EXPORT would make things simpler and cleaner. So I am in  
> favor of the revision.

Duly noted.

> Also as Danny pointed out,  having the AS_HOPCOUNT as an outbound  
> policy (rather than an inbound policy) would make it consistent  
> with the commonly understood practice of NO_EXPORT. It seems to be  
> a good idea.

No objection from me.

I should point out that regardless of the way the draft describes the  
semantics, the implementation
is free to implement this as an inbound or outbound policy, as it  
sees fit.  For example, given the
current text, an implementation could pre-compute the ingress policy  
that a neighbor would implement
and filter the prefix on the outbound side, effectively making this  
an outbound policy.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Jan 2006 15:32:39 -0800

> AS_HOPCOUNT will always be complete.

We must have some miscommunication on the word "complete".  When an  
originator sets
AS_HOPCOUNT, I would assume that they would set it to some non-zero  
small integer.  It would
only be complete when it had subsequently traversed multiple ASs and  
the value had been
decremented to zero.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Wed, 4 Jan 2006 23:50:40 +0000 (GMT)

On Wed, 4 Jan 2006, Tony Li wrote:

> We must have some miscommunication on the word "complete".

I think so. It was the "completed" word in your other email that 
threw me into thinking you were referring to some language in the 
draft.

> When an originator sets AS_HOPCOUNT, I would assume that they would 
> set it to some non-zero small integer.  It would only be complete 
> when it had subsequently traversed multiple ASs and the value had 
> been decremented to zero.

Ah, in every case where I've used "complete" or "partial", I've been 
referring to the Partial bit in the attribute flags header.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
All intelligent species own cats.

---

From: Joe Abley <[email-masked]>
Date: Thu, 5 Jan 2006 00:50:52 -0500

> I have read the entire thread to date and don't believe I'm  

The NO_EXPORT/AS_HOPCOUNT interaction described in the current draft  
were based on an old (unsubmitted) draft I wrote which was conceived  
very much from the perspective of trying to conservatively restrict  
propagation of routes covering the addresses of anycast services.  
(Apologies for not speaking up sooner; my traditional New Year's  
hangover was concatenated with influenza.)

The motivations for abusing NO_EXPORT in this way were that the  
implications for a leak from an anycast node in a region with poor  
external connectivity are often serious, and in many cases not  
propagating the prefix as widely as we could is preferable to  
accidentally propagating it globally. For example, propagating the  
covering route for F.ROOT-SERVERS.NET from ISC's anycast node in  
Nairobi could be bad for many people, both inside and outside Kenya.

Export policies are frequently designed and implemented to prevent  
peer routes leaking to transit providers for obvious reasons;  
however, in practice, we find ourselves deploying infrastructure in  
regions where the concept of "export policy" is not well-known, and  
BGP configurations are apparently copied verbatim from the backs of  
cereal boxes. Not all of these regions are those that would be  
normally considered to be in the developing world. Hence, we like the  
paranoid approach of setting NO_EXPORT on 192.5.5.0/24 from our local  
nodes, since the peers most likely to leak are also the peers least  
likely to know how to remove it, or to even notice it is there. We  
soak up queries from the client population that we miss with this  
conservative propagation strategy on a smaller number of bigger, well- 
connected anycast nodes.

There has been various discussion over the past week or so about how  
the unusual interaction between NO_EXPORT and AS_HOPCOUNT specified  
in this draft could cause confusion, e.g. by those practicing proxy  
application of NO_EXPORT, which for routes which also happen to carry  
AS_HOPCOUNT might not prevent the route from being exported. Breaking  
deployed expectations of NO_EXPORT does indeed seem bad. Since the  
whole NO_EXPORT/AS_HOPCOUNT interaction is a bit of a cheap short- 
cut, designed to allow use of AS_HOPCOUNT without waiting for  
widespread adoption of the AS_HOPCOUNT mechanism, perhaps the  
collateral ugliness is not justified.

As someone else here suggested (and as Tony pointed out to me)  
changing the AS_HOPCOUNT attribute to represent an upper bound on the  
length of an AS_PATH (and discarding the NO_EXPORT interaction) might  
be a useful compromise, since a prefix leaked by a non-AS_HOPCOUNT- 
aware speaker would continue to accrue AS_PATH length through non- 
AS_HOPCOUNT-aware routers, and would be suppressed by the first  
AS_HOPCOUNT-aware speaker it came across.

The only other mechanism that occurred to me was to replace the  
current proposed NO_EXPORT interaction with a capabilities  
negotiation in the specification such that an AS_HOPCOUNT-capable  
speaker would append a NO_EXPORT community-string attribute to routes  
carrying AS_HOPCOUNT in the case where it exports routes towards a  
non-AS_HOPCOUNT-capable speaker. This would provide a more  
conservative strategy for route propagation, but it seems dirtier  
than using AS_HOPCOUNT to bound an AS_PATH length. It also doesn't  
support the alternative, more leak-tolerant semantics achieved in the  
current proposal by adding AS_HOPCOUNT without NO_EXPORT.

Joe

---

From: Danny McPherson <[email-masked]>
Date: Wed, 4 Jan 2006 23:06:39 -0700

On Jan 4, 2006, at 10:50 PM, Joe Abley wrote:

> changing the AS_HOPCOUNT attribute to represent an upper bound on  
> the length of an AS_PATH (and discarding the NO_EXPORT interaction)  
> might be a useful compromise, since a prefix leaked by a non- 
> AS_HOPCOUNT-aware speaker would continue to accrue AS_PATH length  
> through non-AS_HOPCOUNT-aware routers, and would be suppressed by  
> the first AS_HOPCOUNT-aware speaker it came across.

I like this idea much better as well, assuming it accounts for private
AS, AS confederation path segments, AS sets, etc..

> speaker would append a NO_EXPORT community-string attribute to  
> routes carrying AS_HOPCOUNT in the case where it exports routes  
> towards a non-AS_HOPCOUNT-capable speaker. This would provide a  
> more conservative strategy for route propagation, but it seems  
> dirtier than using AS_HOPCOUNT to bound an AS_PATH length. It also  
> doesn't support the alternative, more leak-tolerant semantics  
> achieved in the current proposal by adding AS_HOPCOUNT without  
> NO_EXPORT.

Not only would this require some more dynamic knowledge (e.g., BGP
Capabilities functions) of what capabilities the neighbor supports, it's
something that may vary even within a single AS.

I agree - I like the idea of examining the AS path and using that  
mechanism
instead...

-danny

---

From: Tony Li <[email-masked]>
Date: Thu, 5 Jan 2006 00:57:03 -0800

>> the length of an AS_PATH (and discarding the NO_EXPORT  
>> interaction) might be a useful compromise, since a prefix leaked  
>> by a non-AS_HOPCOUNT-aware speaker would continue to accrue  
>> AS_PATH length through non-AS_HOPCOUNT-aware routers, and would be  
>> suppressed by the first AS_HOPCOUNT-aware speaker it came across.
>

Danny,

I would word it so that the hopcount explicitly does NOT count  
private ASs or confederation ASs.
AS sets would still count as one hop per set member.

Does that match what you're saying?

Tony

---

From: Danny McPherson <[email-masked]>
Date: Thu, 5 Jan 2006 07:41:51 -0700

> Does that match what you're saying?

Yes!

-danny