Subject: Re: [v6ops] [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document

From: Randy Bush <[email-masked]>
Date: Fri, 24 Aug 2012 17:30:53 +0700

for your amusement, today in the routing worshop in phom penh, the
lecture includes rfc 2770 and using only one asn for a large number
of customers multi-homed to my network.  aside from the benefits i
remembered, i was reminded that it even makes peer groups sexier.

randy

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Aug 2012 07:25:00 -0500

> remembered, i was reminded that it even makes peer groups sexier.

Sorry but I'm confused, RFC 2770 is about GLOP Multicast Addressing, 
which was obsoleted by RFC 3180, how does that apply to this discussion?

Did you mean RFC 5065 - Autonomous System Confederations for BGP or RFC 
2796 - BGP Route Reflection - An Alternative to Full Mesh IBGP obsoleted 
by RFC 4456, or maybe something else?

Thanks
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Aug 2012 19:46:27 +0700

>> remembered, i was reminded that it even makes peer groups sexier.

sorry, 2270

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Aug 2012 08:44:01 -0500

>>> remembered, i was reminded that it even makes peer groups sexier.

Thanks for the correction, I guess my RFC Index searching foo wasn't 
good enough to catch that one. :(

So in the workshop were they suggesting using a private ASN or a public 
registered ASN for this purpose?  Both options are discussed in RFC 
2270.  Would you suggest the RIRs have policy to allow a separate public 
registered ASN for this purpose?

Are the slides available?

Thanks

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Aug 2012 21:55:10 +0700

> So in the workshop were they suggesting using a private ASN or a
> public registered ASN for this purpose?

the example used is private, but we try to teach principles.  this is
common practice in the ops world.

> Would you suggest the RIRs have policy to allow a separate public

i would hope we would be getting past micromanaging at that level of
detail.  see http://www.apnic.net/policy/proposals/prop-103

> Are the slides available?

well, there is a long trail of this slide set, as pfs has been teaching
the bgp workshops for a decade or so.

randy

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Aug 2012 10:19:14 -0500

> common practice in the ops world.

I understand, but I thought you we advocating that people shouldn't use 
private ASNs and therefore we don't need an additional 4-byte ASN block. 
  Did I misunderstand you?  Using Private ASNs relies on the Private ASN 
filtering many implementations have.  If you use a Public ASN are there 
common tools to filter a Public ASN as the RFC suggests you do?  I'm not 
aware of them, so I'm asking.

> detail.  see http://www.apnic.net/policy/proposals/prop-103

Well APNIC requires multihoming to receive and ASN as do all of the 
other RIRs as far as I know.

From: http://www.apnic.net/policy/asn-policy ;
-----
5. Eligibility for ASN assignment

An organization is eligible for an ASN assignment if it:

     a. is multihomed; and
     b. has a single, clearly defined routing policy that is different 
from its providers' routing policies.

An organization will also be eligible if it can demonstrate that it will 
meet the above criteria upon receiving an ASN (or within a reasonably 
short time thereafter).
-----

So the problem is ASNs are already micro-manged by the RIRs, should we 
relieve some of the micro-management?  Maybe go back to the only 
requiring a unique routing policy with or without multihoming, before 
discontinuing any policy changes. :)

We really shouldn't pollute the IETF list with RIR policy discussions, 
but I believe if we don't provide a bigger 4-byte Private ASN range then 
we need to reform the RIR ASN policy regime.  Personally, I prefer both, 
but I'm trying to understand what you suggest the right thing to do is.

> the bgp workshops for a decade or so.

The PFS pointer is enough

Thanks.

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Aug 2012 19:36:30 +0200

Hi,

> discontinuing any policy changes. :)

How can you have a unique routing policy without multihoming?

(Well, technically you could single-home, and null-route some prefixes
to make your routing different from that of your single upstream, but
I wouldn't count that as "unique routing policy" in the spirit of the
policy)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Aug 2012 08:15:14 +0700

> Did I misunderstand you? 

yes, you misunderstand me

the point of my post is that one asn is sufficient

randy

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 27 Aug 2012 09:28:18 -0400

> remembered, i was reminded that it even makes peer groups sexier.

Randy -

Sure, RFC2270 seems to be one reasonable solution for the use case of an
ISP providing ASNs to single homed customers that do not require route
connectivity to each other except via default, and yes, I'm aware of it
and seen it deployed at multiple places I've worked.  Of course, the
unsaid thing in this draft is that using a seperate (private) ASN per
customer site was not viable due to limited private use ASN space (which
ISP in 1998 when this was published was not anticipating endless
growth!).  Although this would require one more line in your configs per
peer (but in modern BGP implementations not necessarily provide better
update generation which can occur based on same policy applied rather
than peer-groups), but may have some operational/troubleshooting
benefits.  That said, let's assume that you are correct that the
benefits outweigh the cons for using a dedicated ASN for this scenario
in every operators mind.

In other situations, I've seen a similiar approach implemented with
seperate private ASNs to get rid of the implications of section 3.1, not
for Internet table routes, but for routes to be leaked that are internal
to the larger network.  What are "customers of an ISP" in this RFC may
be seperate engineering groups who run regions, DCs, sites, or
sub-organizations... in a large organization.  In these cases, using
seperate (typically private) ASN's allows arbitrary connections between
sites, the use of multiple backbone options (all from internal networks
again which may or may not utilize a public ASN, not Internet
backbones), and the entire organizations routes to be able to be
received from all sites (which is useful when default lies in another
direction than where you want to send traffic).  I believe using
multiple private ASNs in these scenarios is less a hack than trying to
achieve the same with disabling loop detection, arbitrarily mandating no
connectivity between these sub(orgs/sites) and/or requiring them to
merge BGP everytime they bring up a backend connection.  Depending on
the function of said network, there may or may not be an Internet
connectivity requirement for any of these networks at all.  I personally
don't see the use of private ASNs in these cases as an end run around
the RIR's, as Internet connectivity is not a primary function of these
ASNs and if they do have to send some routes to the Internet (which is
not the case for every network) then these would likely come from a
public "boundary" ASN between them and other ISPs, that provides the
private AS stripping function.

Now we've covered a couple of use cases, but my overall position is that
private use ASNs are used in many situations with various routing
requirements, likely a number of which we will not have properly
identified even if we continue to go back and forth on every current and
possible future use case of BGP in networks.  I personally don't feel
the need to debate whether or not all these use cases are valid, as I
think that is orthogonal to whether having a large range is useful.
After all, this is not a draft about keeping or getting rid of private
ASNs.

Jon

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Aug 2012 09:29:34 +0700

> customer site was not viable due to limited private use ASN space

2270 is widely deployed.  i have not run across the case where we wanted
more than one private asn.  any sane provider is doing templated or
generated config, and using a single asn is simpler and just works.

i am sure i can dream up convoluted uses for a mass of as numbers.  but
what i can not do is come up with convoluted case which is worth the end
run on having good registration of the use/assignment of those asns.

randy

---

From: David Farmer <[email-masked]>
Date: Mon, 27 Aug 2012 21:46:06 -0500

> run on having good registration of the use/assignment of those asns.

I'm sorry but it is not a convoluted use case, section 3.1 of RFC 2270 
details the exact case, if the customer wants a full route table.  And 
BGP customer wanting a full global route table in not convoluted, it is 
a perfectly reasonable request from a customer.   If they don't have a 
globally unique ASN to use, then in that case the easiest thing to do is 
use a unique private ASN for that customer and no other customer.  I 
recommend the customer gets an RIR assigned globally unique ASN, but 
some customers don't want to do that.

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Aug 2012 10:00:15 +0700

> details the exact case, if the customer wants a full route table.

yes, that's a bit old.  no problem giving a full table to 942 peers who
all use the same asn.  2270 was written before the "ignore my as in
path" hacks by all vendors.

> I recommend the customer gets an RIR assigned globally unique ASN, but

no problem.  use 2270+ignore-my-asn-hack

this all works.  this is all widely used.  we do not need more
cleverness.  we do not need to end-run the rirs (we need to abolish
them, but that's a whole other discussion in another venue)

randy

---

From: David Farmer <[email-masked]>
Date: Mon, 27 Aug 2012 23:00:46 -0500

> them, but that's a whole other discussion in another venue)

That is just as much of a hack or convoluted way of doing things as you 
claim that using a unique private ASN per customer is a hack or 
convoluted.

Yes, 2270+ignore-my-asn-hack is one way to do things, but using unique 
private ASNs per customer is another reasonable way to do things too. 
They are both more-or-less equal on the hack-o-meeter from my perspective.

I've used both, I generally prefer unique private ASN per customer, but 
YMMV.

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 Aug 2012 11:12:03 +0700

> private ASNs per customer is another reasonable way to do things too. 

"It's perfectly appropriate to be upset.  I thought of it in a slightly
different way--like a space that we were exploring and, in the early
days, we figured out this consistent path through the space: IP, TCP,
and so on.  What's been happening over the last few years is that the
IETF is filling the rest of the space with every alternative approach,
not necessarily any better.  Every possible alternative is now being
written down.  And it's not useful."  -- Jon Postel

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 28 Aug 2012 09:02:28 -0400

> run on having good registration of the use/assignment of those asns.

I agreed that this seems like a fine use case for a single ASN at the
top of the thread, but I guess the convulted use cases you mention here
include the rest of my email which specify why using a single private
ASN in a large single organization (not an ISP) with many sites that may
need to connect to each other (not always through one central AS) would
not be optimal, hence you choose not to respond to that part.  I think
we've also determined you are not supportive of the use of private ASNs
at this point and that you believe every use case is similar enough to
RFC2270 or a network design you believe is convulted.  I'm not sure
continuing debate will do much to change either of our positions.  I
think the quote you replied to David with would have fit better if I was
proposing a change in protocols or how to design networks, when this
draft does neither.  What it does propose is expanding the range of
available asn numbers for private use, a commonly used numbering
resource, in a extremely large available pool.  I admit this may not
pertain to a use case you are familiar with.

Jon