Subject: [GROW] Fwd: I-D Action:draft-mcpherson-unique-origin-as-00.txt

From: Danny McPherson <[email-masked]>
Date: Wed, 15 Sep 2010 13:19:09 -0400

GROW Folk, 
I'd like to request that the WG consider adopting this as a WG document.  

Feedback is most welcome, thanks!

-danny

Begin forwarded message:

> From: [email-masked]
> Date: September 10, 2010 6:30:02 PM EDT
> To: [email-masked]
> Subject: I-D Action:draft-mcpherson-unique-origin-as-00.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Unique Per-Node Origin ASNs for Globally Anycasted Services
> 	Author(s)       : D. McPherson, et al.
> 	Filename        : draft-mcpherson-unique-origin-as-00.txt
> 	Pages           : 12
> 	Date            : 2010-09-10
> 
> This document makes recommendations regarding the use of unique
> origin ASNs for globally anycasted critical infrastructure services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mcpherson-unique-origin-as-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Sep 2010 23:13:27 -0400

Can we get some discussion and a decision (hopefully) before the
Bejing meeting? (Timeline-wise that means a decision about the draft
worthwhile/not + WG adoption in ~4 weeks time.)

-Chris

On Wed, Sep 15, 2010 at 1:19 PM, Danny McPherson <[email-masked]> wrote:
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 16 Sep 2010 07:19:06 -0500

I support this document as worthwhile for WG adoption.  However I do have some comments.

The first comment is that, while I agree with the conclusions of the document in general, I don't entirely see what operational problems are caused by single-ASN anycast deployments.  It certainly seems more convenient to have unique ASNs for each node, but I can't imagine a concrete need.  This is probably due to my lack of imagination and/or experience with the problems the authors have encountered, so I'd suggest the draft expands on this topic.

My second comment is that the document should acknowledge the case where a common ASN is desirable.  For instance, information "hiding" might be a desired benefit of using a single ASN for all nodes.  Obviously the draft should recommend the approach with the most benefit, having enumerated the pros and cons.  But it should acknowledge the cons of multiple ASNs (aka the pros of single ASN) as well.

Thanks,
-Benson

---

From: Danny McPherson <[email-masked]>
Date: Thu, 16 Sep 2010 08:26:58 -0400

On Sep 16, 2010, at 8:19 AM, Benson Schliesser wrote:

> The first comment is that, while I agree with the conclusions of the document in general, I don't entirely see what operational problems are caused by single-ASN anycast deployments.  It certainly seems more convenient to have unique ASNs for each node, but I can't imagine a concrete need.

Detection of route leaks is _much more difficult if a common origin ASN could pop up anywhere with any set of adjacent upstream ASNs.  This helps with that aspect.  Additionally, if a particular node were exhibiting some anomalous conditions, e.g., routing instabilities resulting the in entire prefix being surprised via flap damping, or perhaps some aberrant datapath behavior, this would provide a discriminator for which operators might consider routing policy specification over.

>  This is probably due to my lack of imagination and/or experience with the problems the authors have encountered, so I'd suggest the draft expands on this topic.

Yep, great point, definitely will..  And if others have ideas, please pass'm along..

> My second comment is that the document should acknowledge the case where a common ASN is desirable.  For instance, information "hiding" might be a desired benefit of using a single ASN for all node…

Yeah, another good point.  I'll give due consideration to both these points in the next revision.

Thanks for the feedback Benson, 

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 16 Sep 2010 08:31:21 -0400

On Sep 16, 2010, at 8:26 AM, Danny McPherson wrote:

> Detection of route leaks is _much more difficult if a common origin ASN could pop up anywhere with any set of adjacent upstream ASNs.  This helps with that aspect.  Additionally, if a particular node were exhibiting some anomalous conditions, e.g., routing instabilities resulting the in entire prefix being surprised via flap damping,

s/surprised/suppressed/  -- although the latter often results in the former ;-)

-danny

> or perhaps some aberrant datapath behavior, this would provide a discriminator for which operators might consider routing policy specification over.

---

From: Joe Abley <[email-masked]>
Date: Thu, 16 Sep 2010 12:31:28 -0400

>> I support this document as worthwhile for WG adoption.  However I do have some comments.

I also support adoption, although I would like to see the document become more of a recorded discussion on the relative merits of unique-origin-AS vs. overloaded-origin-AS than a general recommendation for one over the other.

> Detection of route leaks is _much more difficult if a common origin ASN could pop up anywhere with any set of adjacent upstream ASNs.

I'd like to see a worked example that illustrates these difficulties. Whilst node identification is useful and to be recommended (e.g. see RFC 4786 section 4.9) it's not clear to me that it's good general advice to insist that this be done with AS_PATH.

> This helps with that aspect.  Additionally, if a particular node were exhibiting some anomalous conditions, e.g., routing instabilities resulting the in entire prefix being surprised via flap damping, or perhaps some aberrant datapath behavior, this would provide a discriminator for which operators might consider routing policy specification over.

The advice we got from a number of prominent vendors at the time we were working on 4786 was that prefixes aren't damped; paths are damped. The choice of origin AS hence only makes a difference in the case where multiple anycast nodes are advertising service prefixes to the same adjacent AS. This is functionally identical to a flapping interconnect between (say) two ISPs in a situation where there are multiple adjacencies between their ASes, e.g. peering in multiple cities/continents/whatever.

> Yeah, another good point.  I'll give due consideration to both these points in the next revision.

We went down the road of using different AS numbers per node at ISC when we distributed F-Root, but still used a consistent origin AS (3557). The per-node AS was the next one in the AS_PATH (i.e. ..._peer_node_3557$). It was observed more than once that we were wasting number resources (16-bit AS numbers) by assigning an AS per node. Increasing tolerance for 32-bit AS numbers mitigates this, but there is I think some truth in the general rule that any time you treat resources as infinite they wind up being very finite.

Another practical consideration is that many ASes with whom you might want to peer (as the operator of an anycast content distribution system of some kind) will be happy to talk to you if they can reach your AS in multiple locations, because that fits their existing peering model. Suggest a different AS in each location and the answer is no, because you don't meet their multiple-location policy.

Joe

---

From: Danny McPherson <[email-masked]>
Date: Thu, 16 Sep 2010 12:55:33 -0400

> I also support adoption, although I would like to see the document become more of a recorded discussion on the relative merits of unique-origin-AS vs. overloaded-origin-AS than a general recommenda…

OK, I can try to talk about the ease of use of a common AS, the number space preservation, etc..  I'm happy to try and captures the pros and cons of each and will attempt to accommodate in the next spin.

> I'd like to see a worked example that illustrates these difficulties. Whilst node identification is useful and to be recommended (e.g. see RFC 4786 section 4.9) it's not clear to me that it's good…

So I can expand on what's in the draft and perhaps reconsider text.  However, I think simply the fact that there's no unique discriminator in the routing system in and of itself should illustrate why detection of leaks or rogue instances is problematic.  Beyond AS_PATH, I can't think of another mandatory transitive attribute in BGP that would be used to discriminate particular instances and align with work being done to align with current RPKI machinery.  

I didn't intended to insist anything, just to highlight that it can be useful in oeprations.  On redraft I'll try to reflect that.

> The advice we got from a number of prominent vendors at the time we were working on 4786 was that prefixes aren't damped; paths are damped. The choice of origin AS hence only makes a difference in…

That's not my understanding, my understanding is that most (all?) implementations are per-prefix (I would love to see per-path implementation, and hope folks correct me here), and the measurements I've seen around this highlight just that.  E.g.,:

<http://www.cs.ucla.edu/~jpark/dupbgp.pdf>

Further, RFC 2439 S 4.4.3 and beyond suggests only prefix and length need to be considered.  Path is much harder, obviously.

> We went down the road of using different AS numbers per node at ISC when we distributed F-Root, but still used a consistent origin AS (3557). The per-node AS was the next one in the AS_PATH (i.e. .…

Well, intermediate ASes in the path, as F-root does, don't entirely address my problem.  That is, a detection model would have to accept the set of adjacent ASNs for a given origin {origin, adjacent_as_group(1..n)}, where path set could be hundreds of adjacent ASNs.  I want to be very specific about origin and adjacent topology models ( {origin1, adjacent_as(1,2)} | {origin2,adjacent_as(3,4) | ..).  Further, if one wanted to employ RPKI machinery origin is useful.

> Another practical consideration is that many ASes with whom you might want to peer (as the operator of an anycast content distribution system of some kind) will be happy to talk to you if they can…

And that's yet another reason why highlighting the benefits and utility of this is important.  

Good feedback as usual Joe, I'll try to accommodate your concerns in the next revision.

Thanks!

-danny

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Fri, 17 Sep 2010 04:47:13 +0100

Hi,

I support the adoption of the document.

On 9/16/10 5:31 PM, Joe Abley wrote:

> become more of a recorded discussion on the relative merits of
> unique-origin-AS vs. overloaded-origin-AS than a general
> recommendation for one over the other.

I agree with the Joe here. There are both pros and cons of
Unique-origin-AS vs. single-origin-AS, and it's best to have them
documented rather then one approach being preferred over the other.

>> 
>> Detection of route leaks is _much more difficult if a common origin
>> ASN could pop up anywhere with any set of adjacent upstream ASNs.

Over time, I believe critical infrastructure providers have built their
own mechanisms to detect leaks and track the propagation of routes. It
would be good to see how it has been handled so far.

> 
> Another practical consideration is that many ASes with whom you might
> want to peer (as the operator of an anycast content distribution
> system of some kind) will be happy to talk to you if they can reach
> your AS in multiple locations, because that fits their existing
> peering model. Suggest a different AS in each location and the answer
> is no, because you don't meet their multiple-location policy.

It will also be a rather large undertaking for existing anycast
providers to re-number into unique-origin-AS and deal with 100s if not
1000s of peering sessions, IXP databases and websites.

- -gaurab

- -- 

http://www.gaurab.org.np/

---

From: Danny McPherson <[email-masked]>
Date: Fri, 17 Sep 2010 15:50:07 -0400

On Sep 16, 2010, at 11:47 PM, Gaurab Raj Upadhaya wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 

Gaurab,
As noted, I'll add some text to try and accommodate this input from you and Joe in the next revision.

Thanks much for the review and feedback!

-danny

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkyS5MEACgkQSo7fU26F3X3M6gCeMWtjK3ifRg0LbQ2rz4jkbTnw
> PngAnika9t7BaD86aQ1ypwIgNaYV0pnv
> =Q3LC
> -----END PGP SIGNATURE-----