Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

From: Shane Amante <[email-masked]>
Date: Sat, 1 Dec 2012 09:38:32 -0700

On Nov 30, 2012, at 12:22 PM, John G. Scudder <[email-masked]> wrote:
> On Nov 30, 2012, at 12:34 PM, Chandra Appanna <[email-masked]> wrote:
> 
>> I figure the chairs might want to hear from some of us who are reading but silent so far..
> 
> Indeed. Thanks for speaking up and I encourage others to do the same if you have an opinion on the subject.

FWIW, I support advancing/publishing this document.

While I personally find private ASN's distasteful and I try to avoid them whenever possible (especially/even in private network contexts), the facts of the matter are:
1) The genie is already out of the bottle with the existing range of private ASN's (64512 - 65534).
2) The, <ahem>, "hacks" to deal with them are already in code and would, hopefully, just need a trivial modification to recognize the new range.
3) We operators already have methods of filtering private ASN's and those filters should also require trivial _one-time_ modifications, shortly after this is published.

And, at the end of the day, I would much rather see that the IETF adopt a standard range of "Extended, Private ASN's" than forcing operators who need a large set of Private ASN's to squat on legitimate space.  That would that create a mess.

-shane

P.S. -- Frankly, for folks who don't support this proposal I'd say this is really about economics.  If RIR's supported a model of leasing ASN's in bulk, e.g.: N x 10,000 4-Byte ASN's for $X/year, (where $X was an extremely small fraction of: N ASN's x $500/ASN) for the whole block.  Obviously such bulk allocations would require needs based justification, as defined by RIR policies.  If such a proposal were to be adopted, it would /potentially/ *also* make it more palatable to anycast operators on the Internet to use a globally unique ASN per anycast instance/node, for reasons outlined in this draft:
http://tools.ietf.org/html/draft-mcpherson-unique-origin-as-00
(Not sure if this became an RFC).  IMO, this course of action would be a much more palatable to me, because it would address the needs of both anycast operators and DataCenters/Enterprises.  
   All this really begs the question: when will we recognize that numbers are not a precious commodity, especially ASN's that only appear in the RIB, not the FIB?

---

From: Geoff Huston <[email-masked]>
Date: Sun, 2 Dec 2012 07:39:56 +1100

On 01/12/2012, at 2:50 AM, Tony Li <[email-masked]> wrote:

> 
> On Nov 30, 2012, at 7:36 AM, Christopher Morrow <[email-masked]> wrote:
> 
>> On Fri, Nov 30, 2012 at 3:58 AM, Robert Raszuk <[email-masked]> wrote:
>>> Adding new #define range to check when some filtering policy is
>>> enabled seems to me like not even in the white noise level as compared
>>> with things which BGP is carrying today and perhaps will carry
>>> tomorrow.
>> 
>> by all means, once the floodgates are open, why not drive the valdez
>> through the shoals.
> 
> 
> Come now.  This is not a reasonable comparison in so many ways.  The floodgates are not open and this hardly a large issue.
> 
> The exception is already in the code for one range.  The issue here is simply adding another range.
> 
> There is ample demand for doing this,

Oh please. Such unquantified assertions are about as much help as:

"There is more than ample demand for not doing this"

> The remaining question is whether you want it standardized or not.

no

Geoff

---

From: Tony Li <[email-masked]>
Date: Sat, 1 Dec 2012 20:34:31 -0800

> "There is more than ample demand for not doing this"

Well, sorry.  It's the best that I can do within the bounds of customer confidentiality.

Tony

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 2 Dec 2012 05:57:29 +0000

I support the proposal.

The private numbers are used by consenting adults in the privacy
of their own AS. I say, let them if they want.
It's not like there is a scarcity of numbers.

It makes sidr a bit more difficult, but it's up to the
consenting adults to make their choices.

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Dec 2012 16:14:25 +0900

> It makes sidr a bit more difficult

not really.  rfc 1918 and similar diseases are already addressed by
draft-ietf-sidr-ltamgmt

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Dec 2012 16:18:00 +0900

sorry to pick on you, tli.  but this is a really bad vendor habit that
has to stop.  and i did recant and say i conditionally support the
draft.

> It's the best that I can do within the bounds of customer
> confidentiality.

thank you senator mccarthy

if your large isp and datacenter customers want something, then they can
speak for themselves.  i try not to speak for cisco.

randy

---

From: Tony Li <[email-masked]>
Date: Sat, 1 Dec 2012 23:50:59 -0800

> thank you senator mccarthy

Aren't we above name calling?

> speak for themselves.  i try not to speak for cisco.

I wish they would too, but the fact of the matter is that not all of the operational folks attend or participate in IETF.  As you well know, many of the former participants pulled out long ago as a cost saving measure and they ask their vendors to step up in their stead.  

I'm trying to be reasonable here and share my perspective.  If you choose to disagree, that's fine, but let's stop with the bickering and agree to disagree.

Tony

p.s.  cisco is dead, long long ago. I try not to speak for/to/with/at/in/onto/near Cisco either.

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Dec 2012 18:14:03 +0900

> Aren't we above name calling?

with all due respect, and even a little extra, as i said, i did not mean
to pick on you.  i am merely reminding you and others of the iconic case
(in the us culture) of speaking for or about non-present others.

> I'm trying to be reasonable here and share my perspective.  If you
> choose to disagree, that's fine, but let's stop with the bickering and
> agree to disagree.

i agreed (with conditions) with your point.  i disagreed with your
argument.  i would not persist did i not feel strongly that the disease
of speaking for those not present is pernicious.  and it is particularly
frequent in this wg.

randy

---

From: "Mick O'Rourke" <[email-masked]>
Date: Sun, 2 Dec 2012 21:18:11 +1100

+1 support. A valid problem in large enterprise where eBGP is now widely in
use.

Perhaps some review of IR membership costs could allow for a better middle
ground. There is a case for non-support given the flat nature of IPv6
Internets\internets as to not seeing this draft move ahead. That said could
a large enterprise or sp for instance request at the present point in time
a block of 2000 ASNs?

On Thu, Nov 29, 2012 at 8:26 AM, John Scudder <[email-masked]> wrote:

> Folks,
>
> We have received a request for a working group last call on
> draft-ietf-idr-as-private-reservation-00. A URL for the draft is
> http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00
>
> Please send comments to the list by December 14. [*]
>
> Thanks,
>
> --John
>
> [*] Unless the world ends on December 12, in which case send them by
> December 12.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: David Farmer <[email-masked]>
Date: Mon, 03 Dec 2012 21:34:33 -0600

On 12/2/12 04:18 , Mick O'Rourke wrote:
...
> Perhaps some review of IR membership costs could allow for a better
> middle ground. There is a case for non-support given the
> flat nature of IPv6 Internets\internets as to not seeing this draft move
> ahead. That said could a large enterprise or sp for instance request at
> the present point in time a block of 2000 ASNs?

I'm a little confused and not sure what you are trying to saying here.

If it is that the RIR should revise their policies to allow large blocks 
of ASNs, then I agree.  However, as I said previously the RIR's policies 
are based on the technical recommendations in RFC 1930, requiring 
"unique routing policy".  If we believe this is no longer the criteria 
that should be applied, then we should update the technical 
recommendations within RFC 1930 and I'll bet that the RIR will take that 
into consideration.

As long as RFC 1930 and a "unique routing policy" stands as the 
technical recommendations, I wouldn't expect the RIR's to significantly 
deviate from that.  However, if IDR provided updated technical 
recommendations that entities using RFC 4364 VPNs should use registered 
ASNs per site to facilitate organization mergers and/or provider 
transitions, among other things.  Then I think the RIRs would probably 
update their policies, fairly quickly.

The point is the RIR's are basically following the guidance from this 
technical community, if we think they should do something different at 
the very least we should deprecate RFC 1930 to historic status and tell 
them to no longer consider that as valid guidance.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Dec 2012 16:37:50 -0500

On Dec 2, 2012, at 2:18 AM, Randy Bush <[email-masked]> wrote:

> speak for themselves.

Well, interestingly enough the draft was written by a Microsoft Corporation person as was http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-02 and a nanog presentation http://www.nanog.org/meetings/nanog55/presentations/Monday/Lapukhov.pdf
 
>  i try not to speak for cisco.
> 

… but sometimes I translate for msft :-P

W

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Danny McPherson <[email-masked]>
Date: Tue, 4 Dec 2012 22:51:58 -0500

> not really.  rfc 1918 and similar diseases are already addressed by

It's a gross hack that will never work in practice, albeit sufficient fodder for some.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 4 Dec 2012 22:53:49 -0500

> (in the us culture) of speaking for or about non-present others.

Kinda like you Randy, pretending to be the ordained operator of operators (e.g., [1])

I agree with Shane, I support this as well.

-danny

[1] inline below...

Begin forwarded message:

> From: Randy Bush <[email-masked]>
> Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
> Date: November 30, 2012 7:13:09 PM EST
> To: Tony Li <[email-masked]>
> Cc: idr wg <[email-masked]>, Robert Raszuk <[email-masked]>
> 
>> There is ample demand for doing this
> 
> in the current world, there is demand for all sorts of things.
> 
> but is there actual need?  i.e. the current widely deployed practice of
> re-using an AS for many customers and applying the 'ignore as loop' hack
> seems to be working well.  what we do not have is that hack formalized.
> i think wes and shane are working on that, but i could be wrong.
> 
>> There is ample demand for doing this, it's simply not represented by
>> the SP community.
> 
> you will note a large number of SPs speaking against this proposal
> 
> randy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 4 Dec 2012 23:41:53 -0500

On Nov 30, 2012, at 7:58 PM, Randy Bush wrote:

> 
> and i would like to do a simulation with 2^42 ASs.  let's do an rfc
> expanding the AS space to 48 bits.  :)

Hell, why don't we just bake it into the brand new AS_PATH (e.g., *_Path) attributes [1] like you're attempting to do in *Standards Track* documents in SIDR Randy.  If we're going to rewrite BGP standards track documents there but not allow trivial things like this here I recommend folks with hacks join then fun over in SIDR.

-danny

[1] http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-06

---

From: Enke Chen <[email-masked]>
Date: Tue, 04 Dec 2012 21:00:01 -0800

Support.  -- Enke

---

From: Russ White <[email-masked]>
Date: Wed, 05 Dec 2012 08:01:05 -0500

Support.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Jay Borkenhagen <[email-masked]>
Date: Wed, 5 Dec 2012 12:00:58 -0500

Hi,

My thoughts on this issue have been best expressed by Jared in his
messages here, including the one repeated below.  Likewise, I do not
support advancing this draft.

Jared also wrote in another message:

 > remove-private-as

 > Will there be remove-private-as
 > [oh-yeah-and-that-extended-space-too] ?  How will this be
 > incrementally deployed and used?

To spell this out a bit more explicitly, suppose:

1) this draft proceeds, and a new block of private ASNs is allocated. 

2) someone starts using a private ASN from the new block, not
recognizing that their routers (or their upstream provider's routers)
have 'remove-private-as' configured but are running older code that
recognizes & removes only the old block.  still they get their
connectivity to work somehow.

3) later, they (or their upstream provider) upgrades routers to a
version that adds the new private ASN block to 'remove-private-as'
treatment, and suddenly connectivity breaks or traffic patterns shift
in some unwanted way.

Yes, this sort of problem with incremental deployment happens all the
time.  But we should limit the occasions where it happens to those
where the win is big enough.  In this case I don't think there is
enough of a win.

BTW, if this draft does proceed, it will provide me with more reasons
to encourage network designers I talk to to avoid using private ASNs
altogether.  Them: "But private ASNs must be great.  Look, they just
allocated a bunch more."  Me: "All the more reason never to use them."
:)

Thanks.
						Jay B.

On 28-Nov-2012, Jared Mauch writes:
 > Greetings,
 > 
 > Jon pointed me to this draft earlier today so please be kind (for the first 5 minutes after this is delivered in your mailbox.).
 > 
 > After reading the list history back a few months or so on this topic, I must express the same reservation that Randy and Geoff have raised.
 > 
 > I do not feel this is a problem space that needs to be addressed.  Vendors easily disable loop-detection in current running code, and rfc2270 seems to clearly apply in the problem space this is attempting to address.
 > 
 > The issue of ASN collisions were raised, and I feel can be dismissed easily by one party engaging with their local RIR for a nominal "cost of running BGP" threshold.  The recurring annual cost is likely a budgetary "rounding error" and is not a barrier to entry IMHO.
 > 
 > I have other concerns should this move forward that would impact operations.  I will comment on them in private should folks desire.
 > 
 > I do not feel this draft can be supported.
 > 
 > - Jared
 > 
 > 
 > On Nov 29, 2012, at 11:40 AM, Tony Li wrote:
 > 
 > > 
 > > Support.
 > > 
 > > Editorial nit: I would find it MUCH more helpful if the constants were also expressed in hex.
 > > 
 > > Tony
 > > 
 > > 
 > > On Nov 28, 2012, at 1:26 PM, John Scudder <[email-masked]> wrote:
 > > 
 > >> Folks,
 > >> 
 > >> We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00
 > >> 
 > >> [*] Unless the world ends on December 12, in which case send them by December 12.

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 5 Dec 2012 09:12:19 -0800

Support.

  -ed

On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen <[email-masked]> wrote:

>  > Jon pointed me to this draft earlier today so please be kind (for the
> first 5 minutes after this is delivered in your mailbox.).
>  >
>  > After reading the list history back a few months or so on this topic, I
> must express the same reservation that Randy and Geoff have raised.
>  >
>  > I do not feel this is a problem space that needs to be addressed.
>  Vendors easily disable loop-detection in current running code, and rfc2270
> seems to clearly apply in the problem space this is attempting to address.
>  >
>  > The issue of ASN collisions were raised, and I feel can be dismissed
> easily by one party engaging with their local RIR for a nominal "cost of
> running BGP" threshold.  The recurring annual cost is likely a budgetary
> "rounding error" and is not a barrier to entry IMHO.
>  >
>  > I have other concerns should this move forward that would impact
> operations.  I will comment on them in private should folks desire.
>  >

---

From: Jared Mauch <[email-masked]>
Date: Wed, 5 Dec 2012 12:23:18 -0500

> allocated a bunch more."  Me: "All the more reason never to use them."

This represents my concerns as well with incremental deployment.  Most BGP ASes aren't as smart as the people on this list, and I am concerned for them as they upgrade and the vendors update the code and implement this change.  (I say this, because I feel like i'm hearing consensus on supporting this).

I think perhaps there should be some recommendations about implementing this, perhaps:

routes should not go eBGP without explicit configuration

Then again, I wish that vendors wouldn't send ANY routes without explicit policy configuration.. would solve the millions of transient routing leaks seen all day long.  (see work in grow-wg).

- Jared

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 5 Dec 2012 12:56:42 -0500

> Support.

you support the draft of jay's non-support for support of the draft?

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 5 Dec 2012 10:00:30 -0800

I support the draft.

cheers,

 -ed

---

From: Tony Tauber <[email-masked]>
Date: Wed, 5 Dec 2012 15:17:15 -0500

A long-time public hater of "private" namespaces (trans: "Hey, I can do
whatever I want!"), I oppose this draft.

As usual, my reasons are the inevitable clashes during mergers and some
other silo in the company wanting to bring their junk out the Lab and play
right with Production.  (Why Production is using private name/number spaces
is not something I can quash on my own, unfortunately.)

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Dec 2012 21:49:36 +0100

All,

I think both Tony and Jay forgot that routing and reachability is not
about originator AS .. it is about prefixes they advertise.

If peering ISP AS chooses to peer with private as or remove private as
from AS-PATH or for completeness substitute with their own it is all
ok. He takes responsibility to route data to such customer(s).

Any subsequent removal of private as in the path also results in the
same responsibility of the provider who permits private AS for
peering.

I am not sure why there is concern with it on the list.

Is this perhaps related to folks being afraid that some providers may
offer a "SIDR free peering" for a little more value add ?

I still support the draft to proceed to RFC.

Cheers,
R.

> On Wed, Dec 5, 2012 at 9:17 PM, Tony Tauber <[email-masked]> wrote:
>

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 5 Dec 2012 21:45:14 +0000

>I am not sure why there is concern with it on the list.

Not sure you understood the issue Jay was pointing to - but it is a
problem worth talking about if we are serious about advancing this draft.

Say an enterprise starts using ASN 4278190081. It already has a bunch of
ASNs from the 16-bit private AS range and relies on the correct behavior
of "remove-private-as" from the ISP. The ISP routers are not upgraded to
understand 4278190081 is a private ASN. We get into all sorts of
interesting scenarios based on the connectivity graph (changes in traffic
pattern come to mind as I know folks compare AS_PATH length taking into
account remove-private-as).

The 'operational considerations' section does talk about this - but I
would like it described in more detail.

- Pradosh

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Dec 2012 22:51:36 +0100

Pradosh,

It is ISP 101 to provide BGP peer configuration by specifying peering
AS number.

If ISP does it in the same time he needs to apply appropriate policy
reg handling or propagation of such AS.

Simple as this.

If you say that ISP is not aware that his old "remove-private-as" knob
will not remove newly defined 4 octet private AS range I think such
ISP should go back to class.

Cheers,
R.

> On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat) <[email-masked]> wrote:

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 5 Dec 2012 21:55:55 +0000

Robert,

It may not be the same ISP (think of inter-AS VPNs).

Again, as I said, I would like this to be spelled out in the document in
more detail - what problems we envision and what the guidelines are.

- Pradosh

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Dec 2012 23:02:02 +0100

Pradosh,

I think mixing Internet routing with L3VPNs with DCs etc .. in this
discussion is completely not that much helpful.

Likewise if we go the path to mandate listing concerns and various
deployment scenarios the odds that this document will proceed is quite
low.

IMO this document should just reserve the new private AS space leaving
all other aspects of it's use to the autonomy and freedom of local
operators.

Rgs,
R.

> On Wed, Dec 5, 2012 at 10:55 PM, Pradosh Mohapatra (pmohapat) <[email-masked]> wrote:
>
> Robert,
>

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 5 Dec 2012 22:11:22 +0000

>discussion is completely not that much helpful.

??

>all other aspects of it's use to the autonomy and freedom of local

Thank you for your opinion.

- Pradosh

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Dec 2012 01:24:27 -0500

> reg handling or propagation of such AS.

so glad those filters are working so well today...

> ISP should go back to class.

sure works well today.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Dec 2012 18:06:14 +0900

> so glad those filters are working so well today...

i offer a really nice dinner, probably in berlin, for someone who comes
up with a simple emoticon for dripping sarcasm (apologies for idiomatic
american).

randy

---

From: Tony Tauber <[email-masked]>
Date: Thu, 6 Dec 2012 10:19:00 -0500

Not at all what I had in mind.  What I had in mind was a situation where a
carrier is using a separate ASN for every one of thousands of some type of
site or customer (because there are so many private ASNs, don't worry!)
Then they have policies which say "when a route comes with such and such an
origin AS, do something or other".  Of course, stripping the private AS
internally will break such policy logic.

Then they acquire another carrier whose clever engineers had the same type
of thinking and now the presumption of uniqueness w/in their deployment
scope is broken.  Sometimes such things can be aided by clever use of
hack-y vendor features (unless remove-private-as is part of the BGP
standard); sometimes not.

That problem was the one I was trying to articulate.

The problem that Jay seemed to have in mind of backward compatibility and
semantics of what is considered a private AS is different (and something I
hadn't considered, so glad he mentioned it.)

Tony

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Dec 2012 13:59:22 -0500

> up with a simple emoticon for dripping sarcasm (apologies for idiomatic
Okay, I'll bite (with on-topic example usage):

Hey, Chris,

I love how you show those leaks propagate Internet-wide and cause major
problems.  ;~>

And how opposing new ranges will stop current leaks of 6[45]... from
happening, too. ;~>

(Note the dripping sarcasm emoticon. :-))

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Dec 2012 14:09:41 -0500

> (Note the dripping sarcasm emoticon. :-))

I think before I said something like:
"Just because all my freinds are failing out of school doesn't make it
acceptable for me to as well" (perhaps I said, just because we started
down the hill doesn't mean we need rocket engines attached...)

why make it more possible to have problems?
why not work out the transition to the new spec if it gets approved
and moves forward?
  (note jon will probably do this part)

still not a fan of the plan, fyi.
-chris

---

From: Shane Amante <[email-masked]>
Date: Sat, 8 Dec 2012 10:49:45 -0700

Tony,

On Dec 6, 2012, at 8:19 AM, Tony Tauber <[email-masked]> wrote:
> Not at all what I had in mind.  What I had in mind was a situation where a carrier is using a separate ASN for every one of thousands of some type of site or customer (because there are so many private ASNs, don't worry!)  Then they have policies which say "when a route comes with such and such an origin AS, do something or other".  Of course, stripping the private AS internally will break such policy logic.
> 
> Then they acquire another carrier whose clever engineers had the same type of thinking and now the presumption of uniqueness w/in their deployment scope is broken.  Sometimes such things can be aided by clever use of hack-y vendor features (unless remove-private-as is part of the BGP standard); sometimes not.
> 

In all fairness, the above is true of all private/reserved "numbers" used by two, disparate networks that are being consolidated into one, e.g.: RFC 1918 addresses.  I'd go a bit further and say that all competent engineers understand and acknowledge this risk, regardless of whether it's private ASN's or RFC 1918 addresses, as they are in the design phases.  I would also assert, based on personal experience of the last several years, that when such consolidations happen, there are conversations and planning that occurs between "clever engineers" of _both_ networks /prior/ to the day of "flipping the switch" so-to-speak where the two networks start to become one.  Furthermore, given that the "standard" private ASN's (64512-65534), and other vendor-proprietary BGP knobs, are already deployed and, most likely, in use by one or both networks, then such due diligence & planning MUST already be common practice among those clever engineers ... so, I'm unclear how NOT extending the private ASN space makes this any different?

Admittedly, all of the above is "not fun" nor as easy as using globally unique ASN's.  However, that's not an available option on the table, because operators don't have an economically feasible _choice_ to use globally unique ASN's.  (See previous discussion on changing RFC 1930 and/or RIR policies if you want to fix that).  

Just to be clear, my recommendation is still to publish this draft as a RFC.

-shane

> The problem that Jay seemed to have in mind of backward compatibility and semantics of what is considered a private AS is different (and something I hadn't considered, so glad he mentioned it.)
> 
> Tony
>

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 9 Dec 2012 04:07:23 -0500

> We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00

I did some searching to try and find if there has been any discussion
on the recommended range of values that IANA should reserve.  I didn't
find any, but admittedly, my searching skills may have simply been
poor.

I mentioned this draft to two colleagues, and our discussion was
immediately that it would be nice if the range of newly reserved
values were easier for humans to read.  If it simply extended from
4,000,000,000 until 2**32-2 this would be a little nicer.

If there has been discussion about this, could someone point me to it?

Operators care about what things look like in the CLI or the NMS.  A
bunch of private ASN all beginning with 427xxxxxxx 428xxxxxxx
429xxxxxxx is a little confusing, especially because 4278190080 would
be a private ASN but 4278190079 is not.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 9 Dec 2012 10:22:15 +0100 (CET)

> be a private ASN but 4278190079 is not.

I agree that 4,000,000,000 would be a nice number to start at. It would 
make it extremely easy to match prive ASN range with regexp as well.

If it's felt that 4B up to 2**32 is too many, then I propose that whatever 
number of private ASN is allocated starting at 4,000,000,000 instead of 
going from 2**32 and going down.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 10 Dec 2012 13:40:10 -0500

First up front, this is the text with the current range and sizing
suggested to IANA in the draft, which some people seem to have missed
based on other threads:

   [Note to IANA, NOT for publication: The IANA should update the "16-
   bit Autonomous System Numbers" registry to reference this RFC (when
   published) for the existing private use reservation.  Further, to
   maintain consistency from an operator standpoint, it is suggested
   that the end of the "32-bit Autonomous System Numbers" range be
   reserved for Private Use, and a size of 16777215 (value to replace
   TBD1 below) is suggested corresponding to the range of 4278190080
   (value to replace TBD2 below) to 4294967294 (value to replace TBD3
   below).]

Other comments inline...

Jon

> If there has been discussion about this, could someone point me to it?

The draft originally was more human/decimal boundary friendly before it
was a WG doc.  There has been some on list, some on meeting (Vancouver)
and some out of meeting discussions I did before we moved from nice
decimal boundary to nice bit or asplain friendly boundary).  Here is one
of the emails:

http://www.ietf.org/mail-archive/web/idr/current/msg06468.html

In the Vancouver meeting the draft was presented, and on range structure
a show of hands poll was done, and from my memory (meeting minutes does
not capture result unfortunately) it was overwhelmingly for bit/asplain
friendly boundary (about 10:1).  Others I talked to subsequently
preferred this approach as well (I think Tony's comment earlier about
hex friendly numbers can be grouped similarly).  I'd also point out that
the existing range is more bit friendly than human friendly so this is
not a change in approach.

Sizing has also been discussed a bit on and off list with more
preferring we aren't having this debate again in 10 years due to some
new novel use of BGP, and based on that feedback the current 24 bit text
was implemented, at this point unless a wide number of folks have a
specific change we can all agree to, I'm inclined to leave both as is.
Although I agree the resource we are using is really large, it seems
that reserving over 6% of the total space for private use is a step too
far to me.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 10 Dec 2012 16:12:56 -0500

Inline some specific comments.. in no way meaning to change your
position on the draft.

On Thu, Nov 29, 2012 at 12:50:44PM -0500, Jared Mauch wrote:
> Robert,
> 
> On Nov 29, 2012, at 12:36 PM, Robert Raszuk wrote:
> 
> > I think this is yet one more case where the "Internet BGP" is trying
> > to fight with "Private_Use of BGP".
> > 
> > There are multiple applications BGP can serve and we have single
> > protocol and single resource pool of ASes used by that protocol. Leave
> > alone types of communities, attributes etc ...
> > 
> > Internet folks will say "Do not trash our environment"
> 
> As an operator, I feel this is a fair thing for me to say. :)
> 
> This isn't about private use of bgp vs public use of bgp.  It's about the engineering decisions that went into using BGP as the tool in the first place, and the implementation secondary.  The added requirement of a larger space isn't unreasonable, but looking for a reservation (and the side-effects this will have on vendor code, deployability, usability, etc..) are not insignificant and to be outright dismissed.
> 
> Picking on Cisco - The configuration directive is listed here:
> 
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml
> 
> remove-private-as
> 
> Will there be remove-private-as [oh-yeah-and-that-extended-space-too] ?  How will this be incrementally deployed and used?

For some it will not need to be (they don't use the command today).  For
others, it will need to be updated ONLY IF they intend to allow transit
for prefixes from private ASNs in the new range.  This can easily be
enforced by having egress filters recognize the new range, which I have
yet to find a vendor that doesn't support AS_PATH filtering, although
maybe someone will correct me with their own personal implementation!
They worst case, which already happens today, is that a prefix
originating from the person taking the risk (using a Private ASN or a
new range Private ASN) does not have full Internet connectivity due to
downstream filtering.  I think something the folks for and against this
draft can all agree on is our lack of sorrow for them.

I don't expect to need multiple variants of remove-private-as, one
variant that recognizes both ranges is probably enough for the operator
community (although I can't speak for all of them).  BGP features are
being added everyday, I think this update is fairly minor as others have
pointed out.

> 
> If the goal is something like "I have 5000 racks of gear, want a top-of-rack-switch with a /64 on each of them", this is a solvable problem in current running code today.  You use rfc2270 and allow-as-in with the existing space outlined in rfc1930.

It's a bit more complex then this actually in practice, but generally
agreed that re-using private ASNs at some level with that vendor
specific knob and other vendor specific knobs makes this possible as
some of my colleagues have shared.

> 
> If the goal is to use the ASN as that identifier, eg: encoding the POP/ROW/RACK in the ASN, then I will be the first to say this is a misapplication of technology.  That should either be encoded in your addressing plan or your network documentation.  BGP can't be the place for each need to find the solution fulfilled. (note lowercase "need").

I think people have taken a leap to think that a BGP design used
internally to some MSFT DC's is the primary motivation of this draft
rather than unique number of sites (or organization/site) in a large
organization.  I don't have any forseeable plans to encode row and rack
location information into AS numbers and guarentee uniqueness for such
when this draft passes (although I'm not against the possibility or any
other use of private ASNs people may have WITHIN THEIR OWN NETWORK).

I think if you use BGP as a routing protocol many organizations are
creating an eBGP boundary per site or sub-organization for various
reasons related to implementing policy controls and creating segmented
routing domains, where using a single ASN at all sites does not provide
the necessary connectivity requirements (i.e. I need more than default)
depending on how these sites are interconnected w/o using a number of
complex routing tricks, many of which would require non-standarized
implementation specific features that vary.  I'd like to have a simpler
path forward in the long run...

Jon

> 
> 
> > Applications and services folks will say "We just find BGP useful to
> > our application, why not use it - we have nothing in common with big
> > I"
> > 
> > On that basis I see no harm in allowing some bigger AS space for personal use.
> > 
> > In fact I just looked at various RIR policies (some of them written by
> > Geoff ;) which say that given LIR can get only single AS number
> > allocation - even for experiments. Moreover RIRs get 1K AS pools from
> > IANA and there are clear rules where the subsequent pool can be
> > requested.
> 
> These policies are community driven, and could be changed.  I'm not saying they are right or wrong, but if you have collisions in numbering, you should get unique space to properly work around it vs using a hack.
> 
> > Yes Jared is right that RFC2270 or similar techniques can be used. In
> > fact I spoke with John offline today about one of such cases where
> > private as just get's stripped immediately. But those ideas are just
> > moving the issue and not really solving it - making the internal
> > network troubleshooting more complex.
> 
> I'm not convinced that the AS(4)_PATH is the right place to encode this information.  Numerous elements go into a network and site documentation.  If your premise rises or falls based on this individual element, perhaps it was poorly conceived in the first place?
> 
> - Jared
> 
> > 
> > Regards,
> > R.
> > 
> >> On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch <[email-masked]> wrote:
> >> 
> >> Greetings,
> >>

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 16:18:32 -0500

> decimal boundary to nice bit or asplain friendly boundary).  Here is one

I read the mail thread you linked, but it did not give me any
understanding why folks prefer a bit-boundary instead of a
human-readable boundary.  I will ask some more operator colleagues to
give their opinions.  I am surprised anyone would think bit-boundary
is the smartest choice if one of the alternatives looks nicer in the
CLI/NMS.

I understand what you mean if the CLI/NMS allows you to customize and
create multiple prefixes like PRIVATEn and this might be nice for some
applications.  However, VPLS has clearly figured this out with label
blocks.  The applications for making numerous PRIVATEn prefixes within
a network are likely to have conceptually similar demands, in so far
as the management of number ranges is concerned.  Even if they aren't,
though, it seems clear that router software developers have mastery of
subtraction and addition, along with the bit-wise operators.
-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Brian Dickson <[email-masked]>
Date: Mon, 10 Dec 2012 16:58:16 -0500

The as-dot/bit-boundary style typically uses a lot less space, and there
are several "nice" candidates:

64512.0 = 4227858432 (same start, shifted 16 bits left)
64850.0 = 4250009600 (the 4250000000 and up range is more human-friendly
without eating too much)
65000.0 = 4259840000 (has a bunch of zeros at the end, more
asplain-obvious?)
65280.0 = 4278190080 (currently in the draft)

Of course, it may also be reasonable to set aside a third range:
4000000000 through TBD2 as Reserved (not part of new range, nor part of
Public range, just "off limits", as a kind of DMZ).

That range can be freed up if need be later, e.g. once we have colonized
the galaxy. :-)

Brian

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 10 Dec 2012 17:50:20 -0500

David / Randy - thoughts inline...

On Fri, Nov 30, 2012 at 10:26:26PM -0600, David Farmer wrote:
> On 11/30/12 19:49 , Randy Bush wrote:
> >>the data center community has, for better or worse, decided that BGP
> >>is their protocol of choice.  Frankly, I find it mildly nauseating,
> >>but it's very clear that they are going to use BGP regardless of what
> >>you and I say.
> >
> >agreed
> >
> >but this is not what is in the ID or was not the discussion (that i
> >remember, with large caveats on my memory).  it has been about hiding
> >isp customers behind private asns, which we know how to do already.
> >
> >while nauseating, this is a more compelling argument.  and i note that
> >it does not have the merger problem the isp model has.  or, more
> >precisely, when it has the merger problem, it falls only on the fools
> >who made it.
> 
> I guess that's why we've been arguing past each other, for me its
> always been about enterprise and data centers use of BGP, not ISP
> customer access use of BGP.
> 
> I personally know of 2 or 3 large scale enterprises that are on the
> verge of having issues. They are currently just under a 1000 sites
> and would prefer to keep using unique (within their domain) ASNs for
> each site to avoiding the problems with loop detection hacks.  The
> burden for the hacks doesn't fall on the backbone SPs they fall on
> the customer edge sites.
> 
> Those hacks can be easily managed in a single backbone SP
> environment. However, when you start using multiple backbone SPs
> either for more cost effective reach or for redundancy, the topology
> can get complicated quickly.  There is a reason BGP has loop
> detection and in highly complicated environments those hacks can
> burn even the most experienced network engineers.  And in only
> moderately complicated environments, the junior engineers that many
> enterprises have are frequently in over their head with those hacks.
> 
> Large scale enterprise BGP-VPNs, Data Center BGP uses, and other
> newer applications of BGP that are not generally visible to the
> big-I topology are what is driving this, not ISP customer access
> BGP.
> 
> >update the draft to make these arguments, i will support it, and i
> >suspect other dissidents will as well.

Actually Randy, to be fair, I think a number of dissendents will not
over a philosophical objection to private use space, and I'm quite
shocked at this development since previously I asked you specifically if
there was anything in the wording that could be changed that would allow
you to support it and you declined.  Trying to do a neutral re-reading
of the draft (I think you naturally read it from an ISP providing
Internet access point of view), I see the last sentence in the
introduction which was meant to be a broad statement on why BGP has
proliferated to so many organizations (which includes provider
redundancy) could be confused to be meaning that "provider assigned asn"
is the target of this draft.  In a general sense, I'd rather expose any
issues with private use asns and then allow operators to make their own
problems in so much as they don't affect others unnecessarily which you
seem to agree with.  I'd be willing to delete that line if you think
appropriate?

> 
> In the first paragraph of the introduction there is already a
> reference to BGP/MPLS IP VPNs [RFC4364], do you want Data Centers
> explicitly added with reference to
> draft-lapukhov-bgp-routing-large-dc too?  Are there other references

Brian - As much as marketing is important, I don't think including a
reference a draft that we haven't yet found a home for that documents
Microsoft use of BGP within some DC's is a good idea for something that
applies generically to multiple sites within a single organization.  I
think many can agree they have seen DC's be in a seperate AS
(public/private/confed) than the core networks which attach them, I have
seen this as a normal configuration in multiple networks over the last
12 years personally....  I unfortunatley tried to capture this as large
content providers and may have more generically said DC operators
(either within or between DC's where they determine the connectivity),
but I don't think one sentence in the introduction is worth re-opening
the draft text during WGLC.  I'd be open to considering this past WGLC
as a minor change however, along with striking the last sentence of the
introduction if you both think this is appropriate.

I'd like to re-iterate overall that the purpose the draft is primarly to
make an IANA reservation, not to dictate or recommend to others what to
do with it, except in the operational considerations lay out the changes
to consider to continue to play nice with the broader Internet.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 10 Dec 2012 17:56:57 -0500

Jeff / Brian -

yes, there are a million combinations, I've put one in the draft that
seems to be relatively machine and human friendly (but only when looking
at it in asdot notation).  I'm not willing to consider 8 other options
with the draft in WGLC unless there appears to be a widespread concensus
in the WG to change to one specific other option.  I think overall, we
can say things like 4,000,000,000 are not easy to make human friendly in
the CLI when you remove the commas, so I'm not as convinced that these
are less opertionally error prone or human consumable.  Seems more
likely everyone re-uses that number if we decided on it (not that
uniqueness is an attribute that is useful in private ASNs) and
misconfigures it half the time to be 400M.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 10 Dec 2012 17:58:58 -0500

Pradosh / Randy / et al - although Robert has pointed out already that
in the end someone who knows that these routes need to go to the
Internet needs to peer with said Enterprise in your example, and this
ISP is ultimately responsible for allowing the routes to reach the
Internet (and can consider the operational considerations that is
already fairly clear in my opinion), I think this is a moot point.
However, thinking about your inter-as use case if combined with Internet
access gateway type functionality or other random topologies, I can
certainly create some that allow an ISP that allows BYOA (bring your own
asn?) to accept routes from an ASN that is private (old range) and
provide transit to a new range ASN behind that old range.  I actually
think this problem is not a large operational concern as it already is
an artificat of mis-configurations and mis-understandings of said vendor
implementations in the existing range.  Those using private ASNs and
leaking them to the Internet do not get a lot of tear drops when their
prefixes are dropped based on ingress filters or as-path loop detection
by other networks.

I think a large part of the debate on this draft has been due to the
implication that these would be used by organizations that allocate ASNs
to others outside their organization, such as ISPs, versus internal use
within very large organizations.  After WGLC, if the draft proceeds, I
may propose small changes to the operational considerations section as
there does seem to be sufficient angst, especially from the ISP
community on behavior changes (to use private ASNs in more networks or
applications that otherwise wouldn't have I guess) that may be induced
by operators based on there being an expanded range.  Are there others
who think that the following modification(s) would be useful (whether or
not you support the draft)?

(from the last sentence of 1st paragraph and total of second paragraph
is the new proposed text, ignore sp or grammer errors)

---
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.  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 occurs.  Specifically,
any implementation specific features should treat both ranges similarly
and there is no need to differentiate between the existing and new
ranges.

Networks that provide Internet connectvity for prefixes originated in
other ASNs should be cautious about allocating the new range or ever
guarenteeing transport of prefixes originating from private ASNs
especially if alternative approaches can suffice for their needs, for
instance as described in RFC2270.  Certain topologies, whether using the
existing or new range, can cause vendor specific implementations of
features that recognize the private ASN range to not remove all
instances of the Private ASNs from the AS_PATH, resulting in a prefix
that may not be reachable from all of the Internet due to containing a
Private ASN.  Private ASNs also introduce additional complexity
especially during network mergers and consolidations and careful
consideration should be given to their use versus a globally unique ASN
from a Regional Internet Registries (RIR).
---

Let me know your thoughts on this...

Thanks,

Jon

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Dec 2012 08:37:51 +0900

this misses my point entirely.  we know not to announce private ASs.

my point was

  o i do not accept the use example in the draft as justification
    for an allocation of more private ASs.  in fact, i object to
    it and specifically object to the draft being advanced.  we do
    this already without your requested allocation which then can
    only be viewed as an end-run around the IR system.

  o i can see tli's point about use in large datacenter deployments.
    if the draft is changed to use that (or a similar real need) as
    the motivation, i would reconsider my objection.

apologies, but i do not know how to be more clear.

randy

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Dec 2012 19:05:55 -0600

...
> introduction if you both think this is appropriate.

In the introduction I believe you do a good job motivating that the uses 
of BGP have expanded significantly since RFC 1930 and this is what 
justifies the expansion.  I'm including the relevant text from the draft;

    ... Since the time when that range was
    reserved, BGP has seen much wider deployment in service provider,
    enterprise and content provider networks.  The places in these
    networks where private use ASNs are in use include networks that are
    attached to the Internet, utilizing implementation specific features
    to remove them upon advertisement to Internet peers, and networks
    that are not attached to the Internet.  The displacement of Frame
    Relay and ATM based VPNs by BGP/MPLS IP VPNs [RFC4364] has also
    increased the deployment of BGP to a larger number of sites,
    especially in networks with requirements for multi-homing or provider
    redundancy.

But I will note that large scale data center use of BGP is not 
explicitly mentioned, maybe it should be added, at least as another 
anticipated use case of more than 1023 ASNs within a single private use 
ASN domain, with or without a reference to the aforementioned draft. 
But, this is the only draft or RFC that I can find that explicitly 
motivates the need for more that 1023 private use ASNs, so not including 
the draft weakens the argument for why we need more that 1023 ASNs, in 
fact I would suggest explicitly referencing section 7.2.2 of the draft 
where the issue is discussed.

Also, I suggest including that BGP/MPLS IP VPNs [RFC4364] for 
enterprises with more than 1023 sites can't use the fairly common 
practice of assigning a private use ASN per site, and is another use 
case for more that 1023 private use ASNs.  A similar example is a large 
private BGP cloud, not necessarily using MBGP, with fairly complicated 
internal routing policy amongst a large number of sites.

I guess what I'm trying to get at is; You should add specific examples 
of where the current 1023 private use ASNs are not enough, to help 
motivate why more are needed.  This is not to say where private use ASNs 
should or shouldn't be used, but that there exist real world cases that 
justify more than 1023 private use ASNs.  Furthermore, these reasons are 
also motivations for some network operators to squat on public ASNs, if 
there is not a larger space of private use ASNs assigned.

Tony's argument was basically the Data Center guys are going to do this 
whether we want them to or not and that it is better for there to be an 
assigned a block than have them squat on public ASNs, I think that is 
the argument Randy is asking to be included in the draft.

I think this argument also applies to BGP/MPLS IP VPNs and internal 
enterprise use of BGP; I've had a couple enterprises ask me about more 
that 1023 private use ASNs and could/should they use some of the 4-byte 
ASN space.  I've told them to hold off and wait for this draft to assign 
a larger private use block from the 4-byte ASNs, rather than squat on 
public ASNs.  But, in the long-run they are going to squat on public 
ASNs, if there isn't a larger block of private use ASNs for them to use.

Also, even if we revise RFC 1930 and/or the RIR's revise their policies, 
to easily allow large publicly registered ASN blocks; There is a 
perception that many enterprises have that a private use block is better 
and more secure than a registered block.  It makes my head hut, and we 
can tell them all the reasons they are wrong, but that is their 
perception and it is their network they will be using them in.

> to consider to continue to play nice with the broader Internet.

I agree we don't want to tell people where or where not to use private 
use ASNs in the draft.  However, it is not unreasonable to make sure we 
have a consensus on why 1023 private use ASNs are not enough, that there 
is justification to expand there numbers, and to document the reasons. 
And, from what I'm hearing this is what needs to be added to the Draft. 
  Especially, the data center argument above.

---

From: Shane Amante <[email-masked]>
Date: Mon, 10 Dec 2012 23:55:42 -0700

>    only be viewed as an end-run around the IR system.

May I ask how you are 100% confident that there are 0 deployments of IPVPN's, today, that have no need for more than 1,023 private ASN's (64,512 - 65,535)?  And, while I'm here, may I also ask why you believe it better that operators be forced to _continue_ to play games with 'as-override'[1] and/or 'loops'[2] to overwrite and ignore, (respectively), duplicative private ASN's in the AS_PATH in such large IPVPN's, breaking BGP's fundamental loop detection mechanism, due to the limited space of private ASN's, ultimately making troubleshooting for said operators more complicated?  (Oh, and increasing the complexity of the BGP codebase, associated regression test cases run by vendors & operators, etc.)?

-shane

[1] http://www.juniper.net/techpubs/en_US/junos10.2/topics/reference/configuration-statement/as-override-edit-protocols-bgp.html
[2] http://www.juniper.net/techpubs/en_US/junos10.2/topics/reference/configuration-statement/local-as-edit-protocols-bgp.html

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 11 Dec 2012 06:37:38 -0500

On Mon, Dec 10, 2012 at 8:05 PM, David Farmer <[email-masked]> wrote:
> Also, even if we revise RFC 1930 and/or the RIR's revise their policies, to
> easily allow large publicly registered ASN blocks; There is a perception

I have read that argument a few times.  I don't think it would be wise
to try to invent RIR policy for handing out potentially large blocks
of ASNs to orgs without a lot of specific debate about what uses are
"acceptable" and what aren't, which will ultimately result in RIR
policy that does one of two things:

* limits applications by making it hard to get huge ranges

* makes it easy to get huge ranges, so everyone will ask for a huge
one, and then we will face a 32-bit ASN depletion problem, and decide
to revise the policy, but there will be a bunch of early-adopters who
have these gigantic blocks; and then a huge block of private ASNs will
be created ANYWAY as a half-way measure to "level the playing field"
and avoid squatting

My view is that changing RIR policy to address this is quite stupid,
and it is unrealistic to think that the RIR membership would be stupid
enough to do it without first saying, "why isn't the private ASN space
expanded?"

There are some reasons why you may want unique public ASNs instead of
private, re-usable ASNs inside of service provider L3VPNs but only if
you can convince your customers to actually utilize them, and then
hand-hold your customers through requesting those blocks so they can
be assigned to sites.

Randy has plenty of history trying to force his view of what is
"optimal" to become the only possible option, instead of offering
choices and flexibility.  RIRs can still decide to give big ASN blocks
out if their memberships want that, whether the private ASN range is
expanded or not.  In fact, proposing to RIR membership that a private
resource is being exhausted thus it must be made easier to acquire
public resources for private uses, is not a smart way to convince RIR
members to vote in favor of that proposal.

$0.02.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Dec 2012 17:54:02 +0100

All,

I think Jon should remove any use case examples from the draft as
there is no way one could enforce that the new range will _only_ be
used in those use cases.

I think Jon in fact already said it very clearly that the point of the
draft is to get IANA registration. That' it - no more no less.

It would be up to individual operators to use such new range in L3VPNs
as Shane points out, in DCs or for that matter in ISPs.

Also it seems that it could be useful for dynamically routed home
gateways and in that respect I think the current range may be in fact
too small so I am sympathetic to broaden this space. If this is bit
boundary aligned or human aligned I think is secondary .. I have no
personal preference.

Many thx,
R.

---

From: Russ White <[email-masked]>
Date: Tue, 11 Dec 2012 13:26:03 -0500

+1

Lets steer away from the justifications in a draft, as they might well change over the next 5 years anyway. The justification seems well supported o list, so make the draft simple...

:-)

Russ

<><
[email-masked]
[email-masked]

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 11 Dec 2012 10:42:37 -0800

+1 I'm for removing them.

On Tue, Dec 11, 2012 at 10:26 AM, Russ White <[email-masked]> wrote:

>
> +1
>
> Lets steer away from the justifications in a draft, as they might well
> change over the next 5 years anyway. The justification seems well supported
> o list, so make the draft simple...
>
> :-)
>
> Russ
>
> <><
> [email-masked]
> [email-masked]
>

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 11 Dec 2012 13:59:17 -0500

Russ -

I agree with this view, however this was already my intention and I
believe how the draft reads today.  There is very little text overall
and none that purports to be a use case for the new range in the draft.
There is a brief introduction that mentions that BGP use in lot of
applications has expanded, some may have interpeted this to be a use
case but it sure doesn't try to provide any guidance on it nor in the
subsequent text.  I volunteered to remove the last sentence of the first
paragraph in case it was being misinterpeted in this fashion... but
unless people have some other *specific* wording changes besides that
(that stay away from getting into more specific use cases, for instance
about large DCs), I don't plan to make any further changes to the draft.

Jon

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Dec 2012 20:20:10 +0100

How about if we would take completely different approach ...

Based on number of use cases it seems to me like perhaps we should
just declare the top most bit in 4 octet AS space as indicator of
private vs public.

50% !

2^31 should be well sufficient for public use for a long time,
likewise for private use. Filtering/replacing also seems trivial.

Cheers,
R.

PS. I must say that I see nothing wrong with advertising private AS to
the public. It is just that no one should look at single atomic AS in
the AS_PATH. If you look at tuple of private AS + next AS what harm
does it cause to anyone including SIDR ?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 11 Dec 2012 19:40:25 +0000

> just declare the top most bit in 4 octet AS space as indicator of

Excuse me if this sounds atrociously naive, but putting my operator hat on:

- i'm human and regularly need to parse asns in as-paths

- i don't naturally count in binary

- i would really like a set of numbers which I can easily see are private
or public.  Decimal alignment would work nicely, both for me and the NOC
staff that are going to be dealing with these numbers on a daily basis.

- looking at 4278190079 and 4278190080, I simply cannot tell which might be
public and which might be private.  This will cause leakage because it will
not be obvious on sight to an operator looking at a bgp aspath whether the
range should be propagated or not #operatorfail

- unless something drastic has changed recently, I'm not aware of any plans
to assign bitwise masks to ASNs.  Consequently bitwise alignment for a
private ASN range is a purely arbitrary construction

- please change to using a decimal-aligned range.  it would make my life
and the lives of many operators a little easier.  I suggest 4000000000 or
maybe 4200000000, or something else.  Not 4278190080, because that number
means nothing to me

- otherwise, I love the idea of this draft.  Please let us have private
ASNs and lots of them.  There are plenty of them to spare in the can.

thanks,
Nick

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Dec 2012 03:11:12 -0800

> there is no way one could enforce that the new range will _only_ be

if there is no documented motivation for it, then we don't need the
draft at all.  simplifies live greatly.  great idea.  ;~>

randy

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Dec 2012 08:07:43 -0800

> draft at all.  simplifies live greatly.  great idea.  ;~>

Then we lard up every draft with marketing material.  Is that better?

Tony

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Dec 2012 08:23:28 -0800

> Then we lard up every draft with marketing material.  Is that better?

a use case != marketing material

without sayng why we want to do something, kinda hard to justify doing
it.  in this case, "we want to end run around the IR system for no
reason, just give us the cash and we'll leave."

and robert has been so vociferous about wanting requirements for other
things that it is hard to resist hoisting him on his own petard :)

randy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 17:32:39 +0100

Randy,

I am just realistic.

Sincerely,
R.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Dec 2012 11:34:18 -0500

> Then we lard up every draft with marketing material.  Is that better?

Nope, no-one is suggesting marketing material -- but I think having *some* mention of a use case / justification is needed to readers can evaluate if the idea is worth the time / risk.

Providing instructions on how to build a little wooden platform with strong spring held back by a bent piece of metal that you can attach bits of curdled dairy makes no sense unless you explain that this will help solve their mouse problem...

W

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Dec 2012 08:40:58 -0800

We all think we are realistic. A common delusion. 

randy, on a stinkin' iPoop

---

From: Chandra Appanna <[email-masked]>
Date: Wed, 12 Dec 2012 08:51:07 -0800 (PST)

I think it is reasonable to put a couple of lines
in there.. and there must be a couple we can extract
from this humongous thread and insert :) We do
not need 7 pages and it is quite likely that
over time this will get applied to other 

unforeseen situations(like we have seen in other
solutions many times).

More interesting to me is whether the range we
have picked is the right one or we can pick another
one as being discussed.

Chandra.

________________________________
 From: Randy Bush <[email-masked]>
To: Tony Li <[email-masked]> 
Cc: idr wg <[email-masked]>; Robert Raszuk <[email-masked]> 
Sent: Wednesday, December 12, 2012 8:23 AM
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

randy

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Dec 2012 11:03:21 -0600

Come on guys,

I think the proposed range is more than reasonable, 4,278,190,080 to 
4,294,967,294. Yes, the start and end of the range are not really that 
human or decimal friendly.  But, within that you have a range of 10 
million ASNs that are relatively human and decimal friendly, 
4,280,000,000 to 4,289,999,999.

And, if some how that isn't enough, you can pickup another 5 million 
ASNs with two other adjacent ranges that are only a little less human 
and decimal friendly, 4,279,000,000 to 4,279,999,999 and 
4,290,000,000,000 to 4,294,999,9999.

Something more than 16 million ASNs is way more than enough, reserving 
300 million or more ASNs, just to start the range at the 4 billion point 
is just crazy.

Get over it.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 18:11:46 +0100

Yes ... a simple reference to RFC1930/BCP6 should be sufficient.
Unless this is no longer BCP and if so let's discuss why not.

Regs,
R.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 17:53:21 +0000

On 12/12/2012 17:03, David Farmer wrote:
> 4,294,967,294.

Dave,

could you please provide me with a regexp which matches exactly 4278190080
to 4294967294?

thanks,
Nick

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 Dec 2012 13:16:00 -0500

> could you please provide me with a regexp which matches exactly 4278190080

In as-dot notation, it would be (modulo the regexp language syntax for your
CLI):

652[89]?.* | 65[34]??.* | 655[012]?.* | 6553[0-5].*

(65280.* through 65535.*)

This is every bit as easy (actually a bit easier) to do as a regexp, as the
current 16-bit reserved ASNs are:
6451[2-9] | 645[2-9]? | 64[6-9]?? | 65[0-4]?? | 655[0-2]? | 6553[0-5]

Of course, the general rule of how many separate regexp elements (separated
by |) it would take,
can be determined by the odometer rule:
o  How many carry-over rolls are there in the range? (Those are x99* to
(x+1)00*.)
o       Ignore intermediate rolls between two rolls of increasing length
o       Obey "price is right" rule - don't use a roll if it takes you
"over" the high number
o  That number, plus (up to) two, if the low number does not end in 0,
and/or high number does not end with 9.
o  So, for the ranges above in as-plain, it is about 15 or so.
o  Not really horrible, and you only have to build it once. The great thing
about constants -- they don't change.

(Not sure, but I think the upper range limit should be 2^32-1, or
4294967295.)

Brian

---

From: "Neil J. McRae" <[email-masked]>
Date: Wed, 12 Dec 2012 18:21:56 +0000

+1 on this. These seems far from something that we should be encouraging.
Both Jay and Jared articulate my concerns also.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 18:27:57 +0000

On 12/12/2012 18:16, Brian Dickson wrote:
> In as-dot

We don't use asdot on production networks and for good reasons.  That
barnyard door has been firmly bolted shut.

Nick

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Dec 2012 13:34:33 -0500

> barnyard door has been firmly bolted shut.

No kidding.  as-dot should go away and be removed from everyones code imho.

- Jared

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Dec 2012 12:35:50 -0600

On 12/12/12 12:16 , Brian Dickson wrote:
> On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
>

Nick, why is this any different than creating a regexp that matches the 
current private ASN range?  To me this is a CLI/Config semantics issue 
and not a standards or allocation issue.

Brian, thanks and more below.

> In as-dot notation, it would be (modulo the regexp language syntax for
> your CLI):
>
> This is every bit as easy (actually a bit easier) to do as a regexp, as
> the current 16-bit reserved ASNs are:
> Of course, the general rule of how many separate regexp elements
> (separated by |) it would take,
> o  Not really horrible, and you only have to build it once. The great
> thing about constants -- they don't change.
>

4294967295 is reserved just like 65535 is reserved and not actually part 
of the original private ASN range, this is one of the things this draft 
clarifies from RFC 1930.  Quickly, 65535 has special meaning, it is used 
for well known communities among other things.  It is likely that 
4294967295 will have similar special meanings and we don't want to make 
the same mistake RFC 1930 did by including 65535 in the original private 
range, see previous discussions for more details.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 18:39:37 +0000

On 12/12/2012 18:35, David Farmer wrote:
> current private ASN range?

well, throw the regexp on the table and let's take a look.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 19:43:05 +0100

Are you putting this regex in today ?

Otherwise the sooner this goes through your vendors will be able to
provide you one keyword match for the new private AS range in the
policy language of your choice.

So I can't quite see what's the point of this regex debate now ....

Cheers,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Dec 2012 13:48:18 -0500

> So I can't quite see what's the point of this regex debate now ....

to rephrase, I think Robert is asking: "Would you not just ask your
vendor to include a macro like: 'PrivateASNGroup' to match on in
routing policy language?"

seems reasonable... except that my SFO router may not get upgraded at
the same as my NYC router, nevermind fast-mover Nick over there who's
always happy to load nightly code on his elbonian routers... so do we
have to delay usage of this new shiny space until reasonably close to
all public bgp speakers upgrade? Or build a mechanism like AS4
required for as2 only realms stuck in the middle of the AS4 world?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 Dec 2012 13:52:30 -0500

Okay, in as-plain, here goes:

42781900[8-9]? | \
4278190[1-9]?? | \
427819[1-9]??? | \
4278[2-9]????? | \
4279?????? | \
428??????? | \
429[0-3]?????? | \
4294[0-8]????? | \
42949[0-5]???? | \
429496[0-6]??? | \
4294967[0-1]?? | \
42949672[0-8]? | \
429496729[0-4]

In fix-width, and wrapped so one-per-line, and using "hyphen" even for
consecutive digits, it lines up nicely (so you can easily verify
correctness).

Feel free to use the above (and if you like, credit me :-)).

Again, not too horrible - 13 terms instead of 5 for as-dot, or 7-8 for
current 16-bit.

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 20:01:20 +0100

Chris,

Do you expect that folks will use the new space as soon as it is out
of RFC editor ? Is there such huge demand for it among ISPs or
DSL/FTTH/CABLE operators ;) ?

And if so do you really assume those who will use it are so stupid
that they would leak those ? I think 4 octet AS itself is not that
widely deployed yet. Yes I saw your mail on few two octet private as
leaked.

And if those are leaked do you think transits should just blindly
remove those and replace those private ASes with their own AS ? Note
last time I checked it is not easy to remove private-as from AS_PATH
other then replacing it with your own when the UPDATE crossed few
hops.

rgs,
r.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Dec 2012 14:11:20 -0500

On Dec 12, 2012, at 2:01 PM, Robert Raszuk <[email-masked]> wrote:

> of RFC editor ?

Who knows...

> Is there such huge demand for it among ISPs or

Who know...

> that they would leak those ?

Oh Gods yes. Maybe not stupid, but accidents *will* happen.

But, if there is not a "reserved" range, folk are likely to just squat on some numbers and will be as (or more likely) to leak this… 

If this is a reserved range at least external folk can more easily see that this is a leak, and isn't as likely to end up as path poisoning a legitimate AS.

> I think 4 octet AS itself is not that
> remove those and replace those private ASes with their own AS ?

They could just drop them :-P (evil giggle, runs away…)

> Note

-- 
A. No
Q. Is it sensible to top-post?

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Dec 2012 14:25:53 -0500

+idr back

On Wed, Dec 12, 2012 at 2:25 PM, Christopher Morrow
<[email-masked]> wrote:
> On Wed, Dec 12, 2012 at 1:57 PM, Robert Raszuk <[email-masked]> wrote:
>> Chris,
>>
> the use for the ietf-draft-transition space was ... fast. I'm not sure
> how quickly they'll get used, I was simply asking of thought should be
> put into the rollout/phased-approach and what happens in a mixed-node
> network.
>
> today we see leaks, all the time, of private-as in the path and as
> origin... I clipped far back in this thread one example of many
> examples I found by just asking routeviews.
>
> I have no faith that we'll be successful not leaking this time around.
>
>>
> midstream you can't (today) replace (what would you replace it
> with?)... so no, I don't think the transits will replace, I also don't
> think they'll filter the routes (since they don't today, reliably).
>
> agreed, uniess it's the immediate asn[0] or set of immediate asns[1] I
> think you're out of luck replacing.
>
> -chris
>
> [0]: [] 65543
> [1]: [] 65543 65542 65541
>
>>
>> rgs,
>> r.
>>
>>> On Wed, Dec 12, 2012 at 7:48 PM, Christopher Morrow <[email-masked]> wrote:

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Dec 2012 14:38:37 -0500

> If this is a reserved range at least external folk can more easily see that this is a leak, and isn't as likely to end up as path poisoning a legitimate AS.

Yes, they will leak them. They will be persistent, and most BGP users aren't concerned about the impact.

Take this currently visible global route:

2800:130::/32 12956 19169 27947 65001 27820 I

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 20:41:30 +0100

>> midstream you can't (today) replace (what would you replace it with?).

You can if you would really need to replace any string in the AS_PATH
with your own AS. I spec-ed this RPL enhancement based on the real
customer demand.

Example: http://goo.gl/xVToJ

r.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Dec 2012 20:44:13 +0100

Jared,

> 2800:130::/32 12956 19169 27947 65001 27820 I

True.

So this prefix will be dropped by anyone who has private AS of 65001.

Is this a bug or a feature ? Don't you think that those who use
private AS just default out anyway ?

r.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Dec 2012 14:51:21 -0500

> private AS just default out anyway ?

It's a multi-use protocol, so that view is perfectly "valid" for someone, but likely not intended to be globally viewable.

Ideally the vendors along the path would not default advert their full table to someone without an explicit policy configured.  They would also make some of these settings more default.. remove-private should be the default behavior for this new space.

We should make folks be more conservative in their default behaviors here.. I do wish those that still default flood their full table would make that change.  I would attempt to influence them, but they've made it challenging to purchase from them due to other gaps in capability...

- Jared

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Dec 2012 15:22:01 -0500

> Ideally the vendors along the path would not default advert their full table to someone without an explicit policy configured.  They would also make some of these settings more default.. remove-pri…

is default-remove-private really the right thing to do? for some
'internet connected' routers probably, for everyone? not likely.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Dec 2012 16:03:47 -0500

> 'internet connected' routers probably, for everyone? not likely.

They can configure their policy to override the default behavior.

The problem I see is implementations that

a) default sending all best-path routes to peers.  (at least one vendor has this as a major problem).
b) leak "private" space without explicit configurations to enable said action.

- Jared

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Dec 2012 16:07:02 -0500

> They can configure their policy to override the default behavior.

sure: "no ip directed broadcast"

> a) default sending all best-path routes to peers.  (at least one vendor has this as a major problem).

ok, fine thing to ask the vendors to fix.

> b) leak "private" space without explicit configurations to enable said action.

'what is private' ?

-chris

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 21:08:34 +0000

> Okay, in as-plain, here goes:

ah, thanks - that's saved me the bother of sitting down and exercising the
grey matter of an evening.  In fact you can optimise it by taking
characters out from the front, which I've done below.  On some systems with
recursive RE libs, you can do more of this and shorter the RE string.  On
other RE libs which support specifying the atom instance count, you can
replace sequences of dots with squiggly braces, but that won't help much
with readability and it's not portable across all of the various vendor
regexp libs (and it will just make it look like modem-induced line-noise).
 I've taken out the 42 and cut-n-pasted it into a cisco router, and it now
looks like this:

> ip as-path access-list 499 permit _42(781900[8-9].|78190[1-9]..|7819[1-9]...|78[2-9].....|79......|8.......|9[0-3]......|94[0-8].....|949[0-5]....|9496[0-6]...|94967[0-1]..|949672[0-8].|9496729[0-4])_

It will be similar but not the same on other vendors.

If we aim for a decimal-aligned system, in the worst case this is reduced to:

> ip as-path access-list 499 permit _XXX......._

... for some simple numeric value of XXX.

I know which regular expression I'd prefer to deal with.

Nick

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Dec 2012 16:14:05 -0500

> I know which regular expression I'd prefer to deal with.

Sure, but *you* have the ability to use (by policy)  4,280,000,000 to 4,289,999,999 within your network and then your regexp becomes:
ip as-path access-list 499 permit _428...…._

Personally I think that human readable is much more friendly, but I can see both sides of the argument…

Actually, for yet more fun in this thread, the draft could suggest reserving on the bit boundary, and then another reservation within that that folk would actually allocate from (or just recommendations that folk start counting at 4,280,000,000).

Runs away again, giggling even louder… 
W

--
"Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."

    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Dec 2012 16:29:22 -0500

>> b) leak "private" space without explicit configurations to enable said action.

Today?  The range in rfc1930 for ASNs, but perhaps rfc1930+ the subject draft.
I believe it should perhaps also cover the IP space, but you may object to that premise as a default behavior.

- Jared

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 21:40:12 +0000

> policy language of your choice.

I think your time spent with commit access to XR has given you a overly
rosy world view on how easy it is to get feature requests implemented :-)

My experience with vendor feature requests varies from abysmally poor to
don't-even-bother-asking, which I guess is what happens when your annual
L2/L3 capex budget is less than $100m.

But as Chris mentioned, we all run vendor heterogeneous networks these
days, never mind running different code versions from the same vendor, or
even different operating systems from the same vendor.  How do we handle
consistent policy during a migration period?  I have no idea, unless you're
ok with crazy mad REs like the one posted earlier (which I'm not because I
need to debug this sort of thing).

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Dec 2012 16:11:50 -0600

> Okay, in as-plain, here goes:

Just a thought, couldn't you eliminate the rest with the following shortcut;

429???????

Yes, it would match 4294967295 which is not part of the range, but it is 
reserved for other reasons, and shouldn't be seen in the wild at all, 
Big I or little i.  And, would match ASNs bigger than 2^32 which can't 
exist.  So unless some implemented there regexp library in a vary weird 
way, you are down to 7 lines.  Yes, its cheating a little, but so what.

So with the shortcut above, you are back to more or less the same length 
as the regexp for the original private ASN block.

Throwing some some version of this discussion is as an appendix might 
not be a bad idea, including a regexp for the original private ASN block 
too.  And, just maybe that could help cut down on some of the leaking. 
I can't see how it could possibly make leaking any worse.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Dec 2012 22:22:22 +0000

On 12/12/2012 17:03, David Farmer wrote:
> human or decimal friendly. 
>

this isn't about what particular subset you could choose to use from this
allocation, and I honestly don't care about the size of the proposed
allocation as long as it's large enough to deal with really pathological
lab cases.  It's about vendors and operators and everyone else tending to
align their choice of private ASN to the boundary of the formal allocation
range, because that's what people naturally do when presented with a big
pile of numbers: they select the first in the range, or maybe the last.
It's also about making the entire range visually easy for operators to
handle so that private ASNs are immediately identifiable as such.  As a
side effect, this will make it much easier to write regexps to handle these
ASN ranges, because the tools we have for mucking around with AS paths tend
to involve RE engines.

It would be operationally more sensible to use a much lower range and
suffer fewer ASNs as a result.  This is because operational people like me
routinely need to visually inspect ASNs in as-paths, and it's a whole lot
easier to distinguish between a 5- or 6-digit numbers than 10 digit numbers.

If the draft ends up with 10 digit private ASNs, operational people will
end up with with a whole pile of "wtf were they _thinking_?" and hair
pulling, as they try to figure out whether they've just typed eight 0s or
nine, or made a mistake in position 4, 5 or 6.  We're human, not machines
and things like this make a difference.

As a side issue, we actually don't really need 2^24 private ASNs,
regardless of how complicated anyone's lab network is, but that is a less
important issue.

I'd like to formally propose a smaller range, decimal aligned, from a lower
starting point.  There are several large blocks free in various areas of
the IANA pool, any of which might be suitable for an allocation for private
use:

www.iana.org/assignments/as-numbers/

>From a subjective point of view, I take this position:

Bit-aligned 4278190080 to 4294967294:

	pros:
	- out of the way of RIR assignments

	cons:
	- impossible to recognise visually in operational context
	- the bounding regexp is ridiculous
	- the numbers are large enough that they will attract typos
	- complete mouthful and impossible to transmit down e.g. phone, across the
room, etc (yes, we shout ASNs across the room, and sometimes even talk to
customers).

Low, decimal-aligned range:

	pros:
	- immediately identifiable as private in operational context
	- out of the way of RIR assignments
	- trivial bounding regexp
	- smaller numbers mean fewer typos

	cons:
	- ?

900000 to 999999 would work fine for me.  I'd be even happier with
90000-99999.  In fact I'd be really pleased with the lower range because I
can relate to 5 digit numbers even more easily than 6 digit numbers - but
perhaps 10k private ASNs may not be enough for crazy large lab models.

> Get over it. 

What we need to get over is this idea that bit alignment is relevant to
asn allocation policy.  It simply isn't.

This is an operational draft.  Please let's request a range which works
well for operators.

Nick

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 12 Dec 2012 17:46:42 -0500

To those asking for justification -

RFC1930 is not replaced by this draft, only updated.  This draft adds
the following as justification for the 2nd range:

   The limited size of the current range of private use ASNs has led to
   the re-use of private use ASNs within a single organization,
   requiring the use 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].  These workarounds have
   increased the operational complexity of the networks since the
   implementations of these functions vary and are not defined in
   existing BGP standards.
   
   < another paragraph justifies that the total amount of space is larger,
and asns are not a scarce resource >

If the first paragraph of the draft, by mentioning how BGP use has
increased in a number of networks confuses folks into thinking they are
justifying private ASNs for a specific use case, I've already said I'm
happy to make minor edits.

Since private ASNs are (w/o collectable data a total swag) deployed on
several orders of magnitude higher numbers of devices than public ASNs
and are used in many different ways, it seems to me focusing on any
particular use case is a bit silly and short sighted give the
justification above handles all use cases for the 2nd range and just
creates fodder for those who want to debate the usefulness from an
academic standpoint often while deploying the existing range in segments
of their own networks.

Even if we were to delineate a wide number of use cases for private asns
in DCs, large Enterprise private networks, labs, etc... (which I don't
think we have very good representation in IETF to fully expound upon),
do we think that somehow this would bound folks or somehow fix any
Internet leaking of the existing or new ranges? 

Jon

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Dec 2012 20:20:13 -0600

...
>> b) leak "private" space without explicit configurations to enable said action.

This got me thinking, why are we calling them "private" anyway?

Section 10 of RFC 1930 is actually titled "Reserved AS Numbers" and only 
uses the word "private" when describe their use, it says;

    The Internet Assigned Numbers Authority (IANA) has reserved the
    following block of AS numbers for private use (not to be advertised
    on the global Internet):

                            64512 through 65535

Just like we are clarifying the end point of the original range, as 
65534 inclusive; I would like to suggest clarifying their use, by taking 
a cue from RFC 4193 and more accurately use the term "local" instead of 
"private" when describing their use.  The definition of  "private" 
doesn't seem completely accurate, "pertaining to or affecting a 
particular person or a small group of persons; individual; personal;" 
works, but "confined to or intended only for the persons immediately 
concerned; confidential;" seems problematic, and we seem wholly 
incapable of keeping them private anyway.  Where as, local, "pertaining 
to or affecting a particular part or particular parts, as of a physical 
system or organism;" or "pertaining to, characteristic of, or restricted 
to a particular place or particular places" seem much more accurate, and 
has no connotations of confidentiality or security.

Bedsides a general search and replace of "private" substituting "local" 
in the text and title, I would like to suggest a singe sentence 
paragraph be added at the beginning of Section 2;

"Local use ASNs are used by or within a single technical administration 
or among multiple technical administrations by explicit agreement only."

This simply restates the intended use of theses ASNs, using updated 
terminology, that should be less overloaded and misunderstood.  This 
seems completely compatible with the original intent of section 10 of 
RFC 1930 and the operational guidance provided in Section 3 of this draft.

Additionally, I would like to suggest the following changes to the 
abstract;

"This document describes the reservation of Autonomous System numbers 
(ASNs) that are for local use only and should not be advertised to the 
Internet, sometimes known as private use ASNs.  This document enlarges 
the total space available for local use ASNs by documenting the 
reservation of a second, larger range and updates RFC 1930 by replacing 
Section 10 in its entirety."

The intent is to have this be the sole remaining use of the term 
"private" proving an explicit link to section 10 of RFC 1930.  But, also 
clarifying how this draft updates RFC 1930, by replacing Section 10, 
clarifying the terminology and the end point of the original range.

What do you think?

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 13 Dec 2012 02:28:08 +0000

We all know what a private ASN is. "Local" is an overused word
devoid of meaning. If it ain't broke, don't fix it.

On , David Farmer <> wrote:

>     following block of AS numbers for private use (not to be
>     advertised on the global Internet):
> 
>                             64512 through 65535
> 
> incapable of keeping them private anyway.  Where as, local,
> "pertaining to or affecting a particular part or particular parts, as
> of 
> a physical
> system or organism;" or "pertaining to, characteristic of, or
> restricted to a particular place or particular places" seem much more
> accurate, and
> "Local use ASNs are used by or within a single technical
> administration or among multiple technical administrations by explicit
> agreement only."
> 
> reservation of a second, larger range and updates RFC 1930 by
> replacing Section 10 in its entirety."
> 
> "private" proving an explicit link to section 10 of RFC 1930.  But,
> also clarifying how this draft updates RFC 1930, by replacing Section
> 10, clarifying the terminology and the end point of the original
> range. 
> 
> What do you think?

-- 
Jakob Heitz.

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Dec 2012 20:45:07 -0600

>> This got me thinking, why are we calling them "private" anyway?

Ok, then you answer Chris' question.  That was my answer.

I'll only add "private" seems an equally overused word and equally 
devoid of meaning especially in this context.  And, you may not think it 
is broke, but some people on the list seem to think it is broken. So, 
maybe we should fix the brokenness, rather than propagating the 
brokenness.

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 13 Dec 2012 09:09:13 -0500

Maybe I can assist with the definition... RFC1930 was writen a long time
ago, but clearly in Section 10 it does say these are for private use.
This is reconfirmed by RFC5226 definition of Private Use is what is
being used in the draft, not a common language dictionary entry, here is
the section text:

4.1. Well-Known IANA Policy Definitions

   The following are some defined policies, some of which are in use
   today.  These cover a range of typical policies that have been used
   to date to describe the procedure for assigning new values in a
   namespace.  It is not required that documents use these terms; the
   actual requirement is that the instructions to IANA are clear and
   unambiguous.  However, use of these terms is RECOMMENDED where
   possible, since their meaning is widely understood.

      Private Use - For private or local use only, with the type and
            purpose defined by the local site.  No attempt is made to
            prevent multiple sites from using the same value in
            different (and incompatible) ways.  There is no need for
            IANA to review such assignments (since IANA does not record
            them) and assignments are not generally useful for broad
            interoperability.  It is the responsibility of the sites
            making use of the Private Use range to ensure that no
            conflicts occur (within the intended scope of use).

            Examples: Site-specific options in DHCP [DHCP-IANA], Fibre
            Channel Port Type Registry [RFC4044], Exchange Types in the
            IKEv2 header [RFC4306].

On Wed, Dec 12, 2012 at 08:45:07PM -0600, David Farmer wrote:
> devoid of meaning especially in this context.  And, you may not
> think it is broke, but some people on the list seem to think it is
> broken. So, maybe we should fix the brokenness, rather than
> propagating the brokenness.
> 
> --

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 13 Dec 2012 09:15:25 -0500

On Wed, Dec 12, 2012 at 1:35 PM, David Farmer <[email-masked]> wrote:
> current private ASN range?  To me this is a CLI/Config semantics issue and
> not a standards or allocation issue.

When I read the above argument, I think it is a clear statement that
you don't just not care how something appears in a CLI/NMS, but you
actually care more about an arbitrary range of numbers being
unnecessarily bit-aligned than you do a zero-cost move of that range
to where it can be CLI-friendly.

Operators do care what is on the CLI.  Operators also think the IETF
pays little attention to our concerns.  That's our fault for not
participating in the IETF process, but here you've got some operators
saying, please, reconsider this allocation!  Make it easier on us!
And then you've got some guys whining about a bit-alignment thing that
actually isn't.

Why isn't it bit-aligned?  Because ASN 2^32-1 is already reserved by
IANA and is not part of this new proposed private ASN range.

That means a programmer implementing a test to find if an ASN is in
this private range will be doing a range-check.  Could you make a
branch table from the first bits and then do the second arithmetic
comparison?  Sure.  Why would you want to?  Unless there are a bunch
of other branches in the table, it will be slower.

There is no argument to be made that the bit-alignment can make code
faster.  We are talking about a difference of a few instruction cycles
on any modern CPU anyway, but unless there will be a bunch of other
results besides "private" and "not private," which would mean there
are going to be a bunch of other reservations for different kinds of
ASNs in the future, then the bit-alignment simply does not offer an
advantage.  Making the branch-table would actually be slower, but not
so much slower you would care; however you probably won't implement
the branch table anyway because it is both more complicated and
slower.

I continue to think that a decimal-aligned allocation makes more
sense.  I also agree with Nick Hilliard that this range should
possibly be much lower in the ASN space to further improve legibility.

---

From: Allan Eising <[email-masked]>
Date: Thu, 13 Dec 2012 15:24:10 +0100

List, Nick, Jeff,

I just wanted shortly to express that I agree with both Jeff here and Nick
Hilliard. Their points are good enough and I feel no need to repeat them.

We use a great deal of private ASNs, so an extended range of numbers would
be welcomed no matter what, but with regards to the operational side of
things, I would much prefer if the draft would reflect the points made in
this thread.

/Allan

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 13 Dec 2012 09:41:47 -0500

This is a long email, revisiting almost everyone of the numbering
discussions in the draft, but I'll try to respond inline mostly to the
nice summary you have at bottom.

Jon

> 	- out of the way of RIR assignments

and consistent with placement of the existing range

> 	- impossible to recognise visually in operational context

Well, for a long period of time, operators will know to look carefully
at ASN's in the 4B range unless IANA or some other RFC vastly changes
the current allocation method.

> 	- the bounding regexp is ridiculous

Depending on implentation this is true, but the existing range meets
this definition as well.  I'm sympathetic to this argument however.

> room, etc (yes, we shout ASNs across the room, and sometimes even talk to

I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6.

My general feeling is that if you are configuring a small number of
sites and your operations is confined to a single room and voice
communication is your primary method still, you are likely to be happy
with just using ASN 65000 (meets all of your criteria).  If you have
more than 1000 sites you are trying to stick an ASN on, hopefully you
are taking a more programmtic view to operating and troubleshooting the
network, or at least have figured out that email / IM and other
communication methods are more reliable than voice for network
operations.  Then again, my credit card number has 16 digits and I've
managed to communicate that over the phone succesfully a number of
times.

> 	- out of the way of RIR assignments

You've suggested a range that eventually could be right in the middle of
IANA assignments (forever is a long time).

> 	- smaller numbers mean fewer typos

See previous comment on every other type of thing you can't call accross
the room today.  Even most (unpreviously heard and therefore not easily
grouped) IPv4 addresses can easily be typo'd if we suggest that most
humans are unable to keep more than 7 digits easily in short term
memory.

> perhaps 10k private ASNs may not be enough for crazy large lab models.

The not having to revisit this argument again and force vendor
implementations in the years to come was part of the justification for a
large range.  Since the purpose of the draft is a single organization
and it's for private use (not public as some seem bent on inferring),
I'd suggest you can choose more human readable sub-ranges within the
allocation for your network or lab assuming you need over 1K ASNs.

> This is an operational draft.  Please let's request a range which works

I'm sympathetic to the human recognizable (but not use small or lower
value ranges) and regex arguments to utilize a decimal boundary and the
original draft started there.  An alternate proposal that is not as
silly as 4B+ but still does not consume a significant portion of the
total space (if there was widespread concensus in the WG to change the
existing one, given that we are in LC already) could be:

4200000000 - 4294967294

Although this is even larger than the existing range, it still is a a
very small portion of the existing range, and I think no one is
seriously concerned it's the size of the new range (versus having one)
is concerning as there is no belief that will correlate to any specific
behavior.

Jon

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Dec 2012 09:08:06 -0600

Thanks for the excellent reference.

With that, I think keeping the current title and using the term "private 
use" in most of instances is appropriate.  However, I'd would like to 
suggest the phrase "local or private use" be used in the first sentence 
of the abstract and introduction sections, keeping "private use" only 
elsewhere.  And, I think it would be great if you could add the 
reference below in the first sentence of the introduction as well.

Pulling something out of my other message, I think adding "by replacing 
Section 10 in its entirety." to the end of the abstract clarifies how 
this draft intends to updates RFC 1930.

Thanks

---

From: Mohan Nanduri <[email-masked]>
Date: Thu, 13 Dec 2012 12:45:59 -0500

+1 Support.

Cheers,
-Mohan

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 13 Dec 2012 16:07:37 -0500

On Thu, Dec 13, 2012 at 09:08:06AM -0600, David Farmer wrote:
> With that, I think keeping the current title and using the term
> "private use" in most of instances is appropriate.  However, I'd
> would like to suggest the phrase "local or private use" be used in
> the first sentence of the abstract and introduction sections,
> keeping "private use" only elsewhere.  And, I think it would be
> great if you could add the reference below in the first sentence of
> the introduction as well.

I think the use of "local" has a less exact definition (local to what)
and don't feel this adds significant value to the draft.  Further, I
think the motivation paragraph saying this is for a single organization
addresses the scope that private ASNs are meant to have already (as well
as many of the concerns expressed about people using this for ISP
customers which I'm not sure could be called the same organization by
any definition as the entity allocating the ASNs).  All other parts of
the draft appear to use the term "private use" consistently.

> 
> Pulling something out of my other message, I think adding "by
> replacing Section 10 in its entirety." to the end of the abstract
> clarifies how this draft intends to updates RFC 1930.

I think this adds clarity on what parts of RFC 1930 this impacts and am
willing to make this change to the abstract.  I don't think this
represents an actual content change to the draft however... 

Jon

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Dec 2012 16:16:53 -0500

Given that 1930 has defined Private Use, maybe instances of either of the
two lower-case terms ("private use" or "local") could be replaced with
mixed-case "Private Use"?

It is not as aesthetically pleasing, but it removes ambiguity, IMHO, as
most folks are (I hope) familiar enough with Defined Terms having Special
Meaning. :-)

Just my $0.02.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Dec 2012 16:18:26 -0500

> Just a thought, couldn't you eliminate the rest with the following
Doh! (<facepalm>).

Good point, good catch, and yes, you are right.

It also makes the one-liner regexp that has the form "42(something)" a lot
simpler (and easier to debug).

Brian

> reserved for other reasons, and shouldn't be seen in the wild at all, Big I
> or little i.  And, would match ASNs bigger than 2^32 which can't exist.  So
> unless some implemented there regexp library in a vary weird way, you are
> down to 7 lines.  Yes, its cheating a little, but so what.
>
>
>  429[0-3]?????? | \
>> 4294[0-8]????? | \
>> 42949[0-5]???? | \
>> 429496[0-6]??? | \
>> 4294967[0-1]?? | \
>> 42949672[0-8]? | \
>> 429496729[0-4]
>>
> Throwing some some version of this discussion is as an appendix might not
> be a bad idea, including a regexp for the original private ASN block too.
>  And, just maybe that could help cut down on some of the leaking. I can't
> see how it could possibly make leaking any worse.
>
>
> --
> ==============================**==================
> ==============================**==================
>

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 13 Dec 2012 18:00:47 -0500

Seems a reasonable change...

Jon

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Dec 2012 17:10:35 -0600

On 12/13/12 08:41 , Jon Mitchell wrote:
...
> existing one, given that we are in LC already) could be:

I'm sympathetic to the argument too, even though it may not sound like 
it. :)  But, I can't justify something in the 300M range or even the 
100M range in my head.  Hey, 10M is a stretch, but given that I can 
easily come up with scenarios for a few tens of thousands, cranking that 
up 2 or 3 orders of magnitude means we should have to revisit it for 20 
or 30 years.  There would be one exception, if we were to require 
pseudo-random allocation to help facilitate mergers, similar to IPv6 ULA 
in RFC 4193.  Then I could justify a few 100 million in my head, so you 
get a better spreading function.  But nine random digits preceded by a 4 
isn't going to be very human friendly either.  :(

If we did 4B up most everybody is going to just use a few 10 of thousand 
just above the 4B mark.  And I'm not sure 4.2B mark would be any 
different.  Just like most people use 65000-65010 and 65500-65510 and 
some other combinations in the 1023 we have now.

My recommendation is to specify 4280000000-4289999999 for private use, 
and then suggest to the IESG that they have IANA mark 
4278190080-4279999999 and 4290000000-4294967294 as reserved as opposed 
to unallocated.  That gives private use a block of 10M and sets aside 
some 6M for other future special uses.  Who knows what really cool use 
for million or two ASNs some smart kid will come up with in a few year. :)

And if we wanted to provide another smaller but much more human friendly 
range there is another reserved range at 65552 to 131071, maybe take 
100000-129999 out of that range too.  We don't want to go into 130K, to 
help prevent anyone from accidentally going about 131071 and the ranges 
that the RIRs are using.  Then you would have the original 1023, a 
moderate but mostly human friendly block of 30000, and block of 10000000 
that is probably best for programmatic uses.

Just throwing out some ideas.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 14 Dec 2012 16:25:04 +0000

> I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6.

I don't think this is a viable argument to justify a 10-digit range -
instead it's a straw man.  There are many potential ranges which will not
interfere with the RIR ranges and the lower ranges have an explicit
tangible benefit to me and others on this mailing list.

Turning it around, why didn't IANA start AS32 allocations at 2^32 and work
their way down from there?  I'd argue that it's because the larger numbers
are a pain to deal with and if they had done so, people would have jumped
up and down and shouted at them for doing something unnecessarily pathological.

On this basis I genuinely don't see why a private range should be
considered any differently.  Why should private ASN users be committed to
use ridiculously large numbers forever more? (and what did they do to
deserve this??? :-)

> with just using ASN 65000 (meets all of your criteria).

There may also be reasons for using ASN32s instead of ASN16s, or perhaps
including ASN16s.  The two have different operational characteristics.

Nick

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Dec 2012 12:40:12 -0500

Nick -

I don't think there seems to be much concensus around any of the
discussions to change the range in the draft but there are a number of
people supporting in it's current state w/o these reservations, there
are literally billions of options we could choose from, especially when
we consider David is now suggesting two ranges (the only other person on
the list who has commented).

The only obvious solution to using a very low number range that doesn't
put the private ASN range right in the middle of public ASN's some
number of years from now is to lower significantly the size of the
allocation (which we have already debated and said we wanted to not
re-visit this issue again).  I appreciate that you say you may have a
motivation that is different than a large number of sites for using the
new range, but this is not the motivation of the current draft.

This also leaves open the idea (not which I'm suggesting or planning on
writing drafts about) to re-structure what happens with the vasty
majority of the space in between for some future undefined purpose.

As for private ASNs being secluded to the end of the range... this has
historical precedence and seems to be much more identifiable as
something different than other options (even if you typo it, it's
unlikely to conflict with anyone!).  Why should private ASN's being
favored over current ARIN Public assignments?  Should they gripe they
have a 6 digit number while others are proposing the new range only be 5
digits?

As for 10 digits.. is it really that many (you can add some structure
internally.. i.e. some zeros in the middle if you only need a subset of
the total available number)?

Jon

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 14 Dec 2012 21:19:10 +0000

FWIW, I support a human readable range.
There is absolutely no advantage to any binary
boundary from the software point of view.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jon Mitchell
> Sent: Friday, December 14, 2012 9:40 AM
> To: Nick Hilliard
> Cc: IETF IDR Working Group

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Dec 2012 17:13:24 -0600

> the list who has commented).

To be clear, I support the range currently in the draft, but I'm willing 
to consider the alternatives I outlined.  Especially, if there is a 
consensus that we should have something more human and decimal/regexp 
friendly.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Dec 2012 20:40:33 -0500

On Dec 14, 2012, at 6:13 PM, David Farmer <[email-masked]> wrote:

> To be clear, I support the range currently in the draft, but I'm willing to consider the alternatives I outlined.  Especially, if there is a consensus that we should have something more human and decimal/regexp friendly.

Sounds suspiciously like a "please weigh in" / consensus call…

So, I'd like something more human / decimal/regexp friendly like 4200000000… 

(and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000… :-P )

W

--
"When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
-- Terry Pratchett

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Dec 2012 21:30:19 -0500

I agree Warren and was writing an email with the same suggestion.

Does anyone object to moving the range in the draft to 4200000000 -
4294967294 from the current?  I think the decimal versus bit boundary is
the one trend I see in the messages that is worth revisiting.

Jon

On Fri, Dec 14, 2012 at 08:40:33PM -0500, Warren Kumari wrote:

> 
> So, I'd like something more human / decimal/regexp friendly like 4200000000? 
>

---

From: Michael H Lambert <[email-masked]>
Date: Fri, 14 Dec 2012 22:02:11 -0500

> To be clear, I support the range currently in the draft, but I'm willing to consider the alternatives I outlined.  Especially, if there is a consensus that we should have something more human and d…

Well, if a new ashex type were to be introduced, 0xff000000 to 0xfffffffe would be rather clean for the proposed private range.

Michael

-----
Michael H Lambert, GigaPoP Coordinator         Phone: +1 412 268-4960
Pittsburgh Supercomputing Center/3ROX          FAX:   +1 412 268-5832
300 S Craig St, Pittsburgh, PA  15213 USA      [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 15 Dec 2012 22:44:25 +0000

> (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000… :-P )

or anything in the range between 420000 -> 429999.  This falls bang in the
middle of the likely range that will be assigned to ARIN.  Let me hold my
nose for a moment and use asdot format:  as420000 == 6.26784, and I can see
this asn being assigned in the foreseeable future in the ARIN service region.

900000-999999 seems to be well outside the range of any of the current RIRs
(using current allocation techniques, there could be 6 more RIRs before
there would be any interference).

Nick

---

From: Martin Millnert <[email-masked]>
Date: Sun, 16 Dec 2012 00:00:33 +0100

On Fri, 2012-12-14 at 22:02 -0500, Michael H Lambert wrote:
> Well, if a new ashex type were to be introduced, 0xff000000 to
> 0xfffffffe would be rather clean for the proposed private range.

It's my understanding this horse has left the barn as well, so this is
not an option.

FWIW, I am OK with the large size of a new range of 2^24 private ASNs.
I'd also be OK with a smaller range which is more easily typed in or
otherwise humanly processed.

Chances are, if you need a private space of 2^24 scale, you can rather
easily just pick your own bits from the 2^32 space...

W.r.t predicting future scale of ASN ranges, the real "concern" is IMO
whether 2^32 is sufficient, or if we'll end up needing 128-bit ASNs
eventually...  but as long as we avoid trying to put more information in
an ASN than it is for, we should be fine.

 - at most, a scale of one private ASN per physical VM server, "ought to
be enough" for internet connected networks, w.r.t any scaling I can
imagine. 16M physical VMs? you can probably afford to design a better
solution to your overlay networking :>
  -  larger simulations or experiments need not be connected to the
internet anyway, or could easily afford some translating gateways to use
the full 32 bit space privately on the simulation side
 - burning through "public" ASN space by allocating large ranges of
public ASNs to each network by default (by RIR policy, or any
hierarchical story...) is wasteful and designs for rare exceptions
rather than the norm, which is simply wrong.  much more wise to have a
private range in this case.
 - operators are going to use the numbers, so readability is a really
wise thing.

all in all, I'm ok with the proposal, and with 2^24 even though I'm hard
pressed to see a use case for more than O(100000) private ASNs in
practice.
but the numbers really should be readable, so 420* is ok, as well. 

the numbers in the draft are a bad choice in this regard and should be
changed.

/M

---

From: Martin Millnert <[email-masked]>
Date: Sun, 16 Dec 2012 00:35:42 +0100

> there would be any interference).

This is a very valid point; operational simplicity let's youtube stay
reachable at night.

A more clear motivation of why 100000 private ASNs would be insufficient
would be interesting to read.

/M

---

From: Jeff Wheeler <[email-masked]>
Date: Sat, 15 Dec 2012 19:26:16 -0500

> would be interesting to read.

I would also find that interesting, but I do not need to know that
information to be convinced there is wisdom in allocating a large
range.

I thought 2^128 for IPv6 was stupid.  It was an expensive choice,
given the challenges which still exist in dealing with 128 bit
arithmetic in many environments, FIB consumption, legibility of
addresses, and so on.  We do have 2^128, though, and uses are being
invented for the bits.  ARIN policy allows you to basically get huge
IPv6 allocations based on nibble-boundaries for your ISP.  Some of the
largest ISPs can justify IPv6 allocations bigger than /20 (!) today.

---

From: Richard Hartmann <[email-masked]>
Date: Sun, 16 Dec 2012 02:15:00 +0100

Dear all,

I support this draft.

I am unsure of where to attach my first reply in this discussion so I
picked a more or less random one. There are several points to be made about
the preceding discussion so I resorted to replying en bloc, no inline to
specific messages.
FYI, I am firmly in the operational sector and, obviously, my position
reflects that.

* This RFC builds upon RFC 1930, so it adds rationale for private AS, it
does not need to prove it in the first place, merely to extend the range. I
agree that more specific examples to support this draft would be a good
thing. Both in this current discussion and for the benefit of anyone
reading it in the future.

* Like it or not, private AS numbers are here to stay. There's apparently a
need for more than a thousand AS numbers and any new range should be chosen
so that there are no foreseeable limits.
** This new range should also allow for sub-allocation within one or more
private entities
** Adding a second range can ease operational pains if the first one is
fragmented for historical or other reasons. Obviously, this will not help
in all cases, but it's nice to have backup

* Hierarchy is a proven way to contain local complexity, thus reducing
global complexity
** With 2^32 AS numbers, it's very likely that operators will not limit
themselves to the existing range. It's better to contain this in a
well-known range. Otherwise, rogue ASes _will_ happen, over time.
** The global cost of assigning blocks of 10,000 or more AS numbers to end
users in ways of new policy, synchronization across RIRs, actual
implementation etc can easily be avoided with no or next to no cost

* The range needs to be human readable.
** Humans should be able to detect this range at a glance
** Humans will need to implement any filters, especially when vendors have
not yet implemented this new range in their code.
** While RE do exist to handle more complex numbers, decimal boundaries
make this problem trivial to handle. You don't even need RE, globs will
suffice.

* Updating of built-in vendor filters will take some time, but claiming
that `remove private-as` is ambiguous is setting up a straw-man. Simply
extending the syntax would work wonderfully. `remove private-as rfcXXX` may
be hamfisted, but you get the general idea.

* If two entities merge/tunnel/interconnect otherwise, it's their
obligation to plan ahead. I am willing to bet that AS numbers are of lesser
concern in most cases than RFC1918 addresses. And even if this argument was
valid, it's worse currently than it will be once this draft is published as
RFC.

Personally, I would tend towards 9,000,000 - 9,999,999 as that will allow
ten segments of 100k AS numbers each, but the limits are more or less
arbitrary. It's important to me that they are on decimal boundaries, give
enough space for future use, and short enough to see at a glance, in this
order.

Richard

---

From: Tony Li <[email-masked]>
Date: Sat, 15 Dec 2012 18:25:32 -0800

On Dec 15, 2012, at 4:26 PM, Jeff Wheeler <[email-masked]> wrote:

> addresses, and so on.  

As an aside, FIB sizing only varies loosely with the maximum number of bits in the address because the FIB can be constructed to hold only prefixes.  Thus, what's more important is the average and distribution of prefix lengths.

Thus, (for a core router) the choice of /128 is largely irrelevant when remote prefixes are all /64 and shorter.  For a datacenter switch that has to store possibly many /128's, this is more of an issue, but is offset because there is no ARP cache to deal with.

Tony

---

From: Jon Mitchell <[email-masked]>
Date: Sat, 15 Dec 2012 22:15:58 -0500

Funny, so many peerings turned up every day and rarely does anyone
mis-configure AS 10001 for AS 101, or if in the odd case it occurs, it
is easily corrected.  I think we are getting a bit silly if we are
suggesting a commmon typo will be 4.2B to 420K...  The argument for
being at the end of the range is that unless something dramatically
changes in regards to AS structure, a 10 digit number is definitely
different looking from anything likely to be assigned.

Jon

On Sat, Dec 15, 2012 at 10:44:25PM +0000, Nick Hilliard wrote:
> > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000? :-P )
>

---

From: Jon Mitchell <[email-masked]>
Date: Sat, 15 Dec 2012 22:24:44 -0500

On Sun, Dec 16, 2012 at 12:35:42AM +0100, Martin Millnert wrote:
> > > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000??? :-P )
> > 

We just were worrying about someone dropping 3 digits from the number
and having a conflict, and now we drop or typo one and we are in the
middle of space currently in use or soon to be assigned... hmmm, failing
to see the validity of some of the arguments being made here.  Also -
the one impacted due to a mis-configuration of the number of their
private ASN is only themselves... 

> would be interesting to read.

The motivation of the draft is over 1K ASN's, various folks have
suggested their needs ranged in the 10K numbers today.  The motivation
for going beyond this is only not having to do this again (this has been
repeated in the threads).  The criteria for reasonable in my mind should
be not consuming a large portion of the addressable space for private
ASNs.  I think the current draft and new proposal Warrend made still
meet these criteria.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Sat, 15 Dec 2012 23:01:10 -0500

> enough space for future use, and short enough to see at a glance, in this

Isn't it just as easy to spot a 10 digit number starting with 42 easier
than a 7 digit number starting with 9, when 5 digit numbers starting
with 9 could happen in this lifetime, while 7 8 or 9 digit numbers are
unlikely to happen w/o some radical change in how ASNs are used or
allocated?  It sounds like both you and Nick put some value on the "make
it short argument", but the proposal on the table meets your other
critiera, I assume you could support it?

Btw, what is the value of segments you are referring to, aren't you feel
free to make these yourself out of 1M anywhere in the vast amount of
space available in any of the proposals on the table?

Jon

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 16 Dec 2012 01:18:54 -0500

On Sat, Dec 15, 2012 at 9:25 PM, Tony Li <[email-masked]> wrote:
> As an aside, FIB sizing only varies loosely with the maximum number of
bits in the address because the FIB can be constructed to hold only
prefixes.  Thus, what's more important is the average and distribution of
prefix lengths.

Certainly true, but you reduce power/heat/die area at the expense of
complexity.  I would say that vendors have been doing this long enough to
have pretty much mastered it, but there are products on the market right
now that have sub-optimal FIB scale and will deliver greater FIB scale
through software upgrades, once the software people for these boxes have
time to actually implement the needed improvements.

It is also the reason why people worry about whether or not their box of
choice will work right if they decide to configure /120s or whatever.  My
results have been good, but a few people claim that specific routers do not
work well in such circumstances.  They are probably not wrong.

> Thus, (for a core router) the choice of /128 is largely irrelevant when
remote prefixes are all /64 and shorter.  For a datacenter switch that has
to store possibly many /128's, this is more of an issue, but is offset
because *there is no ARP cache to deal with*.

It would be nice if that were true.  Unfortunately you are not correct.

There is no router that will forward based on an L2 address encoded into a
global IPv6 L3 address, even as an optional configuration knob on the
subnet, egress interface, or adjacency table entry.  I wish such router
would hurry up and exist because it is a smart idea that has just not been
implemented in products that are shipping.

Most routers even need to install link-local address L3 to L2 mappings into
the data-plane even though this should usually be unnecessary.  If you
think this means that the number of L3 to L2 mappings in the FIB is
effectively doubled for subnets where the attached machines all have 1
global IPv6 address and 1 link-local address, you are right.  It means a
router that claims to have room for 2000 ND entries can only support 1000
machines in practice.

If you think there is no "ARP cache" and thus less problems to consider
with IPv6, you should learn about why Cisco has implemented a knob to limit
the number of ND entries that can be used on a per-interface basis.  ND
cache size, churn, exhaustion attacks are a serious concern that operators
will have to deal with once IPv6 adoption grows to the point that
IPv6-based DDoS becomes common.  Most vendors are totally ignoring this
problem and it worries many of us.  It is especially concerning on
platforms like Cisco SUP720 where an attack of this nature will break not
only IPv6 but also IPv4.

My point is, raising the size of the AS number to 64 bits, or some other
ridiculous size, really would not have had data-plane cost the way IPv6
address sizes do.  The only place AS numbers are used in the data-plane is
netflow, and abstractions can be used in place of real AS numbers there.

I am not advocating any scheme that would again raise the AS number space
size.  I'm just pointing out that it would not increase the cost of FIBs.

If anyone thought that hierarchical AS number allocation was a smart idea
and private AS numbers should be eliminated by simply making enough global
AS to satisfy every org with as many as they want (Randy Bush's position),
then hopefully these people spoke up at the time 4-octet AS numbers were
standardized.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Dec 2012 19:14:29 +0000

> the list who has commented).

http://www.foobar.org/~nick/router-bgp-x.pdf

This is a graph of the number of google results returned for the
quote-enclosed query "router bgp x", for values of x ranging from 64512 to
65535.

Couple of things of note, apart from the fact that it isn't data, and that
it is more likely to reflect documentation rather than what people have
configured on routers:

1. "router bgp 65535" is quite common although it is officially a reserved asn.

2. there are large spikes at the beginning of the range, around 65500, and
right near the end of the private ASN range.

3. there are smaller spikes at every asn which is evenly divisible by 100,
and also at 65412 (i.e. 64512 with second two digits transposed - there are
a lot of dyslexics in the industry), 65432, 64555, 65111.

While it's not data, it does lend some credence to a hunch I had that
people naturally prefer round numbers and numbers at the beginning / the
end of a pre-specified range, and that they largely ignore the numbers in
the middle, except for the occasional cutesy number here or there.

Speculating wildly, I suspect the underlying reason for this is that people
find the numbers they've chosen to be easier to remember when working with
them.  After all, we're human.

Full config at:

http://www.foobar.org/~nick/router-bgp-x.dat
http://www.foobar.org/~nick/router-bgp-x.gnuplot

Nick

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 17 Dec 2012 11:29:03 -0500

Inline...

> 1. "router bgp 65535" is quite common although it is officially a reserved asn.

Part of this (I believe) is due to the difference between RFC 1930 and
IANA reservation of original range, which is clarified by this draft.
Others are people not reading either, which is always likely...

> them.  After all, we're human.

Nick - I assume you are willing to accept a modification to the proposal
that makes it 4200000000 - (end) even with your stated preference for a
smaller number of digits ?  This provides lot's of round numbers that
can be subdivided as folks see fit inside their own organizations.  I'd
point out that operators who plan on using only a small segment of the
new space are free to embed silliness or logic (depending on your point
of view) into the most significant x's like we have seen with IPv6, CLNS
addresses, and other large numbers if they are overly concerned about
typos or make it less likely to visually mis-identify a long string of
zeros.  I don't think we should carve out of the middle of the ASN space
for private use if we can avoid it nor think too small since we are
making a change and would prefer to progress this proposal rather than
debate the billions of options as I've stated before.

I'd prefer to minimize changes to the original doc at this point to only
those were there is strong concensus, that seems to be developing for a
change of the start of range to a decimal boundary (although I'd love to
hear from a few others on their preference between the two proposals on
the table).

Jon

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 17 Dec 2012 16:24:45 -0500

The WGLC period has ended. Thanks to all for your thoughtful comments. While well-considered positions were advanced both opposing, and supporting, advancement of the document, there's a clear consensus in favor of advancing it. So, we will request advancement. 

There's an ongoing subthread as to what exact range to request. It seems to be proceeding usefully, so let's extend that part of the discussion until the solstice (December 21). Please try to confine your comments to the subject of what range to request. 

Thanks,

--John

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Dec 2012 07:58:13 -0600

On 12/17/12 15:24 , John G. Scudder wrote:
> The WGLC period has ended. Thanks to all for your thoughtful comments.
> While well-considered positions were advanced both opposing, and
> supporting, advancement of the document, there's a clear consensus in
> favor of advancing it. So, we will request advancement.

Good to hear.

> There's an ongoing subthread as to what exact range to request. It seems
> to be proceeding usefully, so let's extend that part of the discussion
> until the solstice (December 21). Please try to confine your comments to
> the subject of what range to request.

On the issue of the exact range;

I have trouble supporting the idea of starting the range at 4B or 4.2B, 
I see no justification for reserving nearly 300M or even 100M ASNs for 
private use.

The original discussion was that the 1023 we have now isn't enough, I 
agree, as do most of the rest of you it seems.  There were numbers in 
the 10k to 50K range talked about as reasonable numbers that people saw 
immediate use cases for.  It was then discussed to round that up a 
couple orders of magnitude so we wouldn't have to revisit this again in 
our life-times.  That seemed like a good idea.  So, 1M was talked about 
and since there are now 4B ASNs that didn't sound that unreasonable, its 
only 0.02% of the 32bit ASNs.  And the original 1023 is 1.5% of the 
16bit ASNs by comparison.

In discussions and through a poll at the working group meeting, the top 
24bits of the 32bit range was selected, that's now 16M ASNs, another 
order of magnitude plus some.  That choice was arbitrary, but 24bits is 
at least explainable as a nice bit boundary, and its still is only 0.4% 
of the 32bit ASNs, this is what the draft has in it currently.

Now the issue of a human/decimal/regexp friendly range has come up as 
being very desirable, I think this is a valid issue.  However, I see no 
justification to add yet another order of magnitude or more of ASNs to 
achieve this goal, taking it to the 100M or 300M range of ASNs and using 
2% or 7% of the 32bit ASNs.

We can start the range at a fairly reasonable point from a 
human/decimal/regexp friendliness point of view and actually reduce the 
size of the range just a little in the process, by selecting 4.28B as 
the beginning of the private ASN range.  Leaving just under 15M private 
ASNs for use.  This seems like way more than enough and several orders 
of magnitude more than any use cases I've heard of.  And, there would be 
no danger of any entity running out, probably any 100 entities for that 
matter.

I just had another thought for making them even more 
human/decimal/regexp friendly.  What if as-plain was changed to use 
32bit ones' complement representation.  Then the range in the draft 
would be 4278190080 to 4294967294 in 32bit decimal or -1677215 to -1 in 
32bit ones' complement, that's probably not going to happen, but they 
sure would be human/regexp friendly. :)  Also, it doesn't look like this 
was explored, at least not in the text of RFC 5396.  Hey we could even 
call it as-neg-plain. :)  Enough math geek silliness.

So, if someone can provide a reasonable justification for 100M private 
use ASNs, or even 10M for that matter, I'm all ears. Otherwise my 
suggestion is to start the range at 4.28B

Thanks

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Dec 2012 15:41:08 +0100

Hello David,

> So, if someone can provide a reasonable justification for 100M private use
> ASNs, or even 10M for that matter, I'm all ears

I think we are all observing exponential rate of office backends being
outsourced. Also notice that grow of public AS numbers is not that
steep. Through last 12 years we allocated 50K !
http://www.potaroo.net/tools/asns/

So IMHO it is not that unrealistic that some global SP (maybe Google,
Microsoft, Apple2 etc... :) could offer free Internet access
everywhere they could reach or where law mandates free "last mile".
Would we want to limit number of their global customers ? Would we
really need to invent new hacks to work around private AS number
starvation ? Of course it is dead clear that Internet access does not
mandate use of BGP even for multihomed sites (example: LISP). But this
is IDR so I guess talking about BGP here is ok.

My seemingly wild suggestions to offer half of the space as private or
think about make AS hierarchical were aiming precisely in such new
EBGP (or EBGP-lite) peerings for large numbers of IPv4/IPv6/VPNs
customers.

If someone would to use this new RFC for such applications let me
reverse the question .. do we have sufficient reasons to limit the
space to 1M customers ? Are we afraid that even if we reserve 31 bits
the public AS will experience shortage anytime soon considering
current grow rate of public as number assignments ?

Best wishes,
R.

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 19 Dec 2012 09:57:06 -0500

On Wed, Dec 19, 2012 at 07:58:13AM -0600, David Farmer wrote:
> I have trouble supporting the idea of starting the range at 4B or
> 4.2B, I see no justification for reserving nearly 300M or even 100M
> ASNs for private use.

I agree there is no immediate use case I'm aware of for such a large
range, I'm failing to see any cons as none of the proposals poses any
real threat to the overall space (I think any real threat to future
changes in allocation or use of the 4B ASN space to maximum would come
from putting the range in places other than the start or end).

> 
> I agree, as do most of the rest of you it seems.  There were numbers
> in the 10k to 50K range talked about as reasonable numbers that
> people saw immediate use cases for.  It was then discussed to round

Trying to predict the future is hard.  BGP on VMs could make these
ranges far too small.  This is not to meant to say that eBGP with
private use ASN's has some specific use case scenario here I think we
need to delve into to further the discussion, but it does seem within
the realm of possibility that a single organization (NOT AN ISP or
someone assigning numbers externally) could exceed a 10-100K range with
certain use cases.  This is a viable enough business that companies are
selling BGP routers on VM's as products...

> that up a couple orders of magnitude so we wouldn't have to revisit
> this again in our life-times.  That seemed like a good idea.  So, 1M

I think this continues to be a very good idea so this issue does not
need to be re-visited.

> another order of magnitude plus some.  That choice was arbitrary,

The original range was arbitrary, the new range is arbitrary, most
naming and numbering is.  By putting it at end of range it is somewhat
less abitrary as it's a convention at least.

> Now the issue of a human/decimal/regexp friendly range has come up
> as being very desirable, I think this is a valid issue.  However, I
> see no justification to add yet another order of magnitude or more
> of ASNs to achieve this goal, taking it to the 100M or 300M range of
> ASNs and using 2% or 7% of the 32bit ASNs.

I agree 7% is too big.  2% does not seem unreasonable to me.

> human/decimal/regexp friendliness point of view and actually reduce
> the size of the range just a little in the process, by selecting
> 4.28B as the beginning of the private ASN range.  Leaving just under
> 15M private ASNs for use.  This seems like way more than enough and

I'm OK with this proposal as well.  It (42[8-9]...) is not quite as
identifiable or human friendly as 42... , but fairly close.  In the
view of the overall space, I don't think this is a a vastly different
proposal (in other words, the savings of this number of ASNs may not
be useful, but I'm fine with it, although I still prefer Warren's
suggestion).

Maybe some others would like to weigh in on one of the above options now
that it's a focused discussion (otherwise I plan to make the small edits
discussed in previous threads and move the start of range to
42xxxxxxxx so we can close this out...)

Jon

---

From: Jeff Wheeler <[email-masked]>
Date: Wed, 19 Dec 2012 10:12:31 -0500

> I agree 7% is too big.  2% does not seem unreasonable to me.

Do you foresee other kinds of large reservations being made from the
32-bit ASN space?

If NO, then 7% is not too big.  If it were, 2% would also be too big.
If you think public ASNs will be exhausted again in the future, and
having 5% more public ASNs will prevent that eventual exhaustion, I'd
love to see a basis for that prediction.

Basically, what I'm saying is, if 7% is too big then now is a good
time to start talking about 64-bit ASNs.  Everyone knew the 16-bit ASN
space would probably need expansion, and most folks I know came to
that realization in the mid- to late-1990s.  It's 2012 now and we
still do not have an extended BGP community formatted as 32:32 bits,
which is needed by numerous operators for BGP route advertisement
control.  Some major transit networks still don't have 32-bit ASN
support for their customers.  If 15 years isn't enough to go from
problem realization to feature-complete and widely-deployed fix, then
please, stop worrying about 7% or 2% and start crying that "the sky is
falling," so you can have 64-bit ASNs before you run out of 32-bit
ones.

If YES, you do imagine other large reservations being made from the
32-bit ASN space, have there been any proposals?  Will these
proposals, combined with existing public ASN use, exhaust 93% of the
32-bit space but not 98% of it?

The only "threat" I see to the 32-bit ASN space is the notion that RIR
policy should allow delegation of large blocks of ASNs to
organizations (companies, service providers) for whatever uses they
can imagine.  If that happens, I do not think +/- 5% global ASN pool
size will make a difference.  Either such RIR policy will run the ASNs
out, or it won't.

> 42xxxxxxxx so we can close this out...)

I asked some operators about decimal vs bit-aligned, and virtually all
feel strongly in favor of decimal-alignment.

I asked some to choose between starting a larger private range at
900k, 9000k, or 4.2b, and found there is much less interest in even
expressing an opinion at that point.

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 19 Dec 2012 10:20:22 -0500

> http://www.potaroo.net/tools/asns/

I agree that this is the case.

> current grow rate of public as number assignments ?

I think there is hope that there will be interesting growth on the
Internet or globally unique identifier use cases with Public ASN
registrations and that RIR policies may change to encourage these use
cases over time.

It's hard to tell if you are seriously suggesting a 50% proposal still,
but I would consider this is a substantive change to the intent,
motivation and content of the draft which is for a single organization
(and Private Use) and would probably require a new draft.  I can't
accept a proposal to move to 50% in the draft and there seemed to be no
energy from anyone that this is the right direction.  It also seems to
then remove the possibility that these types of allocations would be
from Public space, and disallow other proposals such as the one you
started a seperate thread about by consuming too much of the overall
space to make them acceptable any longer (there by forcing more use
cases with large number of ASN needs into Private Use space).

However if your overall point is that 10M - 100M is not unreasonable for
this draft as is, I agree and think certain variations of use cases
(more the backend ones) you identified above would be Private Use if a
single organization is allocating and managing the ASNs (in my mind more
likely the large office backend customers than a provider, or a provider
using BGP in these scenarios transparently / not managed by the customer).

Jon

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Dec 2012 16:25:23 +0100

Hi Jon,

> using BGP in these scenarios transparently / not managed by the customer).

That's precisely my overall point.

The 50% was just the example of illustration so we see the full
pendulum here not just it's small section ;-)

Cheers,
R.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Dec 2012 15:35:27 +0000

Hi Jon,

On 17/12/2012 16:29, Jon Mitchell wrote:
> that makes it 4200000000 - (end)

I've floated the idea with a couple of operations people, and the small
sample that were interested are split between 4200000000 and the lower
proposed ranges.  Personally, I'm strongly in favour of the lower ranges,
but at this stage, the bikeshed doesn't need any more paint thrown at it.

Regarding Dave's concerns about allocating so many, this is a complete non
issue.  It's going to be a long while before we get from assigning 50k ASNs
to 4199999999.  Even if we do, we'll have generated such momentum in terms
of allocation that it will be necessary to move to 64 bit ASNs, which we
can do using a similar style of transition technology that we used for
asn16 -> asn32.  I.e. if you've reached 93% of the potential range, that's
well beyond the point at which you need to plan to expand the range.

So I'd say go ahead with 4200000000-end.  Thanks for taking Jeff's and my
comments on board - very much appreciated.

Nick

---

From: Richard Hartmann <[email-masked]>
Date: Thu, 20 Dec 2012 12:49:35 +0100

On Wed, Dec 19, 2012 at 4:35 PM, Nick Hilliard <[email-masked]> wrote:

>  the bikeshed doesn't need any more paint thrown at it.
>

Agreed.

I.e. if you've reached 93% of the potential range, that's
> well beyond the point at which you need to plan to expand the range.

Also agreed.

> comments on board - very much appreciated.

And yet another agreement.

I believe that operational concerns have all been addressed so I'd like to
state "support" once again.

RIchard

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 09:03:56 -0600

I know the last call is over so ignore this if you wish;  However, I've 
been thinking about the issue of filtering private ASNs through out the 
discussion, but I hadn't identified what was bugging me until now.

Here are a couple quotes for some context;

On 11/29/12 13:10 , Jon Mitchell wrote:
> Any network can filter private ASNs as well as various other types of
> ASNs on ingress that they do not want to not accept/propogate.  This
> draft will have no impact on whether people tend to do that correctly or
> not in my opinion.  Folks who have no use for more than a thousand
> internal use ASNs today are not likely to use this new range.

On 11/30/12 14:15 , Brian Dickson wrote:>
 > If you see it on the Public Internet, it does not belong and can be
 > ignored safely, and should not be propagated to one's Internet
 > peers/customers.

But several others have made similar comments as well.

This is basically covered in Section 3 "Operational Considerations" in 
the draft.  Here is what it says now;

    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.  Operators are cautioned to ensure any filters or
    implementation specific features that recognize private use ASNs have
    been updated to recognize both ranges prior to making use of the
    newer, numerically higher range of private use ASNs.

I like that this says "private use ASNs must be removed from the AS_PATH 
before being advertised to the global Internet."  However, it finally 
hit me that in the quotes above, and in others as well, we have said "if 
you see private use ASNs on the global Internet you can filter them." 
But, this is only implied by the text in section 3, not explicitly 
stated.  So, I suggest that section 3 also explicitly state that 
operators may filter private use ASNs they receive from the global 
Internet.

So here is some suggested text.

    Operators may drop or disregard any prefix received from the global
    Internet that is originated from or that contains a private use ASN
    in the AS_PATH.  This may result in unpredictable connectivity for
    any prefix originated from or containing a private use ASN in the
    AS_PATH.  Therefore, all operators using private use ASNs to
    originate prefixes or passing an AS_PATH that contains private use
    ASNs to the global Internet, must remove all private use ASNs from
    the AS_PATH before being advertised to the global Internet.
    Furthermore, operators are cautioned to ensure any filters or
    implementation specific features that recognize private use ASNs
    have been updated to recognize both ranges prior to making use of
    the newer, numerically higher range of private use ASNs.

Again the intent of the change is to explicitly state operators can 
filter any prefixes received from the global Internet that uses private 
use ASNs.  In addition to stating you must not send the to the global 
Internet in the first place.

Thanks

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 10:27:21 -0500

David -

I just posted a new rev of the doc which I hope is final incorporating
the changes discussed on the list previously (must have just crossed in
the wires with this email).  I made slight changes to the section you
describe, although I put the focus on filtering on the user of private
ASNs (outbound).

I think whether or not filtering inbound or not is a good idea is
largely operator preference (I'm personally in favor as it pushes the
drop closest to the source of the error which I'm generally in favor of)
and the draft is not meant to dictate specific behavior (this is not a
BCP doc) in this regard however it seems like if you are using private
ASN's, it will simplify things a bit from a troubleshooting standpoint
to not mis-identify a leaked private ASN as one of your own by inbound
filtering at your border, but the impact in either case is the same and
minimal (routes that are leaked are the ones impacted only - encouraging
those who leak to fix their issues).

Also, it should be noted none of these issues are new (related to the
new range), although some of them may have to be revisited as Pradosh
pointed out if remove private implementations are not updated, and that
is the focus of the text change I did make.

Jon

On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote:
> I know the last call is over so ignore this if you wish;  However,
> I've been thinking about the issue of filtering private ASNs through
> out the discussion, but I hadn't identified what was bugging me
> until now.
> 
> This is basically covered in Section 3 "Operational Considerations"
> in the draft.  Here is what it says now;
> 
> I like that this says "private use ASNs must be removed from the
> AS_PATH before being advertised to the global Internet."  However,
> it finally hit me that in the quotes above, and in others as well,
> we have said "if you see private use ASNs on the global Internet you
> can filter them." But, this is only implied by the text in section
> 3, not explicitly stated.  So, I suggest that section 3 also
> explicitly state that operators may filter private use ASNs they
> receive from the global Internet.
> 
> filter any prefixes received from the global Internet that uses
> private use ASNs.  In addition to stating you must not send the to
> the global Internet in the first place.
> 
> Thanks
> 
> --

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 10:55:32 -0500

i have a strange question at this late date.  why is this draft in idr
at all?  it is not protocol, it is ops.  i would think it would be in
grow.  and certainly, grow should at least review it.

randy

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 10:14:42 -0600

On 12/20/12 09:27 , Jon Mitchell wrote:
> the wires with this email).

Yep, I saw it right after clicking send.

> I made slight changes to the section you

I'm OK with the focus being on outbound filtering and outbound filtering 
and being required with a "MUST" clause.  However, I believe that 
inbound filtering should be explicitly allowed, but not required, with a 
"MAY" clause being included as well.

However, there is the old mantra of "trust but verify".  So I think we 
need to be explicit that any other operator "MAY" filter inbound.  If 
you get the balance right this can be use to reenforce your focus that 
operators "MUST" filter outbound.

I'll agree my suggested text below did not get the balance right and 
focuses to much on the inbound filtering.  However, both your original 
and new text don't make it explicit that an operator "MAY" filter 
inbound if they wish.  That is what I would like to see added somehow.

> is the focus of the text change I did make.

Completely agree, not a new issue.  However, we are touching the text, 
and vendors are going to need to touch code, so now is the time to fix 
issues, especially if they lead to divergent interpretations.

...

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Dec 2012 16:32:29 +0000

On 20/12/2012 16:14, David Farmer wrote:
> and being required with a "MUST" clause.

I don't think the IETF is too hot on the idea of "MUST" appearing in non
normative documents?

Nick

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 10:47:54 -0600

> 42xxxxxxxx so we can close this out...)

OK, I'll relent, 4.2B it is.  But, we need to be clear about why we are 
selecting this; which is to make regexp matching of private use ASNs 
easier.

The idea is to allow the simple regexp of 42???????? to match private 
use ASNs.  However, this makes a few assumptions.

1. While not part of the Private Use ASN range, the intended regexp also 
matches the reserved ASN 4294967295, and therefore 4294967295 can never 
be a valid ASN in an AS_PATH.

2. The intended regexp would select ASNs beyond the 32bit ASN range, if 
they were valid, that is 4294967296 through 4299999999. Therefore, if 
the ASN range were ever expanded to make these valid ASNs, the private 
use ASN range would also need to be expanded to be included these ASNs 
as well.

If we want to use 4.2B as the starting point to simplify regexp matching 
of the private use range then these assumptions need to be explicitly 
stated in the draft.

Thanks.

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 20 Dec 2012 11:52:23 -0500

On Thu, Dec 20, 2012 at 11:47 AM, David Farmer <[email-masked]> wrote:
> matches the reserved ASN 4294967295, and therefore 4294967295 can never be a
> valid ASN in an AS_PATH.

Fortunately, it can never be a valid ASN in an AS_PATH.  So it won't
matter if a regexp matches it as private.

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 10:59:11 -0600

> matter if a regexp matches it as private.

I agree, but I'm not sure where this is explicitly stated, its not in 
RFC 6793.  So, unless it is explicitly stated somewhere else it needs to 
be stated here.

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 12:03:54 -0500

> I don't think the IETF is too hot on the idea of "MUST" appearing in non

normative is how a document is referred to by another document, and one
can never know that.

and, despite common rumor, one can have 2119 language in an info or bcp.

rand

---

From: Jared Mauch <[email-masked]>
Date: Thu, 20 Dec 2012 12:04:38 -0500

On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote:
> OK, I'll relent, 4.2B it is.  But, we need to be clear about why we
> are selecting this; which is to make regexp matching of private use
> ASNs easier.
> 
> The idea is to allow the simple regexp of 42???????? to match
> private use ASNs.  However, this makes a few assumptions.
> 
> 1. While not part of the Private Use ASN range, the intended regexp
> also matches the reserved ASN 4294967295, and therefore 4294967295
> can never be a valid ASN in an AS_PATH.

	I think this poses the need to have vendors replace regex
with something where you can specify a list or range of the integers
you wish to match.

	I have wanted to tie prefix to the integer string encoded in AS_PATH
for some time and there is no effective way to do this.

	- jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 11:11:11 -0600

> I don't think the IETF is too hot on the idea of "MUST" appearing in non

To be clear, the draft uses the word "must", which I take as the normal 
English meaning of the word.  I was using "MUST" and "MAY" in my email 
to add emphasis, not to make normative statements.

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 11:25:17 -0600

> for some time and there is no effective way to do this.

If we had something like that, we wouldn't care about 4.2B, which was my 
point along time ago about this being "CLI/Config semantics issue and 
not a standards or allocation issue".

But, we're deciding to make the special allocation to suite this issue, 
I'm fine with that.  We just have to be explicit about the issues this 
choice creates.  There is no perfect answer here.

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 12:38:12 -0500

This was discussed upfront with WG chairs from both initially, and I
agree it is odd that you would bring it up at this late date.  I
personally believe that this an update of RFC 1930 which was IDR product
and a bit out of GROW charter since the focus of this draft is not about
global Internet.  IDR charter includes support for four-octet AS numbers
in BGP, and I believe it fits well into that.  IDR description also
states it supports use of BGP-4 by IPv4 and IPv6 networks, which this
draft continues to make room for growth in the use of the protocol
outside of Internet use cases.  Also this draft is a reservation
document, not an operations document, but I agree also not a protocol
extension of any kind.

I'm not against a GROW review (maybe one of the chairs, AD or IESG will
recommend it anyway), however it also appears many of the active
participants of GROW have already participated in the discussion.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 12:48:36 -0500

David -

Just to close this out, I don't plan to make these additional changes to
the draft.  I don't plan on saying operators MUST filter private use
ASN's outbound specfically with an AS_PATH filter list or dictate to
operators anything they must do except not to send private use ASN's to
the Internet, which is the same guidance given in RFC 1930 and already
in the draft.  Operators are inventive and can use whatever tool to do
this they please (community/prefix based could be used if they know
which communities or prefixes come from private ASNs for instance).

On the inbound filtering, operators may filter /25 or longer, their own
address space, private or public ASN's or anything else they please in
my opinion, and none of this needs to be codified in this draft, however
is certainly welcomed in BCP documents.  We've already established in
many threads that the worse case is a prefix from a mis-configured
(leaked to Internet Private Use ASN) is dropped.

Jon

On Thu, Dec 20, 2012 at 10:14:42AM -0600, David Farmer wrote:
> I'm OK with the focus being on outbound filtering and outbound
> filtering and being required with a "MUST" clause.  However, I
> believe that inbound filtering should be explicitly allowed, but not
> required, with a "MAY" clause being included as well.
> 
> However, there is the old mantra of "trust but verify".  So I think
> we need to be explicit that any other operator "MAY" filter inbound.
> If you get the balance right this can be use to reenforce your focus
> that operators "MUST" filter outbound.
> 
> focuses to much on the inbound filtering.  However, both your
> original and new text don't make it explicit that an operator "MAY"
> filter inbound if they wish.  That is what I would like to see added
> somehow.
> 
> Completely agree, not a new issue.  However, we are touching the
> text, and vendors are going to need to touch code, so now is the
> time to fix issues, especially if they lead to divergent
> interpretations.
> 
> >Jon
> >
> >

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 20 Dec 2012 12:50:46 -0500

> with something where you can specify a list or range of the integers

This already exists in major implementations.  Most of us are so used to
how regexps work in other environments, we don't realize there is more than
one way.  For example, on a Juniper box, do this:
root@Juniper> show route aspath-regex ".* [3000-3999] .*" terse
 ... matches plenty of routes like you'd hope ...

Similar thing works on Cisco.  Unfortunately the regexp engines used for
offline processing (Perl, grep, whatever) are usually not customized for
dealing with AS_PATH expressions.
$ perl -wne 'print if / [6000-6999] /;' routes-from-tinet.txt |head -3
inet.0: 423540 destinations, 1806800 routes (423540 active, 0 holddown, 0
hidden)
  5.144.136.0/21          A.B.C.D         0                  3257 22652
22652 8304 I
  18.0.0.0/8              A.B.C.D         90                 3257 174 3 I

Obviously, the above won't "do what you mean" in Perl.  But with the
proposed extended Private ASN range 4.2B+, you will be able to match that
using any common regexp engine.

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 13:05:41 -0500

> private use ASNs.  However, this makes a few assumptions.

Human identifiable range was the primary concern raised with regex
implementation another given justification for changing the
recommendation to IANA for the start of range.

> can never be a valid ASN in an AS_PATH.

The draft does not state how to construct a regex, this is out of scope
for the draft.  Some operators may not even choose or need to filter
private use ASN's inbound or outbound based on their
requirements/design.

> 
> 2. The intended regexp would select ASNs beyond the 32bit ASN range,
> if they were valid, that is 4294967296 through 4299999999.
> Therefore, if the ASN range were ever expanded to make these valid
> ASNs, the private use ASN range would also need to be expanded to be
> included these ASNs as well.

Certainly something operators should concern themselves with when
discussions start on moving beyond 4 byte ASNs (maybe a note about it
could be attached to that draft).  On a side note, do you plan on this
before or after IPv6 exhaustion? 

> If we want to use 4.2B as the starting point to simplify regexp
> matching of the private use range then these assumptions need to be
> explicitly stated in the draft.

I disagree, I prefer not delving how to construct regex's properly or
stating how they work in various implementations in a simple IANA
reservation draft.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 20 Dec 2012 13:07:19 -0500

> using any common regexp engine.

	Not likely:

RP/0/RSP0/CPU0:r07.dllstx09.us.bb#sh bgp regexp [65000-1024000]
BGP router identifier x.x.x.x, local AS number 65000
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0000000   RD version: 70417360
BGP main routing table version 70417360
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 1.0.0.0/24         x.x.x.x             0             0 3356 15169 i
* i                   x.x.x.x         4294967294    100      0 1299 15169 i
* i                   x.x.x.x         4294967294    100      0 1299 15169 i
* i                   x.x.x.x         4294967294    100      0 3356 15169 i
* i                   x.x.x.x         4294967294    100      0 3356 15169 i
* i                   x.x.x.x         4294967294    100      0 1299 15169 i
...

This is on modern code built and released in the past 6 months.

	- Jared

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 13:15:47 -0500

> > Similar thing works on Cisco.  Unfortunately the regexp engines used for

This is my experience as well, I believe that was XR output which even
has the CLI say ios-regex for their as-path filters even, implying this
is true for most if not all Cisco implementations.  The range operator
appears to be a single character/digit function only.  I agree better
tools in general are warranted from lot's of vendors but don't think
this document is the right place for specifying those.

Jon

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 13:43:42 -0600

> which communities or prefixes come from private ASNs for instance).

The -01 draft says "Private Use ASNs must be removed from the AS_PATH 
before being advertised to the global Internet."  This is perfect, how 
this is accomplished is completely up to the operator.  But, it says you 
MUST remove Private ASNs outbound to the Internet.

> (leaked to Internet Private Use ASN) is dropped.

All I was looking for was something making explicit and reinforcing to 
those using Private Use ASNs, everyone else MAY disregard prefixes using 
Private Use ASNs inbound from the Internet.  Which is why they MUST 
remove Private ASNs outbound to the Internet.  Its in their own interest 
that they remove the Private Use ASNs not everyone else.

But if you believe that belongs in a separate BCP then OK, but them my 
question would be why doesn't this whole section belong in a separate BCP.

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 16:17:40 -0500

> the draft.

thanks.  see you in ietf last call.

randy

---

From: "Neil J. McRae" <[email-masked]>
Date: Thu, 20 Dec 2012 21:38:02 +0000

I echo Randy's view that this needs grow to look at it.

> well beyond the point at which you need to plan to expand the range.

transition technologies they work really well ! Because we never compromise them do we!?

Neil.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Dec 2012 21:52:22 +0000

> I echo Randy's view that this needs grow to look at it.

No major objection to that.  Does that happen now, or once it's finished WGLC?

> transition technologies they work really well ! Because we never compromise them do we!?

all things considered, the asn16->asn32 migration is going remarkably well.
 I'd say the idea is mature enough so that if we need to do an asn32 ->
asn64 migration in 2.5 million years time (based on current asn usage
figures), it would probably proceed well enough that we don't need to worry
to much about it at this stage.  That's if we make it past the end of the
world tomorrow.

Nick

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 16:56:27 -0500

Randy and Nick:

Please note that Randy is correct about the use of MUST language, and it is
an appropriate editorial question for WG LC or the period between WG LC and
IETF LC ending. 

For my clarification, why is the following text using "must" without the
MUST language? 

   If Private Use ASNs are used and prefixes are originated from these
   ASNs which are destined to the Internet, Private Use ASNs must be
   removed from the AS_PATH before being advertised to the global
   Internet.

In my reading of this text, it is specifying the 2119 language.  In this
case the text would be:

   If Private Use ASNs are used and prefixes are originated from these
   ASNs which are destined to the Internet, Private Use ASNs MUST be
   removed from the AS_PATH before being advertised to the global
   Internet.

I look forward to the authors comment on this point.  Since this document is
modifying a BCP (RFC1930), it is likely to be a BCP.  Please note I consider
this an issue that the authors need to address this RFC2119 issue.   Please
note this type of editorial review is normal during the post WG-LC  when the
chairs perform an editing review prior writing up a IESG Shepherding report.

I am not widening our restricted request for advice on the WG LC agreement.
We are still focus this week on the range.   

May you have Shalom in your Holidays, 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy
Bush
Sent: Thursday, December 20, 2012 12:04 PM
To: Nick Hilliard
Cc: [email-masked]
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

> I don't think the IETF is too hot on the idea of "MUST" appearing in 
> non normative documents?

normative is how a document is referred to by another document, and one can
never know that.

rand

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 17:38:20 -0500

I'm comfortable making the change to a capital MUST for this sentence
and adding the appropriate reference to RFC 2119 as necessary.  I'm just
not comfortable telling operators how to perform that action as there
are a number of options to do so, which was my point to David (and he
seemed to be ok with).  I will make the changes as necessary to the
abstract where this statement exists as well.

As for BCP versus info, I leave that up to the chairs, but this does not
obsolete or otherwise change text in RFC 1930 outside of the IANA
considerations section (RFC 1930 is primarily about justification for an
ASN).  There is no "practice" being advocated by the draft to be best or
current, outside of the practice of not sending Private Use ASNs to the
Internet.

Jon

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 17:43:42 -0500

Randy - please see my commment to Susan, could you see if that addresses
your concern, or are you suggesting that the draft states operators
SHOULD do inbound AS_PATH filtering on private ASNs (I'm not sure this
is even common practice today, although some operators do so).

Since you deleted the context of the change you agreed with David on (he
had suggested a couple), it's a bit hard to infer your meaning.

Jon

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 17:55:39 -0500

Jon:

My understanding of your text is that it operationally MUST be done.   I
like you, will  leave the "how to" to implementations and operators.   If
it's a filters or pure fairy-magic, it is fine by me.  I do not think this
MUST modification implies the method. 

My understanding from my wonderful Routing ADs is something that modifies a
BCP (RFC1930) is generally a BCP.  However, we'll let Stewart Bryant (our
Routing AD) weigh in on that fact. 

Sue 

-----Original Message-----
From: Jon Mitchell [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 5:38 PM
To: Susan Hares
Cc: 'Randy Bush'; 'Nick Hilliard'; [email-masked]; [email-masked]
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

I'm comfortable making the change to a capital MUST for this sentence and
adding the appropriate reference to RFC 2119 as necessary.  I'm just not
comfortable telling operators how to perform that action as there are a
number of options to do so, which was my point to David (and he seemed to be
ok with).  I will make the changes as necessary to the abstract where this
statement exists as well.

Jon

On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote:
> Randy and Nick:
> 
> Please note that Randy is correct about the use of MUST language, and 
> it is an appropriate editorial question for WG LC or the period 
> between WG LC and IETF LC ending.
> 
> For my clarification, why is the following text using "must" without 
> the MUST language?
> 
> In my reading of this text, it is specifying the 2119 language.  In 
> this case the text would be:
> 
> I look forward to the authors comment on this point.  Since this 
> document is modifying a BCP (RFC1930), it is likely to be a BCP.  Please
note I consider
> note this type of editorial review is normal during the post WG-LC  
> when the chairs perform an editing review prior writing up a IESG
Shepherding report.
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Randy Bush
> normative is how a document is referred to by another document, and 
> one can never know that.
>

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 18:02:06 -0500

I agree with the understanding (in fact one might say this is implied
already by this being for Private Use).  A question for you or Randy..
does this make RFC 2119 a normative or informative reference given this
is not a standards track document?  If Normative, should I include the
prescribed "Specification of Requirements" section text as well?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Dec 2012 23:02:51 +0000

> abstract where this statement exists as well.

If it's of interest, rfc 6666 ran into much the same issue recently with
the issue of leaking the rtbh prefix to ebgp peers.  We decided on SHOULD
rather than MUST because there probably were situations where there might
be valid operational reasons for leaking the prefix to a peer. I would
think the same arguments hold for a private ASN range.

http://tools.ietf.org/html/rfc6666#section-5

Nick

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 18:20:11 -0500

Jon:

Please refer to my comment on BCP as I believe it must be a BCP since it
modifies a BCP.  In a BCP, I believe the MUST uses RFC 2119. 
I believe, the WG chairs can change it to a BCP given it modifies a BCP - as
an editorial change. 

I've asked for Stewart Bryant to give us a read on the BCP issue.  And as
always, the WG will speak if up someone objects. 

Sue 

-----Original Message-----
From: Jon Mitchell [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 6:02 PM
To: Susan Hares
Cc: 'Randy Bush'; 'Nick Hilliard'; [email-masked]; [email-masked]; Pete
Resnick

I agree with the understanding (in fact one might say this is implied
already by this being for Private Use).  A question for you or Randy..
does this make RFC 2119 a normative or informative reference given this is
not a standards track document?  If Normative, should I include the
prescribed "Specification of Requirements" section text as well?   

On Thu, Dec 20, 2012 at 05:55:39PM -0500, Susan Hares wrote:
> it's a filters or pure fairy-magic, it is fine by me.  I do not think 
> this MUST modification implies the method.
> 
> My understanding from my wonderful Routing ADs is something that 
> modifies a BCP (RFC1930) is generally a BCP.  However, we'll let 
> Stewart Bryant (our Routing AD) weigh in on that fact.
> 
> Sue
> 
> 
> and adding the appropriate reference to RFC 2119 as necessary.  I'm 
> just not comfortable telling operators how to perform that action as 
> there are a number of options to do so, which was my point to David 
> (and he seemed to be ok with).  I will make the changes as necessary 
> to the abstract where this statement exists as well.
> 
> As for BCP versus info, I leave that up to the chairs, but this does 
> not obsolete or otherwise change text in RFC 1930 outside of the IANA 
> considerations section (RFC 1930 is primarily about justification for 
> an ASN).  There is no "practice" being advocated by the draft to be 
> best or current, outside of the practice of not sending Private Use 
> ASNs to the Internet.
> 
> Jon
> 
> > Please note that Randy is correct about the use of MUST language, 
> > and it is an appropriate editorial question for WG LC or the period 
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Randy Bush
> > > I don't think the IETF is too hot on the idea of "MUST" appearing 
> > > in non normative documents?
> >

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 18:24:08 -0500

Nick:

I'd be interested in you suggesting the situations would be valid to leak
the AS private path AS to a peer, before we downgrade to a "SHOULD". 

Sue 

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 6:03 PM
To: Jon Mitchell
Cc: Susan Hares; 'Randy Bush'; [email-masked]; [email-masked]
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

> to the abstract where this statement exists as well.

If it's of interest, rfc 6666 ran into much the same issue recently with the
issue of leaking the rtbh prefix to ebgp peers.  We decided on SHOULD rather
than MUST because there probably were situations where there might be valid
operational reasons for leaking the prefix to a peer. I would think the same
arguments hold for a private ASN range.

Nick

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 20 Dec 2012 15:33:57 -0800

+1

Acquisitions, ASN merges etc may all involve use of private ASN space
between consenting parties.  I think this is a SHOULD.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 19:01:29 -0500

Edward:

+1 - that Certainly Acquisitions and ASN mergers will cause multiple private
ASNs. 

The draft's text says :

" Private Use ASNs must be removed from the AS_Path before being advertised
to the global Internet."  

The question is not whether it goes out of a single Private ASN, but whether
it cross the global Internet.  For example, if several private DCs band
together to have a private exchange beyond the reaches of the global
Internet, I have no reason to specify what happens with private ASN behind
in those private party exchanges. 

How do certain Acquisition and ASN mergers cause private ASN to cross the
global Internet?  And why are these private AS not being hidden by a public
AS or AS Confederation. 

Sue 

From: Edward Crabbe [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 6:34 PM
To: Nick Hilliard
Cc: Jon Mitchell; idr wg; Susan Hares
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

+1

Nick

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 20 Dec 2012 16:08:02 -0800

Yep, agree with MUST usage for 'the global internet", but not for arbitrary
ebgp peers, per Nick's mail.

On Thu, Dec 20, 2012 at 4:01 PM, Susan Hares <[email-masked]> wrote:

> Edward:****
>
> ** **
>
> +1 – that Certainly Acquisitions and ASN mergers will cause multiple
> private ASNs. ****
>
> ** **
>
> The draft’s text says :****
>
> ** **
>
> “ Private Use ASNs must be removed from the AS_Path before being
> advertised to the global Internet.”  ****
>
> ** **
>
> The question is not whether it goes out of a single Private ASN, but
> whether it cross the global Internet.  For example, if several private DCs
> band together to have a private exchange beyond the reaches of the global
> in those private party exchanges. ****
>
> ** **
>
> AS or AS Confederation. ****
>
> ** **
>
> Sue ****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, December 20, 2012 6:34 PM
> *To:* Nick Hilliard
> *Cc:* Jon Mitchell; idr wg; Susan Hares
>
> *Subject:* Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00****
>
> ** **
>
> +1****
>
> ** **
>
> between consenting parties.  I think this is a SHOULD.  ****
>
> ** **
>
> On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard <[email-masked]> wrote:***
> *
>
> > abstract where this statement exists as well.****
>
> Nick****
> https://www.ietf.org/mailman/listinfo/idr****
>
> ** **
>

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 20 Dec 2012 19:20:52 -0500

I agree that any use case that requires the text to move to should is probably not a Private Use case by definition.

-Jon

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 18:35:12 -0600

> recommendation to IANA for the start of range.

Bull!! Lets be honest here, 10 digits without any separators doesn't 
meet any definition of human friendly I can think of.  Also, humans 
would recognize 4.28B and above just about as easy as 4.2B and above, 
the real reason to go to 4.2B is it makes the regexp much simpler.  I'm 
fine with that, but its to make regexp easy.  However, picking 4.2B to 
make the staring point human/decimal/regexp friendly but completely 
ignoring the any issues at end point isn't going to work either.

> private use ASN's inbound or outbound based on their

That argument doesn't fly, because you are saying that they MUST filter 
outbound to the Internet.  Yes, if there not announcing to the Internet, 
then there isn't an issue, but that is a common enough use case that it 
makes scene to provide some guidance on how to properly implement the 
filter you are saying they must implement.  You don't need to cover 
every possible solution, but saying that regular expression of the from 
42????????, where "?" selects 0-9, would provide a very big hint.

However, my primary motivation in bringing up the end point issues 
aren't operational, but is to ensure future protocol work doesn't create 
an issue with how people use the Private Use range.  If there were some 
future protocol changes, especially anything that required 4294967295 to 
be valid within the AS_PATH, there could be issues. I don't think anyone 
thinks this should happen, but its not explicit anywhere.  I'm only 
trying to make sure we don't making a similar mistake that was made with 
AS65535 in RFC 1930, that we are fixing now.

As a mater of fact this could be an issue with any range, no matter what 
size we pick, at the top of the 32bit ASN range.  The regexp issues with 
4.2B is only one possible issue.  There could easily be issues with 
4294967295 and your original range.  It would be problematic for many 
reason if 4294967295 became a valid ASN within AS_PATH.  If we're going 
to pick a range at the very top end of the 32bit ASNs then that should 
be made clear.

Also, you say were picking 4.2B primarily to be human friendly.  But, 
there is nothing human friendly about 4294967294 being part of the range 
and that 4294967295 is not part of the range.  So at the very least we 
should make it abundantly clear 4294967295 is not part of the range.

Maybe something like this, creating a new section;

    X. Other Reserved ASNs

    It should be noted that 65535 and 4294967295 are reserved ASNs,
    documented in the IANA Autonomous System Numbers Registry [IANA.AS].
    These two ASNs are the numerically highest values in the two-octet
    and four-octet AS number spaces respectively.  While directly
    adjacent to the Private Use ASNs they are not part of either
    Private Use ASN range, and MUST never be used as Private Use ASNs.
    However, any protocol changes effecting the status of these two ASNs
    should consider any impact on how the Private Use ASNs are used.

This makes it abundantly clear that these two ASNs are not part of the 
Private Use ranges, this conspicuously corrects RFC 1930 regarding 
65535. Further, it makes it clear there are no other valid ASNs above 
4294967295 that need to be worried about.  Finally, it make it clear 
that the current status of these two ASNs as reserved is important to 
the Private Use ranges and that any changes could have an impact on the 
use of Private Use ASNs.

> before or after IPv6 exhaustion?

Again its not the operators I'm worried about, its how future protocol 
work would interact the assumptions we are making about the validity of 
picking 4.2B as the starting point, and basically ignoring the end point 
issues.  This is mostly a hand wave for the operators, and that's fine, 
it will probably just work.  But, if the protocol guys do something in 
the future today's operational hand wave could become tomorrows ugly 
problem.

> stating how they work in various implementations in a simple IANA

While I'd prefer we did cover the whole regexp thing, that's not really 
necessary to deal with these issues.  If you include something like the 
text above regarding 4294967295, it makes it clear there are range 
endpoint issues that should be considered carefully.  I'd be OK dropping 
any discussion of what happens if you expand the ASN range, that is 
probably out of scope.  But the above text makes it clear that there are 
no valid ASNs above 4294967295, that should be enough of a hint if you 
don't cover the regexp stuff explicitly.

Thanks.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Dec 2012 19:40:47 -0500

Ed: 

+ 1 agree to your point.  Therefore,  I think the text is fine with the MUST
as it is.   

Sue 

From: Edward Crabbe [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 7:08 PM
To: Susan Hares
Cc: Nick Hilliard; Jon Mitchell; idr wg
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

Edward:

The draft's text says :

Sue 

+1

Nick

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Dec 2012 18:52:01 -0600

> abstract where this statement exists as well.

If you go to a capital MUST on the outbound to the global Internet then 
I fine with not say everyone else MAY disregard inbound from the global 
Internet.  However, if that MUST was changed to SHOULD then I would 
would want an everyone else MAY disregard inbound from the global Internet.

> current, outside of the practice of not sending Private Use ASNs to the

BCP is what I think it should be.

Thanks

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 20 Dec 2012 20:19:29 -0500

> the AS private path AS to a peer, before we downgrade to a "SHOULD".

This is happening in the DFZ today.  You don't have to take my word
for it.  Log onto a router and check.  You can even find 65535 in DFZ
AS_PATHs even though that is not a valid ASN!

I think it's called a Private ASN and by its very nature, it ought not
appear in a DFZ AS_PATH.

However, since some networks are actually doing this right now,
perhaps it is worth asking them why.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 21 Dec 2012 11:43:22 +0000

> the AS private path AS to a peer, before we downgrade to a "SHOULD". 

the proposed text states: "If Private Use ASNs are used and prefixes are
originated from these ASNs which are destined to the Internet, Private Use
ASNs must be removed from the AS_PATH before being advertised to the global
Internet."

To start off, there's the usual problem: what do we mean when we talk about
"the Internet"?

In fact there's more to the situation.  We're dealing with operational
stuff here rather than protocol specification, i.e. human behaviour rather
than computer specifications.  I'd have no problem with throwing "MUST"
around when dealing with protocol handling, but when it gets to operational
stuff, I would be a lot more circumspect for several reasons:

- operational people will happily ignore a MUST if they feel it suits their
purpose at a specific time.

- the Internet is a bunch of interconnected networks and what works for
policy for one network peer might not work for another.

- I don't not have the wisdom or the foresight to predict every eventuality
where there might be legitimate reasons to forward a prefix with a private
ASN over an ebgp peer.

- I suspect most private asn leaks we see in the DFZ are accidental, and
MUST won't help in this situation.

- if this is specified as 2119-compatible MUST, vendors may be tempted to
hardwire an AS path prefix filter for ebgp sessions into their code in a
way which cannot be circumvented (in the same way that e.g. 169.254/16 is
hardwired and cannot be used in a bgp NLRI).  I'd see lots of value in
having a vendor default of not forwarding private ASNs, but I think this
could be quite harmful to have an absolute prohibition

Private ASN leaks are going to happen in two main circumstances: accidental
and deliberate.  I don't think that putting in "MUST" will actually deal
with either. What's important from an operational point of view is getting
vendors to implement a default but overrideable filter so that the bar for
accidental leaks is raised to a sufficiently high point that accidental
leaks are only going to happen when the safety nets are removed.

If we're going to make a statement on this one way or another, I think it
should be along the lines of SHOULD rather than MUST, and that we should
consider including a vendor hint to suggest that the default implementation
behaviour would be to filter private asns.

This complicates issues slightly because we get into an issue of semantics:
 does the prefix get dropped?  Or does the private ASN component get
stripped from the AS path?

In term of specific situations where this might be useful, yeah, mergers
and acquisitions would be one.  Others might include private peering
between ASN confederations.  Or interconnections between the large number
of private networks around the world, many of which use a mixture of
private and public ASNs.  Or test peerings.

Anyway, these were some of the issues that cropped up during the WG
discussion phase for rfc 6666.  We eventually decided to go with the idea
of making a recommendation that the prefix shouldn't be transferred over
ebgp sessions, and specifically made the point in the security section to
highlight it.  This avoided the issue of defining "the Internet", while
encapsulating what we wanted to say in the way that we wanted to say it.

Nick

---

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Dec 2012 08:34:54 -0500

> AS_PATHs even though that is not a valid ASN!

Yup, Susan is well aware of this...

> perhaps it is worth asking them why.

'tis called a leak, and is (in every case I've seen) unintentional…

Someone forgot to add "remove-private" or (if they are masochists) "remove-private-as" to a peer somewhere….

W

--
I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, with great presence of mind, they brought Thousand Island Dressing and a bottle of chili sauce.
    -- Terry Pratchett

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 21 Dec 2012 09:05:51 -0500

> AS_PATHs even though that is not a valid ASN!

I think we are all aware of this.

> perhaps it is worth asking them why.

Isn't this like asking why folks leak RFC 1918 space into the global
routing table, /32's into the routing table, etc... ?  Mis-configuration
seems obvious, but I don't think a poll is a fruitful exercise.

I think because something happens today due to accidental (or poorly
designed networks that make fixing the issue difficult) doesn't mean we
should soften language that states operators (if they strive to be RFC
compliant) MUST or MUST NOT do something.  One of the reasons why it is
not fixed in these cases is likely that the impact is so low to the
originator (who may have a covering route) or the receiver.

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 21 Dec 2012 09:34:08 -0500

> To start off, there's the usual problem: what do we mean when we talk about

Terminology seems clear as outside of the "single organization" context
to which Private Use is defined?  This term is the same as in RFC 1930,
and I don't believe the leaks we see are due to semantic issues in that
document, nor future leaks will be based on mis-reading of this text.

> purpose at a specific time.

This is always true even for protocol specifications, implementers can
choose to forgo being RFC compliant for their own reasons.  At MUST it
will be obvious they are not in the right, if we soften it to should,
maybe the operators who ignore the SHOULD will say "the RFC didn't say I
MUST remove them" if asked to fix it?

> policy for one network peer might not work for another.

Private Use by definition should be not be seen on the Internet, we are
still awaiting the case where it should be seen outside a single
organization.

> where there might be legitimate reasons to forward a prefix with a private

The draft doesn't say not to send to eBGP peers, just peers outside of
your organization.

> MUST won't help in this situation.

Nothing produced by IETF will help in this situation, however I think
IETF should specify what is the correct behavior.

> could be quite harmful to have an absolute prohibition

Since this is not a protocol specification, I think this is personally
unlikely.  Given there is argueably (but not verifiably) many more
Private ASNs in use than Public ASNs, changing this default seems
unlikely.  Given the impact of leaked private ASNs versus leaked RFC
1918 space, and vendors not defaulting to not sending that, it would
seem unlikely this becomes a default.  But whether or not it does or not
is not likely going to be due to the operational considerations section
of this RFC in my opinion.

> leaks are only going to happen when the safety nets are removed.

I agree that nothing in this IETF draft will likely solve the leak
problem, however at least someone might point to it as an indication of
what is correct or not.

> behaviour would be to filter private asns.

I don't think this draft nor this section is a good place to specify
vendor implementation behavior.  This was meant to be guidance for
operators in use of Private ASNs.

> stripped from the AS path?

Yes, if we take it out of operator control and into vendor
implementation guidance, these would become risks.

> private and public ASNs.  Or test peerings.

I think you are focusing on some possible vendor implementation that
doesn't exist that prevents Private Use ASN exchange over every eBGP
peering and is not configurable rather than the guidance to operators.
If ANY of these cases require routes to go to the global Internet,
Private Use ASNs MUST not be in the AS_PATH as the draft says.   If
these use cases are not for routes that go to the global Internet, the
statment didn't apply in the first place.

Jon

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 21 Dec 2012 09:37:18 -0500

David:

On the inbound "MAY", I'm not sure I know which text in section 3 you are
indicating.  Rather than guess at the text you are implying, would you
please just send the exact text from the latest draft. 

Thank you, 

Sue 

-----Original Message-----
From: David Farmer [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 7:52 PM
To: Jon Mitchell
Cc: Susan Hares; [email-masked]; David Farmer
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

> to the abstract where this statement exists as well.

If you go to a capital MUST on the outbound to the global Internet then I
fine with not say everyone else MAY disregard inbound from the global
Internet.  However, if that MUST was changed to SHOULD then I would would
want an everyone else MAY disregard inbound from the global Internet.

Thanks

---

From: t.petch <[email-masked]>
Date: Fri, 21 Dec 2012 15:06:17 +0000

----- Original Message -----
From: "Jon Mitchell" <[email-masked]>
To: "Nick Hilliard" <[email-masked]>
Cc: <[email-masked]>; "Susan Hares" <[email-masked]>
Sent: Friday, December 21, 2012 2:34 PM
> document, nor future leaks will be based on mis-reading of this text.

Since we are putting this under IANA, then I think that the relevant
definition should not be RFC1930 but RFC5226 from which
"     Private Use - For private or local use only, with the type and
            purpose defined by the local site.
<snip>
            It is the responsibility of the sites
            making use of the Private Use range to ensure that no
            conflicts occur (within the intended scope of use)."

from which I would expect removal to be implicit for most readers. I see
no harm in including a MUST just to emphasize the point; and a
reference to site would probably be better than to Internet.

Tom Petch

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 21 Dec 2012 11:05:03 -0500

Nick:

Before I start, these are great questions.  Before, I start, I must repeat
John limited the discussion to the range comments.  Please get your comments
in often and early today on the range.

----------

Now, as to your questions... 
RFC 1930 says: 

10. Reserved AS Numbers

I will address "global Internet" rather than the phrase "Internet".

Many "fun" adventures in the past with BGP infrastructure have generally
been found to be someone's leak or accident.  Leaks/accidents if painful
enough, will inspire code and operational changes. There tales of equally
fun adventures within the private VPN or private DC space, but it is not the
concern of RFC1930. 

I believe that operations people are smart.  If they ignore "MUST" for
private VPN or private DC, they must deal with the problems.  If they wish
to standardize it, they'll speak up.  If operators want better knobs to
handle private AS, operators will define it. If operators define knobs for
private AS, it's a great topic to talk about in Grow or IDR. 

If they break the global Internet using private AS space, that's what
RFC1930 is for and this draft modifies.  Your stated cases match my
understanding of our original discussions on RFC1930. 

 Your reasons for deciding against rfc 6666 are interesting, I will re-read
RFC 6666.  As you've stated your reasons, I do not think the circumstances
match either the original intent of RFC1930 or the intent of the "MUST" or
"must" in the operational paragraph. 

Sue  

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Friday, December 21, 2012 6:43 AM
To: Susan Hares
Cc: 'Jon Mitchell'; [email-masked]; [email-masked]
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

On 20/12/2012 23:24, Susan Hares wrote:
> I'd be interested in you suggesting the situations would be valid to 
> leak the AS private path AS to a peer, before we downgrade to a "SHOULD".

In fact there's more to the situation.  We're dealing with operational stuff
here rather than protocol specification, i.e. human behaviour rather than
computer specifications.  I'd have no problem with throwing "MUST"
around when dealing with protocol handling, but when it gets to operational
stuff, I would be a lot more circumspect for several reasons:

- if this is specified as 2119-compatible MUST, vendors may be tempted to
hardwire an AS path prefix filter for ebgp sessions into their code in a way
which cannot be circumvented (in the same way that e.g. 169.254/16 is
hardwired and cannot be used in a bgp NLRI).  I'd see lots of value in
having a vendor default of not forwarding private ASNs, but I think this
could be quite harmful to have an absolute prohibition

In term of specific situations where this might be useful, yeah, mergers and
acquisitions would be one.  Others might include private peering between ASN
confederations.  Or interconnections between the large number of private
networks around the world, many of which use a mixture of private and public
ASNs.  Or test peerings.

Anyway, these were some of the issues that cropped up during the WG
discussion phase for rfc 6666.  We eventually decided to go with the idea of
making a recommendation that the prefix shouldn't be transferred over ebgp
sessions, and specifically made the point in the security section to
highlight it.  This avoided the issue of defining "the Internet", while
encapsulating what we wanted to say in the way that we wanted to say it.

Nick

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 21 Dec 2012 12:22:20 -0500

> seems obvious, but I don't think a poll is a fruitful exercise.

Haven't we asked if there is ever likely to be a reason for
intentionally leaking private ASNs to the "Internet?"  If it's useful
to know that information, it seems illogical not to ask if anyone is
doing it intentionally today, and if they are, why?

nLayer is doing this.  If you want to know if it's a mistake or
intentional, I'm sure they will answer.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 21 Dec 2012 17:36:05 -0500

Folks,

The extended (and epic) IDR WGLC period is completed. On the question of the range to use, there was consensus that, although various other personal favorites were discussed, 4200000000+ is good enough.

However, before we send it to the IESG we've asked GROW and SIDR to take a look too. In hindsight, we should've done those concurrently, but that's how it goes. (And actually, this does allow us to send them a document that's had the benefit of review and revision.)

I do note that a few other editorial suggestions were made during this last week. These seem to Sue and me to be things that can be handled in the editing process.

Thanks,

--John and Sue

---

From: Richard A Steenbergen <[email-masked]>
Date: Sat, 22 Dec 2012 02:53:14 -0600

> intentional, I'm sure they will answer.

I think you're confused, nLayer has never intentionally leaked private 
ASNs to the Internet. If this ever happens, it is because of the very 
limited toolset available to manipulate AS-PATHs on routers (i.e. there 
are plenty of ways that "remove-private" will fail to strip every 
private ASN).

Of course, the negative impact of leaking private ASNs to the Internet 
is pretty darn minimal, so this issue doesn't really make my list of 
things I care about.

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)