Subject: [Idr] new ID on expansion of private use ASN range

From: Jon Mitchell <[email-masked]>
Date: Mon, 2 Jul 2012 12:48:34 -0400

IDR WG folks -

I hope you can take some time from the normal debate(s) to consider and
review a fresh draft on expanding the ASN space reserved for Private
Use.  All comments regarding content, clarity or structure welcome.

Cheers,

Jon

--

A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt
has been successfully submitted by Jon Mitchell and posted to the IETF
repository.

Filename:        draft-mitchell-idr-as-private-reservation
Revision:        00
Title:           Autonomous System (AS) Reservation for Private Use
Creation date:   2012-06-20
WG ID:           Individual Submission
Number of pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt
Status:
http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation
Htmlized:
http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00

Abstract:
   This document describes the reservation of Autonomous System numbers
   (ASNs) that may be used within networks but should not be advertised
   to the Internet, known as private use ASNs.  This document enlarges
   the total space available for private use ASNs by documenting the
   reservation of a second larger range and updates RFC 1930.

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 02 Jul 2012 19:03:57 +0200

Hi Jon,

I have read your draft few days back and support adopting it as an IDR 
WG doc.

However I have one question/suggestion ...

Perhaps you recall some debates on the topic of reserving some address 
chunk like 1918, but only for operator's use.

Here with private AS numbers we actually are facing the same issue 
today. Flat space introduces a bit of a difficulty when both my internal 
ASes (example: data centers) as well as my customer's ASes use the same 
private as number.

This mandates the knobs like as_override or allowas_in to be applied on 
all address families.

The simplest way to solve it would be to define two blocks of 4 octet 
private AS numbers .. One for multi-as operators and one for stub 
networks. Maybe we could do the same for 2 octet AS numbers too if we 
manage to find some decent block space.

Cheers,
R.

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

---

From: David Farmer <[email-masked]>
Date: Mon, 02 Jul 2012 13:36:53 -0500

> I have read your draft few days back and support adopting it as an IDR

I agree and support support adopting it as an IDR WG doc.

> manage to find some decent block space.

I'm not sure it is a good idea to try to define something like this 
within the limits of 2-Byte ASNs.

I'm not opposed to trying something like this for 4-Byte ASNs.  However, 
the analogy you provide isn't quite accurate, as there isn't really ASN 
translation that I'm aware of.  Stripping of private ASNs could maybe be 
thought of as a type of translation, but it doesn't function quite the 
same way especially as multi-layer CGN/NAT.

I'm not sure defining two layers of private ASNs is going to simplify 
anything though.  A provider will still need uniqueness among its 
customer stub ASNs, or have to use knobs like as_override or allowas_in, 
a million private ASNs will make that a lot easier to maintain 
uniqueness though.

A two layer system, might help if two providers are exchanging private 
ASNs and they both have stub customers out of the other range that are 
stripped.  But is that really a common situation?

I think a million private ASNs will be a much bigger help than trying to 
bifurcate the ranges, but I'm willing to listen to arguments otherwise.

-- 
===============================================
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: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Jul 2012 14:47:37 -0400

Jon,

Several comments:

> Use.  All comments regarding content, clarity or structure welcome.

You beat me to such a draft.  I had one about 2/3 finished and just got
diverted from finishing it. :-)  I thus, obviously, support a draft on this.

I would also suggest that GROW is probably a more appropriate venue for this
draft.

I suggest that we leave 65535 alone as a reserved AS.

I finally suggest that the number of private ASes (967K) is somewhat weird
and would be a counter example of an implementor that would like something
that made a bit more sense boundary-wise.  (It makes staring at the private
stuff in the debugger a bit easier.)

-- Jeff

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 2 Jul 2012 21:10:48 -0400

Comments [JM] Inline...

On Mon, Jul 02, 2012 at 07:03:57PM +0200, Robert Raszuk wrote:
> Hi Jon,
> 
> I have read your draft few days back and support adopting it as an
> IDR WG doc.
> 

[JM] Thanks.

> Perhaps you recall some debates on the topic of reserving some
> address chunk like 1918, but only for operator's use.
> 
> today. Flat space introduces a bit of a difficulty when both my
> internal ASes (example: data centers) as well as my customer's ASes
> use the same private as number.
> 
> This mandates the knobs like as_override or allowas_in to be applied
> on all address families.
> 
> The simplest way to solve it would be to define two blocks of 4
> octet private AS numbers .. One for multi-as operators and one for
> stub networks. Maybe we could do the same for 2 octet AS numbers too
> if we manage to find some decent block space.

[JM] I'm not sure that adding a single second range would alleviate
this.  This seems to suggest that networks and the services they offer
are somewhat static, or that multi-as network operators could not
acquire services from each other?  Given that little guidance is given
to network operators on private Use ASNs by definition I'm not sure that
we could easily define or expect your customers to abide by a defintion
of whether they are a multi-AS operator versus a stub network unless you
are the one doing the ASN assignment, in which case you shouldn't run
into this issue.  The only workable solution I can envision for your use
case that would guarentee uniqueness is a GLOP style block reservations
so anyone with a Public AS would have another set of private ASN to use,
however this is so much more ambitious/complex than my proposal and
would consume potentially a much larger portion of the pool.
 
Unless others weigh in this is a problem space they feel needs to be
solved, I expect that others will accept the existing knobs or the
workaround of using a Public (RIR assigned) ASN to front services when
connecting to private ASNs that customers own.  I also think that this
problem will be less likely to occur with a much wider range of ASNs
available as David mentioned, assuming you are willing to renumber into
a semi-random location in the new range.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 3 Jul 2012 01:44:42 +0000

Jon,

	Seems reasonable.. I do not fully get the context.. You describe the fact that the increase in the number of AS across both l3VPN and Internet use cases are expanding rapidly.. No Doubt... So I see the creation of the new spaces and ranges.. My concerns are in re the Operations Considerations Section

a) You are creating a set of rules for the internet routing context.

"  If private use ASNs are used and prefixes are originated from these
   private use ASNs which are destined to the Internet, private use ASNs
   must be removed from the AS_PATH before being advertised to the
   global Internet.
"
How does this effect folks who use AS_PATH and/or AS_CONTENT in routing policy decisions? Better question is there an issue if all of the Private ASNs are stripped?

b) You specify no rules in re the L3VPN routing context(s). 

c) Not sure how this would work? If someone screws up what is the collateral damage?

"  Prior to making use of the second, numerically
   higher, range of these ASNs network operators should be confident any
   implementation specific features or filters that recognize private
   use ASNs have been updated to recognize both ranges correctly so that
   no unintended announcement of private use ASNs to the Internet
"

Thanks,
	Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Mitchell
Sent: Monday, July 02, 2012 12:49 PM
To: [email-masked]
Subject: [Idr] new ID on expansion of private use ASN range

IDR WG folks -

Cheers,

Jon

--

Abstract:

The IETF Secretariat

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 2 Jul 2012 21:55:21 -0400

Comments [JM] inline...

[JM] Thanks.

> I would also suggest that GROW is probably a more appropriate venue for this

[JM] I have mixed feelings on this which I expressed to both WG chairs,
where the main points for thinking it should be in IDR are:
  1. This is an update to RFC 1930 which is listed as an IDR document,
     albeit very old.
  2. Documentation ASN reservation RFC was published more recently by
     IDR.
  3. GROW charter is focused on Internet scalability and routing, where
     private Use ASN use cases (most?) often involve non-Internet
     routing.

A good case can be made for either in my opinion, but the IDR WG chairs
were OK with it being worked here.  I can definitely send it also to
GROW list for comment either before or after it becomes a WG document,
or whatever makes the IDR WG chairs most comfortable.  GROW WG chairs
are aware of it already...

> I suggest that we leave 65535 alone as a reserved AS.

[JM] I think it should be clarified either way, and I think adding it to
the private use ASN range with this draft is the better approach for the
following reason.  I consider this an after-the-fact registration (RFC
5226 section 6.3) since this ASN seems to have widespread (mis-)use as
many implementations strip it using their remove private ASN knobs and
various networks undoubtedly have it deployed since it seems more than
since a large amount of Internet documentation including RFC 1930 seem
to include it as a private Use ASN.  Also, if this document progress,
implementors will need to update their knobs and documentation anyway,
so they, IETF and IANA can all be on the same page, allowing this ASN to
be stripped if there are vendors that don't do it today (note even some
vendors with published documentation stating that private ASN range is
64512-65534 strip 65535 with their remove private knobs).

> stuff in the debugger a bit easier.)

[JM]  I don't feel strongly either way, expect others will weigh in on
size, placement, and structure of range.  I leaned toward the range
being easily recognizable which is why I choose a nice round number for
the start meaning operators would recognize 4294 (it will be hard to
optimize for both, but frankly anything at the end of the total range of
space should be easily recognizable since is not likely to be assigned
by an RIR for a long time).  Can I suggest your alternative proposal for
folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or
are you suggesting a different range location or sizing?

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Jul 2012 22:12:38 -0400

Jon,

> 64512-65534 strip 65535 with their remove private knobs).

A strong part of my recommendation has to do with the fact that this AS has
assumed a level of "magic" in some implementations.  In the case of much
older implementations on antique hardware may, in fact, be a magic internal
value as it is UINT16_MAX.  As a WG, we can deal with such things two ways:

1. Good grief, your code is that old and broken? Replace it/the hardware.
Let's use it!
2. We don't really need that one extra AS lying around.  Assume it may
potentially be toxic and try to pay no attention to the man behind the
curtains.

I will agree with anyone that the above opinion is one of strong cynicism.
:-)

> Can I suggest your alternative proposal for

If you want ~1M, pick 2^20 addresses.  You could probably even just do 2^16
and have most providers happy.  (2^16 was the number I had in mind for my
draft.)  This lets you align the private AS number at a convenient as.dot
boundary.  I could even forsee someone's CLI saying PRIVATE.<num> :-)

-- Jeff

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 2 Jul 2012 22:20:14 -0400

James - all of these operational concerns exist today with the existing
private Use ASN range when it meets the Internet, and this document is
just acknowledging what operators are already doing (making use of
vendor specific knobs).  Text that generally states private Use ASNs
should not be advertised to the Internet is also in RFC 1930 - section
10.

This document does not intend to dictate as much as acknowledge
operators are using these knobs and providing some general guidance that
they make sure such vendor implementations are updated in accordance
with the draft if they are using them to remove private use ASNs towards
the Internet before using the new range (providing transition guidance
for when/if it's first published).  In my experience, the L3VPN
providers tend towards knobs like allow-as-in and as-override rather
than remove-private so the statements would not be applicable as they
don't rely on features that recognize private use ASNs, but in any case
this document was not intended to define any features or changes to
protocol behavior.  As far as I've read (which is by no means every RFC)
none of these vendor knobs that do AS_PATH manipulation are documented
through the IETF process.

As far as impact, there are are a number of private Use ASNs advertised
to the Internet at any given time with no large (Internet wide) impact,
but presumably there may be some small impact if a route with one of
these ASNs was received by an ASN w/o an inbound AS_PATH filter to block
them which was using such ASN internally to it's network and was
therefore dropped.  So the impact is limited mostly to connectivity to
those who do no correctly remove the private ASNs.

Jon

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Jul 2012 00:16:15 -0400

> are aware of it already...

it's probably worthwhile (as a co-chair in GROW) to come clean about this bit:
Jon asked both chair groups, we debated and mr scudder leaped.

As to the whole idea, I think that jon puts forth some valid arguments
for making more private-asns, though I fear the tomfoolery in code
that already exists for special case thiings (private-asn,
private-ip/ULA, accept-own-as, etc...ick)

I'd like to see a good discussion on 'why not just get public asns for
all this sort of stuff'
If there never were private-asns, if asns were as plentiful as rain,
why NOT just use them instead? What would be required to go on as we
want, without making making more private-asns?

-chris

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Jul 2012 18:05:34 +0900

the motivation is not clearly stated.  the only thing i could find
was

   The limited size of the current range of private use ASNs has led to
   the usage of a number of implementation specific features that
   manipulate the AS_PATH or remove AS_PATH based loop prevention
   described in Section 9 of [RFC4271].

and it is not clear how more private ASs will ameliorate this.

perhaps a clear statement of need, and why this is the best solution,
right up front would be helpful.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Jul 2012 07:09:54 -0400

> want, without making making more private-asns?

The answer probably is something along the lines of "ARIN charges $500 for a
registration and $100 per year for 'maintenance'".  Modulo waiving part of
this if you're already paying for address space.  (And I'm only picking on
ARIN because they're the first site I checked.)

Frankly I'd rather see the RIRs have *4-byte* AS number pricing in line with 
the cost of registering a domain ($20 US) and then kill this draft.  (Note,
also spoken as someone who was going to author a similar draft.)

This would then move the desired feature to such tom-foolery as "AS hiding"
as a feature, but such things don't require standardization.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Jul 2012 20:18:01 +0900

> The answer probably is something along the lines of "ARIN charges $500
> for a registration and $100 per year for 'maintenance'".  Modulo
> waiving part of this if you're already paying for address space.  (And
> I'm only picking on ARIN because they're the first site I checked.)
> 
> Frankly I'd rather see the RIRs have *4-byte* AS number pricing in
> line with the cost of registering a domain ($20 US) and then kill this
> draft.  (Note, also spoken as someone who was going to author a
> similar draft.)

the real cost is address space.  if you are gonna play this game fix the
real problem.

and, i sure hope you are not proposing to us this 'private' AS space as
a cheap replacement for real AS space.  the capex you save will be
overwhelmed by the opex of maintaining a new global AS space co-joined
with the traditional one.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Jul 2012 07:49:13 -0400

> the real cost is address space.  if you are gonna play this game fix the

A lot of people are using private-AS peering within a SP's address space
just to get some routing.  They don't need a public AS.  They don't need
provider independent space.

They don't want to run an IGP since the failure modalities are ugly and are
hard to mitigate.
The next best protocol that gives them filtering is RIP.

> a cheap replacement for real AS space.

No, I'm not.  It's one of the reasons I'm happy with closer to 65K ASes than 1M.

> the capex you save will be

Right now an opex pain point for some larger providers is dealing with the
absence of enough private ASes to keep their internal stuff, well, private.
It's much the same argument as the providers who had run out of RFC 1918
space and do address squatting.  I haven't heard any first-hand accounts of
AS-squatting, and I hope I never do.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Jul 2012 20:56:35 +0900

ok, so let's see if i have it correctly.

the case you are trying to support is the use of a private asn for a
customer who is bgp multihomed to a single isp, and that provider has
more than 1024 of this kind of customer.  and the asns can not be
re-used because they need as-loop prevention so can not turn as-loop
detection off?

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Jul 2012 08:21:57 -0400

On Tue, Jul 03, 2012 at 08:56:35PM +0900, Randy Bush wrote:
> customer who is bgp multihomed to a single isp,

Or small set of providers using a coordinated internal space.

> and that provider has

There's that opex thing again.  You'd have to track which customers are in
sites that need to communicate with each other and make sure not to re-use
numbers for those customer subsets. 

More numbers means less operational complexity.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Jul 2012 14:43:23 +0200

Jeff,

> numbers for those customer subsets.

Regardless of opex how technically would you (proactively) go about 
tracking who needs to communicate with whom within your Internet 
customers (even if they are directly attached) ?

R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Jul 2012 09:11:13 -0400

> customers (even if they are directly attached) ?

In a very high latency protocol called "contractual agreements".

Note also that the motivation is not specifically for Internet customers.

-- Jeff

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 3 Jul 2012 09:17:20 -0400

Robert - this appears to be a non-private use case as you are providing
service to multiple customers, and I support it and encourage you to
work a proposal through the proper venue (RiR's) to get them to lower
the bar for applying for larger blocks of public ASNs if necessary,
however I think fixing this particular problem is orthogonal to the
draft proposed.

By definition, a Private Use reservation by IANA is unreserved for a
specific customer and re-use is to be expected, in accordance with
section 4.1 of RFC 5226.  I don't expect this draft to fix/change every
situation where AS_PATH manipulation hacks are used, but it should
reduce the ones where they are used for communication within one
administrative domain that can allocate their own numbering yet the
number of sites exceeds 1022.

Jon

On Tue, Jul 03, 2012 at 10:21:41AM +0200, Robert Raszuk wrote:
> <offline>
> 
> Hi Jon,
> 
> Thx for your reply.
> 
> How about a bit different approach.
> 
> Could we define a new AS allocation option that I get a registered
> AS block of ASes rather then single AS as it is today ?
> 
> So if I get registered AS (first three octets) and fourth octet ANY
> then I would have no problem reg my case of any possible private AS
> overlap with my customers.
> 
> Just like we allocate prefixes ;)
> 
> Thx,
> R.
> 
> 
> >
> >Comments [JM] Inline...
> >

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 3 Jul 2012 09:39:48 -0400

[JM] inline...

> I will agree with anyone that the above opinion is one of strong cynicism.

[JM] This is interesting, however given these ASNs are in use today and
there is widespread mis-understanding that the 65535 ASN is a private
use ASN already based on widespread vendor and other networking
documentation, I think publishing this informational draft to
officially allocate it as such is not going to cause a rush of changes
to use it on devices this old.  However new implementors would have
clear guidance on what a private ASN if they are trying to comply with
this draft/RFC if/when it's published and therefore could avoid this
leaving this open to error in new implementations.

> boundary.  I could even forsee someone's CLI saying PRIVATE.<num> :-)

[JM]  Although 65K private ASNs meet our near term needs, BGP is being
used further and further down in the DC, with proposals that push it
even to the host/hyper-visor.  Therefore, given the large amount of
space available, I think it makes sense to not limit this so artifically
and be frustrating operators again 5-10 years from now as more and more
creative network designs are proposed.  As for any implementation hoping
to make more asdot friendly implementations and encourage it's use, I
think this sounds like a good reason not to make the range 16 bits!

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Jul 2012 09:51:54 -0400

> think this sounds like a good reason not to make the range 16 bits!

Mostly, if you're going to pick a range of addresses, just keep clean bit
alignment.  That would mean it's cleanly maskable in the code.

If you pick 2^20, you can have PRIVATE1.<as> through PRIVATE16.<as>.   While
I'm only partially serious about something like this as a UI mechanism, one
consideration is that 4-byte numbers in decimal format are big enough to be
difficult for humans to parse for convenience and having such mneumonics
might be very helpful.  (To be contrary, canonical display and machine
readable should always be as-plain formatted.)

-- Jeff

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 3 Jul 2012 10:16:29 -0400

Randy / Chris -

Sorry in advance for the long message, I tend to be verbose.  As I
stated in my message to Robert, the use cases I was hoping to solve were
a single customer that has requirements for much more than a thousand
sites (not connected via an IGP which may have unique routing
requirements or redundancy).  I'd venture that the number of private
ASNs (unattached from each other) deployed is at least an order of
magnitude, if not several orders, higher than public ASNs allocated.

This goes to Chris's message as well... there seems to  be interest to
ask for justification of use of these ASNs.  The use of BGP has expanded
so much in Enterprise networks especially for remote site connectivity,
when no justification or process was required to use BGP like they
utilized any other routing protocol internally.  For those who want to
move this to a Public ASN paradigm, I encourage you to submit the
appropriate proposal to change both IANA/RIR policies to be so lenient
that I can walk in and request 10K+ ASNs with minimal justification and
low cost.  I don't see much value in increasing the administrative
burden on the network operators or the registries for ASN processing of
these use cases, but if others do I'm at least interested in seeing the
proposal and how well it is received.  After all, 32 bit ASNs appear to
be "like rain" because of the justification required today, while we at
the same time have determined that the 32 bit IPv4 resource requiring
less justification and using larger allocation blocks was not big enough
long term for growth of networks.

Also if we go down this method of using public ASNs for building larger
internal networks, some folks may want knobs back to hide their
multitude of ASNs from the Internet w/o deploying confederations or
having to aggregate every prefix at a higher level, as they want to
maintain a short and consistent AS_PATH for other reasons.  Also, since
private Use ASNs that are already allocated will likely exist for a
really long time, and no one is proposing some sort of active
notification/deprecation strategy as part of a proposal (yet) we will
still need all the existing knobs / complexitiy in current vendor
implementations on top of the new one.  To me extending the one command
(I'm aware of) that already recognizes private ASNs to strip a second
range seems like a better approach and not overly complex.  Please note
as-override nor allow-as-in are examples of command that fit in this
criteria, but their future use may be lessoned but not eliminated by
this proposal.  

For the other use cases where SPs are providing service to customers who
likely are using private ASNs (either in the existing range or the new),
I encourage these SPs to see if a non-private ASN or range of ASNs can
be allocated to them for these use cases and would support any proposals
that reduce the justification needed to assign these if the existing RiR
policies are deemeed to stingy.

Jon

---

From: Brian Dickson <[email-masked]>
Date: Tue, 3 Jul 2012 11:01:11 -0400

On Tue, Jul 3, 2012 at 12:16 AM, Christopher Morrow <[email-masked]
> wrote:

> private-ip/ULA, accept-own-as, etc...ick)
IMHO, this draft should try to be "clean", i.e. deal only with new content
(new private ASNs).

Leave well enough alone (regarding 65535), or have it cleaned up separately
with some *-bis draft or another.

> want, without making making more private-asns?
Um, the fact that however large the space is, it is still finite?
Also, the use cases that "private" supports, generally won't or shouldn't
be visible via AFI/SAFI == 1/1.
The administrative overhead of centralized (versus local) management of
ASNs that are "ships in the night" is clearly not justified.
And, the local use cases already show need for >1024 ASNs within a single
SP environment.
(As for the concept of blocks of ASNs out of public space, instead of
re-used private space - let's avoid the rat-hole that was 10xxx vs 1010xxx
on long distance dial-around. If we have first- and second-class public
ASNs, we will rapidly consume the whole 32-bit space. Just say no.)

So, I am in favor of adoption as a WG draft.
And, I suggest the author(s) remove 65535 from this.
And, I see no reason not to "go big" on the amount of private 32-bit ASN
space.

Big means not having to update this in a year or five, and not having to
have arguments over whether to expand the space to support those who
actually need it.
IMHO, 2^24 is about as big as can reasonably be expected to reserve without
hamstringing the rest of the public space, and hopefully is enough for
single SPs for a long time.
2^20 vs 2^24 is nit-picking, and 2^16 is short-sighted. Let's just bite the
bullet and go 2^24.

Also, IMHO, use outside of the proper "private" environment should be
enforced via draconian language, hard-coded mechanisms, and the like.
Having to support "public" use of "private" space isn't a reasonable
requirement to place on future protocol elements (e.g. any kind of BGP
security mechanisms.)
The DFZ *must* *not* be polluted with private ASNs, ever. IMHO.

Brian

P.S. RIR policy/pricing mods for 32-bit ASNs, and IETF additional private
32-bit ASNs - should be treated as "OR", not "XOR", as in, there's no
reason not to pursue both. They have different use cases, and both are
justified.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Jul 2012 17:08:38 +0200

Jon,

> I don't expect this draft to fix/change every

How about if each of such internal site uses the same *single* private 
AS number and you perform loop detection/troubleshooting by use of SOO 
extended community ?

It is local to you to assign it's value (6 octets seems wide enough) and 
it has been already widely implemented.

Today it is used mainly for multihomed VPN sites, but it could be 
applied equally well to your internal sites.

Thx,
R.

---

From: heasley <[email-masked]>
Date: Tue, 3 Jul 2012 08:26:31 -0700

> numbers for those customer subsets. 

send a default route to those customers, or let them build one based on
a backbone route,  and leave loop detection alone.

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 3 Jul 2012 11:42:41 -0400

[JM] Inline..

On Tue, Jul 03, 2012 at 05:08:38PM +0200, Robert Raszuk wrote:
> How about if each of such internal site uses the same *single*
> private AS number and you perform loop detection/troubleshooting by
> use of SOO extended community ?
> 
> It is local to you to assign it's value (6 octets seems wide enough)
> and it has been already widely implemented.

[JM]  Robert - are you are saying you do not support the draft as I can
use hacks/workarounds such as allow-as-in or as-override in conjunction
with site of origin to add loop detection or am I misunderstanding your
suggestion?  What if I want to use BGP as designed for AS_PATH loop
detection and be able to do standard troubleshooting/filtering based on
AS_PATH and not worry about (mis-)configuration of soo?   Why not have a
range of private ASNs large enough to support internal networking
requirements of organizations w/o the use of more and more features?

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Jul 2012 17:54:26 +0200

Jon,

The point I am making is that you no always have full control on what 
private AS your customer chooses to use.

If you use private AS within your domain there is risk that you would 
end up using the same AS number as your customers - so all tricks like 
private AS stripping, allowas-in or as-override would still need to be 
applied.

And once you apply it once you better apply it everywhere as non uniform 
configuration which does not follow templates is the worst NOC nightmare.

That is no matter how many private ASes are in the pool.

I am bringing SOO as an example as this is single time configuration 
when you establish eBGP session to a given site to see what would be 
missing to realize your objective. The main difference is that you have 
full control over SOO value.

 > [JM]  Robert - are you are saying you do not support the draft

No - however seeing comments from others I am getting less and less keen 
on it - more towards being just neutral. Clearly just reserving the pool 
does no harm to anyone ;-)

Rgs,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Jul 2012 14:50:54 -0400

On Tue, Jul 3, 2012 at 11:54 AM, Robert Raszuk <[email-masked]> wrote:
> If you use private AS within your domain there is risk that you would end up
> using the same AS number as your customers - so all tricks like private AS
> stripping, allowas-in or as-override would still need to be applied.
>

isn't the case of 'give customers an ASN to peer with us in more than
one location' just: RFC2270
why would you pollute your RIB and your configs with private-asn when
a public is available for this? (or a reason to get a public is
available for this).

> configuration which does not follow templates is the worst NOC nightmare.

yes, less complex config, win.

> That is no matter how many private ASes are in the pool.

right, because you used 2270 and a public asn.
(sorry for hijacking)
-chris

> I am bringing SOO as an example as this is single time configuration when
> you establish eBGP session to a given site to see what would be missing to
> realize your objective. The main difference is that you have full control
> over SOO value.
>
>
> No - however seeing comments from others I am getting less and less keen on
> it - more towards being just neutral. Clearly just reserving the pool does
> no harm to anyone ;-)
>
> Rgs,
> R.
>
>
>
>> [JM] Inline..
>>

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Jul 2012 14:54:29 -0400

> low cost.  I don't see much value in increasing the administrative

I would bet that if you were a large enterprise WAN like, say: "the
Limited" (clothing store) that has +1.5 endsites, you could say to
ARIN (for instance): "Hi, I have 1.5k endsites, all connected over a
third-party WAN, we use BGP and have unique routing policies for each
site, can I have 1.5k TODAY and since I plan to expand 500 sites this
year 1k tomorrow" you would probably get that allocated, if you can
deal with 4-byte.

it's worth asking the hostmaster people I suppose.

-chris

---

From: David Farmer <[email-masked]>
Date: Tue, 03 Jul 2012 15:06:43 -0500

> year 1k tomorrow" you would probably get that allocated, if you can

So Chris, why does clothing store with 1.5k endsites want those ASNs 
publicly registered.  I tend toward why not, but they frequently seem to 
not want them publicly registered.  They clam it has something to do 
with security.  I don't buy it, but on the other had it is their network.

A lot of enterprise networks are starting to use BGP internally, but 
they seems to only want to deal with eBGP and no iBGP peerings or only 
very limited iBGP.  So they give every router or pair of site routers 
its own Private ASN.  I seen some with fairly elaborate routing policy, 
that would qualify as unique routing policy.  But many don't they just 
used Private ASN to avoid iBGP, without any unique routing policy.

So, currently Public ASN must be justified by unique routing policy, I 
believe this essentially comes from RFC 1930, this is the guidance from 
the IETF that the RIRs are using.  Actually most RIR also currently 
require multi-homing to justify an ASN as well. However, this is 
primarily attributed to scarcity of 2-byte ASNs, but could probably go 
away now that we have 4-byte ASNs.

But using an ASN so you don't have to deal with iBGP isn't justified by 
the unique routing policy criteria of RFC 1930.  If we don't think a 
unique routing policy is necessary any longer then maybe the IETF should 
give that guidance to the RIRs.

Realistically, even in your example of the large clothing store chain, 
I'll bet you there are not multiple unique routing policies involved, 
its because they want eBGP going to each of the endsites. Right or 
wrong, lots of people use private ASNs so that most if not all of their 
peerings are eBGP and not iBGP.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 3 Jul 2012 16:20:38 -0400

> a public is available for this? (or a reason to get a public is

No. For lots of reasons.

RFC 2270 is (a) informational, (b) 14 years old, and (c) talking about
using (and re-using) a _SINGLE_ _private_ ASN for multiple customers.

If you have a single customer with multiple, isolated, non-contiguous
sites, a single ASN won't necessarily work for _that_ customer.
In other words, while it might work some of the time, it won't work in
every case. There are lots of possible similar corner cases.
(E.g. "back-door" routes as either preferred, or as back-up paths, means
that more than just default is needed.)
(Similarly, any kind of tunnel/VPN/GRE/whatever, implemented by the
customer without the SP's involvement.)

One's RIB is polluted by routes, regardless of the attributes of the routes.
There may be very slight benefit to the same ASN being used, but generally
only if the rest of the attributes are identical.
For large customers with lots of sites, this won't hold true.

And, while life is easier when all the ASNs you have are unique _within_
your universe of configs,
nothing changes if some of those ASNs are re-used by someone else (out of
sight from your perspective).

> yes, less complex config, win.

Config complexity is orthogonal to standardization via automation.
It is only when you over-ride the tools that you lose the scaling war.

If you have tools that understand a dozen or so variants, and fully capture
the requirements
of each, you can plug in necessary values (e.g. from a database or other
info source),
and crank out the configs. This includes, for example, a private routing
registry, where
prefixes are keyed off of customer objects, including private ASN origin:
fields.

Having mapping references _back_ from the config to the template and
customer, is key.
(Adding your own structure to unstructured description fields has worked
well for me.)

(If you have to dumb things down, you will end up with only dumb customers.
Dumb customers are a commodity, which is ends in a price war with eroded
margins.)

Reality trumps models. 3 nanoseconds per meter might not be acceptable to
some,
but it is the law. :-)

Brian

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 3 Jul 2012 16:32:51 -0400

> year 1k tomorrow" you would probably get that allocated, if you can

[JM] Besides filling out 1500 requests, waiting for 1500 tickets to pass
justification, filling out 1500 RSA's with the correct ticket numbers,
and paying $750K upfront and ongoing maintanance to ARIN, what added
benefit would "the Limited" get for using public ASN's in this
presumably non-Internet use case?

> it's worth asking the hostmaster people I suppose.

[JM] Since they seem to be in NoVA, just did.  "Sue" at the ARIN
helpdesk clarified that each request would have to be justified
seperately with diagrams, there are no block assignments, and that she
had not seen a "unique routing" policy justification fly in the many
years she had worked there, only multi-homing requests go through.  She
recommended for the scenario I laid out that I use private use ASNs.

I think what you are proposing is a huge cultural shift / re-education
on the definition of appropriate use of public ASNs, which is certainly
possible but I'm unclear the value proposition since I'm thinking the
existing private ASN's deployed are not going away so we will have to
deal with this new way of using public ASN's for non-public applications
as well as all the knobs around AS_PATH manipulation for overlapping and
private ASN removal as well.  All my proposal does is allow individual
organizations to grow beyond the current range, it does not aim to
address the difficulities of connecting various organizations with
overlapping private use ASNs.

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jul 2012 09:12:04 +0900

> with security.  I don't buy it, but on the other had it is their

it's the public's resource

> used Private ASN to avoid iBGP, without any unique routing policy.

i see lots of silly things.  i am not inclined to change to world to
accommodate them.

> the unique routing policy criteria of RFC 1930.

or by good design practice

randy

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Jul 2012 22:18:30 -0400

On Tue, Jul 3, 2012 at 4:06 PM, David Farmer <[email-masked]> wrote:
> publicly registered.  I tend toward why not, but they frequently seem to not
> want them publicly registered.

I'd want them registered in case I happen to link my corp network with
any partners, less pain in the rear when it comes to 'who's net is
this anyway?' discussions.

TODAY they choose the path of zero resistance, 'our vendor said use
65something... oh, 65535, done.' :(

I'm not sure it's in our best interest to continue to let people paint
themselves into a corner needlessly. (if we can fairly easily avoid
it)

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Jul 2012 22:22:40 -0400

On Tue, Jul 3, 2012 at 4:06 PM, David Farmer <[email-masked]> wrote:
> Realistically, even in your example of the large clothing store chain, I'll
> bet you there are not multiple unique routing policies involved, its because
> they want eBGP going to each of the endsites. Right or wrong, lots of people
> use private ASNs so that most if not all of their peerings are eBGP and not
> iBGP.

Their WAN provider (of the week, it may change tomorow) has an ASN
(not the clothing stores) that it uses to peer with the endsites. Each
endsite uses a unique ASN so as to be easily found... tomorrow they
may choose a new network provider, it'd be a bummer if they had to
change lots more than 'add new peer to all endsites, depref old peer,
turn down  old circuits, profit!'.

-chris

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 6 Jul 2012 13:29:25 -0400

On Tue, Jul 03, 2012 at 10:18:30PM -0400, Christopher Morrow wrote:
> > publicly registered. ?I tend toward why not, but they frequently seem to not

[JM] Unless we assume that all Enterprise operators are unable to make
wise decisions, I agree they should choose to use a Public ASN to make
this connection, likely at their HQ or in a dedicated DMZ network, as
they are probably not bringing in partner connections directly at their
stores.  Often this ASN will advertise an aggregate network or very
small number of networks containing the servers that need access to the
data from this extranet partner and no data from the extranet partner
will go directly to the store terminals situations but I think it is
hard to justify the next conclusion that they should register the other
1500 ASNs needed for this networking scenario just because they should
register that one.  Of course this is only one example of a single use
case, and walking through every use case of private use ASNs does not
seem useful.

> themselves into a corner needlessly. (if we can fairly easily avoid

[JM]  Many networks are succesfully using private use ASNs, I suspect
we'll never know how many (although I'd guess far more individual
private ASN instances are deployed thank Public) since we don't connect
to them all or have to deal with them.  In my mind the only thing that
would have painted anyone into a corner would have been if such a
private use range had never existed in the first place and they were
forced to register every ASN, as likely this would have lessoned BGP
adoption overall (since there are many use cases that will not meet the
RIR justification requirements), when otherwise it was the right
protocol for their needs.

I don't see how this draft, providing a larger private use range, changes
the situation given that there are no plans or even feasible way to make
the existing private use ASN space to go away.  Not increasing the space
will only result in further hacks being used (internally) by networks
that need more than 1000 ASNs, not suddenly create a desire or a
realistic path to getting public ASNs.  Even if we theoritically could
take away away all private use space this may not get the result you
want either, but may push operators who don't want to incur this burden
to utilize other parts of the vast ASN space that they don't think will
be allocated soon.  I'm not suggesting this is wise or proper behavior,
just pointing out it has been done in other resources such as IPv4
private use space when the size was not sufficient for the requirements.

I welcome approaches/proposals to encourage a lower threshold for when
to use a public ASN and lowering the administrative and justification
burdens to obtaining them, and would be happy to work with anyone who
wants to solve this problem.  However as Brian pointed out, this draft's
progress should not be tied to the success of that effort as they are
solving different problems.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 9 Jul 2012 13:25:45 -0400

> leaving this open to error in new implementations.

There is another very strong argument to leave AS 65535 alone as a reserved
AS rather than noting it can be used as "just another private AS":
Communities.  While users of that AS would likely be addressing their
communities to someone else's AS, why preclude them from being able to
receive any addressed to their own AS?

(If it's not immediately apparent, RFC 1997 well known communities are
effectively addressed to AS 65535.)

-- Jeff

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 9 Jul 2012 16:27:00 -0400

Jeff - Thanks, this is a strong argument and I agree it stands to reason
operators should not be utilizing AS 65535 due to the reserved use of
all of that AS's standard communities (and current use of three of them)
through RFC 1997, which I do not intend to have impact on.  However,
since this draft proposes to update RFC 1930, I'm still inclined to
"fix" this documentation issue (whether or not vendors choose to strip
the last ASN is another matter and I don't believe this stripping
behavior has ever been stadarized by IETF anyway), by putting both
ranges in the RFC and ending the existing range at 65534 so that IETF
and IANA can agree on the private use range.

Do you think for consistency sake and future possible use to not include
the last ASN of the new private use range as well?

Cheers,

Jon

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 9 Jul 2012 16:39:36 -0400

On Mon, Jul 09, 2012 at 04:27:00PM -0400, Jon Mitchell wrote:
> However,

If the draft ends up solely dealing with instructions to IANA, it'd be fine
for it to be in there.  It'd simply reflect the current registration of
65535 as "reserved".

> the last ASN of the new private use range as well?

This rather depends on where the new private range lies.  In the case of the
2-byte space, the last private AS also happened to be the all-1's number.
If the new private AS range is at the end of the possible range, we'd want
that.  Note that 2^32-1 is already reserved in the registry.

-- Jeff

---

From: David Farmer <[email-masked]>
Date: Mon, 09 Jul 2012 19:21:13 -0500

I just had an idea I though I would float.  What if this draft dealt 
exclusively with defining a new larger private range in 4-byte ASN land. 
  It wouldn't have to update RFC 1930 then and it could just stand on 
its own, RFC 1930 could just be a Normative Reference defining Private 
Use ASNs.

Then do another Draft "Special Use ASNs", kind of the ASN equilivant of 
RFC 5735, summarizing all of the special use ASNs with References.  Then 
it could clarify that 65535 is not a Private ASN but a reserved ASN, 
updating RFC 1930 if that is really necessary.

Just a quick list;

0 - Reserved - draft-ietf-idr-as0, RFC 1997 and RFC 6491
23456 - AS_TRANS - RFC 4893
64496-64511 - Documentation (16-bit) - RFC 5398
64512-65534 - Private Use (16-bit) - RFC 1930
65535 - Reserved - RFC 1997
65536-65551 - Documentation (32-bit) - RFC 5398
{new private range} - Private Use (32-bit) - 
draft-mitchell-idr-as-private-reservation
4294967295  - Reserved - Does this have a special use or is it just 
reserved, as all ones?

There are already a non-trivial number of Special Use ASNs or ranges of 
ASNs, enough that having them summarized in a single place would 
probably be helpful. I know I find RFC 5735 useful from time to time.

Like I said, just an idea I thought I would float.

Thanks.