Subject: [Idr] AS hopcount draft as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Sun, 23 Oct 2005 19:38:50 -0700

Folks,

We received a request (see below) to accept draft-li-as-hopcount-03.txt
as an IDR WG document.

Comments are greatly appreciated. The deadline for comments is
November 6, 2005 (not 10/31, as mentioned below).

Yakov.
------- Forwarded Message

Date:    Sun, 23 Oct 2005 16:46:27 -0700
From:    Tony Li <[email-masked]>
To:      [email-masked]
Subject: [Idr] AS hopcount draft

All,

After our Paris discussion, the AS hopcount draft has been modified  
as discussed to include a 4 byte AS number as part of the attribute  
to aid in debugging.  I would like to propose that this become a WG  
document at this point.  If folks have objections to this or  
comments, could you please voice them by Monday, 10/31 (boo!).

The current draft can be found here:
http://www.ietf.org/internet-drafts/draft-li-as-hopcount-03.txt

Thanks,
Joe, Rex & Tony

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

------- End of Forwarded Message

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

---

From: "Elmar K. Bins" <[email-masked]>
Date: Mon, 24 Oct 2005 09:39:25 +0200

> November 6, 2005 (not 10/31, as mentioned below).

I - as a newbie to this list - would like to comment in a somewhat
private way on this; I'd anyhow like to share my thoughts and I
hope I'm not too far off-topic.

I like this proposal very much, because it enables conscious
operators to somewhat "confine" their more specific advertisements
(or, their advertisements at all) to a certain radius.

I personally would like this level of control over the prefixes
I use for anycasting. Controlling load-sharing over anycast
locations is a pretty hard job, and the control is not really
better than marginal.

I also see an application in more-specific multi-homing. We'll
be needing this in the next year, splitting our PA block in the
process (not wanting to waste address resources on top of using
up additional slots in the BGP tables). And since we're such
good netizens, we'd like to be able to confine the more specifics'
propagation to some radius that covers all locations involved. The
aggregate will provide for fallback connectivity.

Unfortunately, I strongly believe that not everybody that could
use the AS hopcount feature will actually use it without being
given additional incentive. As per the proposal, setting the NLRI
is entirely voluntary. It also involves (a) an understanding of
how DFZ routing works, (b) an idea of how far into the DFZ their
advertisements need to be seen, and (c) the will to confine the
advertisements.

Would you consider using AS hopcount as a way to lighten DFZ tables
from more-specific multi-homing garbage an abuse of the scheme?

If not, does anybody have an idea of how to get people to confine
their more specific prefixes, some way of incentive? I'm not sure
if this can be done in the draft itself. This may need to be
addresses separately, but could be mentioned alongside the draft.

Thanks for listening,
			Elmar.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Oct 2005 14:59:55 +0300 (EEST)

> (or, their advertisements at all) to a certain radius.

note: I only took a quick look at the document.

Is this approach really useful?  That is,

  a) an "AS" is a coarse concept.  A single router, or a single AS 
could span across the globe.  Thus, "AS hop count" in itself doesn't 
buy you much.

  b) given a), this attribute would likely only be used with small hop 
counts, say 1-3, because if the operator doesn't investigate the 
AS-level topology in detail, (s)he cannot know which count (s)he would 
want to use to obtain the intended policy.  I'm assuming investigation 
of AS-based topology beyond a couple of AS hops would be infeasible.

  c) as reducing the hop count per traversed AS requires support for 
this attribute, until this is deployed everywhere, the usage is even 
more challenging. That is, it's not enough to figure out the AS-level 
topology, you also need to figure out (and monitor) whether they 
support AS hopcount, and how to take it into the account in setting 
the AS level hopcount.

So, I'm a bit of skeptic whether this kind of tool is useful enough 
for the intended purpose (i.e., would it become used).  As it happens, 
you can already use NO_EXPORT for hop 1, and in most cases 
provider-specific communities for hop 2.  I'm not sure if it's clear 
enough that a more generic solution is necessary.

btw. is a confederation peer considered 'an external peer' ?

-- 
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: "Elmar K. Bins" <[email-masked]>
Date: Mon, 24 Oct 2005 14:09:56 +0200

Pekka :)

> note: I only took a quick look at the document.

You should, it would answer your question c)

> could span across the globe.  Thus, "AS hop count" in itself doesn't 

You'll have to decide whether it's useful for your AS.

> of AS-based topology beyond a couple of AS hops would be infeasible.

One could start experimenting, though :)

> enough that a more generic solution is necessary.

If it would be used at all, and large-scale, we could get quite a lot
of rubbish out of the DFZ, buying a couple more years.

Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
                          (PLemken, <[email-masked]>)

--------------------------------------------------------------[ ELMI-RIPE ]---

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2005 11:17:14 -0400

In message <[email-masked]>
Yakov Rekhter writes:
>  
> Folks,
>  
> We received a request (see below) to accept
> draft-li-as-hopcount-03.txt as an IDR WG document.
>  

This draft provides a useful mechanism for limiting the scope of
routing information that is needed only for localized traffic
engineering (where localized can span continents and indeed does in a
well known example of intended usage).  The use of AS_HOPCOUNT and
NO_EXPORT together as described in the draft provides a transition
mechanism that will prevent any significant harm to the network as a
result of partial deployment of this feature.

I agree with the proposal that draft-li-as-hopcount-03.txt should
become a WG document.

Curtis

All,

Thanks,
Joe, Rex & Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2005 11:52:04 -0400

> btw. is a confederation peer considered 'an external peer' ?

Pekka,

I think the motivation for this would be the problem that the POISSON
WG set out to address but never found a solution for.

The specific example that was used in POISSON was Australian providers
using a large number of more specific routes advertised to multiple
global providers in order to balance the load from the US west coast
across these providers.  Much of that traffic was from other providers
within the US or from Europe where the more specific routes were not
needed.

Limiting the scope of these more specific prefixes reduced global
routing while still allowing providers to do this sort of load
balancing.  Since we know that this is being done, deployment, even
partial deployment would reduce the amount of unnessecary global
routing information.  Therefore, yes it is useful.

Please feel free to correct me if I got this wrong since I'm not part
of any team that put this together or discussed this in Paris.

Curtis

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Oct 2005 15:57:47 -0700

Hi Curtis,

I agree with you and support this to become an IDR WG doc.

Even if ever AS_HOPCOUNT is used to limit specific propagation of just 1 
hop away it already will be very useful.

And and far as additional incentive goes .. proper network design should 
be enough of incentive :). Maybe that goes against $$$$ rule but IMHO it 
goes along the real large scale network design principle (if that even 
still matters these days :-).

Cheers,
R.