Subject: [Idr] AS hopcount draft (redux)

From: Tony Li <[email-masked]>
Date: Wed, 16 Nov 2005 15:45:04 -0800

Hi all,

Last month we sent around an email request asking that draft-li-as- 
hopcount-03 become a WG document.
There was little discussion but the responses to the mailing list  
were clearly favorable.

As part of the physical meeting, the WG was again polled and it was  
deemed that there was insufficient
interest, although these results may be skewed by the attendance of  
the meeting itself.

We would like to renew our request that this become a WG document and  
ask that those interested in this
document speak up on-list.

Thanks,
Rex & Joe & Tony

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 16 Nov 2005 20:58:25 -0500

In message <[email-masked]>
Tony Li writes:
> hopcount-03 become a WG document.  There was little discussion but the
> responses to the mailing list were clearly favorable.
>  
> deemed that there was insufficient interest, although these results
> may be skewed by the attendance of the meeting itself.
>  
> ask that those interested in this document speak up on-list.
>  
> Thanks,
> Rex & Joe & Tony

Simple.

Useful.

Can be used to address the need that PTOMANE was focused on.

What I said last time ...

Should be a WG doc.

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Nov 2005 07:14:35 +0000 (GMT)

On Wed, 16 Nov 2005, Tony Li wrote:

> Last month we sent around an email request asking that 
> draft-li-as-hopcount-03 become a WG document. There was little 
> discussion but the responses to the mailing list were clearly 
> favorable.

> may be skewed by the attendance of the meeting itself.

IIRC there was a pretty clear show of hands in Paris to adopt as WG 
document.

> We would like to renew our request that this become a WG document 
> and ask that those interested in this document speak up on-list.

It seems it could be very useful. And reasonably simple.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Ditat Deus.
 	[God enriches]

---

From: "Elmar K. Bins" <[email-masked]>
Date: Thu, 17 Nov 2005 08:53:05 +0100

Just to give it some leverage...

> It seems it could be very useful. And reasonably simple.

I second that and would like to see it implemented.

Elmar.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Nov 2005 12:43:57 +0200 (EET)

On Thu, 17 Nov 2005, Paul Jakma wrote:
>> We would like to renew our request that this become a WG document and ask 
>> that those interested in this document speak up on-list.
>

While I can see it seems simple, I don't see how it would be very 
useful.  As the mesh of interconnections gets more and more dense, I 
don't believe it's really a sufficient mechanism to express (the 
intended) policy.

That is, is there any real examples of applicability of AS hopcount 
with value >= 3 ?  I'd certainly be interested in hearing about it and 
the policy goal behind such use.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2005 03:25:25 -0800

Pekka,

> don't believe it's really a sufficient mechanism to express (the 

Your doubts that the idea may not address few possible interconnect 
topologies and may not be the universal solution for limiting update 
propagation for generations to come is IMHO not a sufficient argument 
not to progress with the draft and make it a WG doc to address all other 
much more controled AS meshes.

Imagine there is a network operator who owns number of ASes and wants to 
limit some information distribution in one of BGP SAFIs just to his 
domain. The usual topology is one AS in the core surranded by reginal 
ASes. If he configured AS_HOPCOUNT to 3 and do not peer (by design) from 
the core AS his problem is easily solved.

Cheers,
R.

> That is, is there any real examples of applicability of AS hopcount with 
> value >= 3 ?  I'd certainly be interested in hearing about it and the 
> policy goal behind such use.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Nov 2005 13:32:29 +0200 (EET)

On Thu, 17 Nov 2005, Robert Raszuk wrote:
> limit some information distribution in one of BGP SAFIs just to his domain. 
> The usual topology is one AS in the core surranded by reginal ASes. If he 
> configured AS_HOPCOUNT to 3 and do not peer (by design) from the core AS his 
> problem is easily solved.

Are you saying that there are real topologies where there are about 3 
levels of (hierarchical) ASes under one administrative domain where 
this kind of control would be desirable?

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2005 03:40:44 -0800

Pekka,

Correct ... To clarify it does not need to be 3 levels in a hierarchy. 
It can be just plain flat string of ASes. As described one core AS and 
few ASes around it.

Thx,
R.

>> Imagine there is a network operator who owns number of ASes and wants 
>> to limit some information distribution in one of BGP SAFIs just to his 
>> ASes. If he configured AS_HOPCOUNT to 3 and do not peer (by design) 
>> from the core AS his problem is easily solved.
> 
> 
> levels of (hierarchical) ASes under one administrative domain where this 
> kind of control would be desirable?
> 
> 
>

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Nov 2005 12:11:56 +0000 (GMT)

On Thu, 17 Nov 2005, Pekka Savola wrote:

> useful.  As the mesh of interconnections gets more and more dense, 
> I don't believe it's really a sufficient mechanism to express (the 
> intended) policy.

> with value >= 3 ?  I'd certainly be interested in hearing about it 
> and the policy goal behind such use.

The 2 hop case certainly seems something that it'd be useful to 
specify formally (beyond any AS-specific 'action' communities offered 
by some ASes today).

If there is consensus on that (?), then it seems just as much effort 
to introduce and roll-out a new well-known community as the more 
generalised, yet still simple enough, hopcount attribute.

The density of AS hierarchy, no idea. Perhaps at some stage we'll 
need a better well-known path metric than the current AS_PATH length. 
Granularity of 1 is obviously very coarse when average length is 
(what) 3.9? That's possibly an argument for maybe trying to 
future-proof AS_HOPCOUNT a bit with an additional type to allow for 
any future refinement of metrics maybe. Nature of such refinements, 
who knows - for another thread some other day ;).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
There is no distinctly native American criminal class except Congress.
 		-- Mark Twain

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Nov 2005 20:33:21 +0200 (EET)

On Thu, 17 Nov 2005, Paul Jakma wrote:
> The 2 hop case certainly seems something that it'd be useful to specify 
> formally (beyond any AS-specific 'action' communities offered by some ASes 
> today).

But is that useful enough to fulfill the intended policy?  Someone's 
policy could be for example, "I want to only get regional or national 
traffic via this advertisement".  This mechanism does not fulfill 
that goal, as the site who sends the community has to (AFAICS) both:

  1) know the network topology to the depth of $HOPCOUNT AS numbers, and
  2) know which ones implement AS-hopcount

These are very demanding constraints and I doubt it offers a very 
useful tool for affecting intended (more fine-grained) policy.

But maybe the goal of AS hopcount isn't that, but rather something 
much coarser, for example enabling an endsite to say, "OK, we'll try 
advertising with HOPCOUNT = 1,...,n until we get the degree of inbound 
traffic balancing as we want and stick with that value.  We don't care 
where that traffic comes from".

For that the feature could be useful.

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Nov 2005 20:04:49 +0000 (GMT)

On Thu, 17 Nov 2005, Pekka Savola wrote:

> But is that useful enough to fulfill the intended policy?

Is it intended for such specific policy though? It seems intended 
more as a "green" bgp-eco-friendly feature, limiting the scope of 
'noisy' routes generally, than as a way to implement very specific 
policy.

> Someone's policy could be for example, "I want to only get regional 
> or national traffic via this advertisement".  This mechanism does 
> not fulfill that goal, as the site who sends the community has to 
> (AFAICS) both:
>
> These are very demanding constraints and I doubt it offers a very useful tool 
> for affecting intended (more fine-grained) policy.

ACK.

> much coarser, for example enabling an endsite to say, "OK, we'll 
> try advertising with HOPCOUNT = 1,...,n until we get the degree of 
> inbound traffic balancing as we want and stick with that value. 
> We don't care where that traffic comes from".

Yep. Or just restricting more specifics so that only 1/x (where X is 
I guess not a terribly large integer, given the average path length) 
of the internet has to burdened, rather than all of it.

> For that the feature could be useful.

I reckon so too.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Compliment, n.:
 	When you say something to another which everyone knows isn't true.

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 17 Nov 2005 22:44:33 +0100

Robert,
> the core AS his problem is easily solved.

In this case, since the same operator owns a number of ASes, it looks
easier to use communities or extended communities to achieve the same
goal. This can be made more explicit in the BGP configurations and does
not suffer from problems when the interconnection between the ASes change.

Olivier

---

From: Joe Abley <[email-masked]>
Date: Thu, 17 Nov 2005 19:48:11 -0500

On 17-Nov-2005, at 13:33, Pekka Savola wrote:

>> specify formally (beyond any AS-specific 'action' communities  
>> offered by some ASes today).
>

I agree it is no magic bullet.

The problem at the moment for people who wish to experiment with  
short-distance propagation of routes is that there are very few tools  
in the toolbox; there's NO_EXPORT and there's ad-hoc community  
attribute support from various providers, which is expensive to  
implement if you have a lot of external sessions.

The AS_HOPCOUNT attribute is a differently-shaped screwdriver, but  
nobody should expect it to fit every single kind of screw.

The toolbox is currently so empty that any additional tools would be  
welcome, however.

> inbound traffic balancing as we want and stick with that value.  We  
> don't care where that traffic comes from".
>

Right.

I think this mechanism is of limited interest to ASes who connect  
near the topological centre of the Internet (as measured, loosely- 
speaking, according to where traffic is sunk or sourced), since the  
set of routes with an AS_PATH length of 1 can frequently represent  
most traffic sinks or sources, and the rest doesn't always represent  
enough to bother optimising.

However, outside the big markets of North America and Western Europe  
(and parts of Africa connected by tier-1 satellite operators,  
interestingly), the geo-economic difference between routes with an  
AS_PATH length of (say) 2 and 5 can be very useful to distinguish  
between.

One additional application for this attribute that I don't think I've  
seen in this thread is controlling the propagation of covering  
prefixes for anycast services. This application is very similar to  
the problem of inter-domain traffic engineering, but it's slightly  
different and hence arguably worth mentioning.

(See the discussion of "local nodes" in draft-ietf-grow-anycast-02,  
for example. I'm happy to expand on this here if people think that  
would be useful.)

Joe

---

From: Geoff Huston <[email-masked]>
Date: Sat, 19 Nov 2005 08:13:57 +1100

I'm in favour of adopting the hop count draft

   Geoff

---

From: Danny McPherson <[email-masked]>
Date: Fri, 18 Nov 2005 15:29:49 -0700

> I'm in favour of adopting the hop count draft

I believe it's generally useful and a worthwhile WG item as well.

-danny

---

From: Tony Tauber <[email-masked]>
Date: Tue, 22 Nov 2005 13:43:57 -0800 (PST)

> I believe it's generally useful and a worthwhile WG item as well.

Yes, let's adopt.

Tony