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

From: John Scudder <[email-masked]>
Date: Wed, 28 Nov 2012 16:26:03 -0500

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.

---

From: David Farmer <[email-masked]>
Date: Wed, 28 Nov 2012 16:58:39 -0600

Support

By the way, speaking of December 12; Support Sandy relief too. :)

http://www.121212concert.org/

-- 
================================================
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: Randy Bush <[email-masked]>
Date: Thu, 29 Nov 2012 08:30:18 +0900

> We have received a request for a working group last call on
> draft-ietf-idr-as-private-reservation-00.

i do not support this drafr.  do we need to repeat the previous
discussion?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Nov 2012 00:50:34 +0100

Hello Randy and all,

I admit that when we first discussed this proposal it was very unclear
what the real objective is and I admit I was also personally quite
unsure about it's value.

However after discussing it directly with Petr in Vancouver and
reading carefully his other draft (which unfortunately was posted
after this one) which was
http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-02 I do
see a very valid need to allow much bigger space for private AS block
to allow for constructing arbitrary private networks especially using
EBGP as the dynamic routing protocol.

Therefor I do support publishing this as RFC and getting IANA
allocation for the extended AS 4 octet block.

Best regards,
R.

> On Thu, Nov 29, 2012 at 12:30 AM, Randy Bush <[email-masked]> wrote:
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Nov 2012 14:07:06 +1100

> Please send comments to the list by December 14. [*]

I am opposed to this draft - increasing the size of a unordered non-unique identifier space is counter-productive.

regards,

   Geoff

---

From: Tony Li <[email-masked]>
Date: Thu, 29 Nov 2012 08:40:03 -0800

Support.

Editorial nit: I would find it MUCH more helpful if the constants were also expressed in hex.

Tony

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Nov 2012 11:49:33 -0500

> I am opposed to this draft - increasing the size of a unordered non-unique identifier space is counter-productive.

… and I support it -- some folk have a need for more than 1023 "private" ASNs and *really really* don't want to do the "just reuse the same one and then use something like the 'allows-in' and similar hacks".

Yes, going to an RIR and requesting a few thousand global ASes is possible, but to me seems inelegant.

Close to 100,000 reserved ones feels overly large to me, but it does line up nicely on a (decimal) boundary.

W

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Nov 2012 11:53:32 -0500

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Nov 2012 18:36:23 +0100

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"

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.

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.

Regards,
R.

> On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch <[email-masked]> wrote:
>
> Greetings,
>

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Nov 2012 12:50:44 -0500

Robert,

> 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?

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.

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").

> IANA and there are clear rules where the subsequent pool can be

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.

> 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

---

From: Tony Li <[email-masked]>
Date: Thu, 29 Nov 2012 10:01:35 -0800

> As an operator, I feel this is a fair thing for me to say. :)

Indeed it is.  

However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it.

Other proposals have had MUCH more environmental impact.

Tony

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Nov 2012 13:19:30 -0500

> However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it.

because private asns don't leak?
route-views>sho ip bgp regex _64..._
<snip>
   Network          Next Hop            Metric LocPrf Weight Path
*  27.123.19.0/24   195.66.232.239                         0 5459 38082 64549 ?
*  41.76.104.0/21   196.7.106.245            0             0 2905 11845 64525 i
*  41.90.0.0/16     114.31.199.1             0             0 4826 8966
33771 65535 64555 64555 33771 i
*                   194.85.40.15                           0 3267 2603
8966 33771 65535 64555 64555 33771 i
*  41.209.32.0/19   164.128.32.11                          0 3303 174
9129 9129 9129 9129 {4558,15808,64520} i
*  131.124.1.0/24   69.31.111.244            0             0 4436 4323 64778 i
*  131.124.2.0/24   69.31.111.244            0             0 4436 4323 64778 i
*  131.124.3.0/24   69.31.111.244            0             0 4436 4323 64778 i
*  131.124.4.0/24   69.31.111.244            0             0 4436 4323 64778 i
*  131.124.5.0/24   69.31.111.244            0             0 4436 4323 64778 i

(hi twtc! filter-customer-much?)

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 05:21:04 +1100

> Yes, going to an RIR and requesting a few thousand global ASes is possible, but to me seems inelegant.

???

> Close to 100,000 reserved ones feels overly large to me, but it does line up nicely on a (decimal) boundary.

But if there is a single need for 100,000 code points in single coherent space then you have to ask how one could ensure uniqueness within the deployment space, as you are now talking about a large number of entities and a large coder point space, and according to your response, the reason why there is a driving need  duplicate an existing uniqueness framework is because the current framework we have for ensuring uniqueness of AS number code points is ... "inelegant"?

Obviously I'm unconvinced by such as assertion, and remain opposed to the further progress of this document.

Geoff

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Nov 2012 13:29:42 -0500

>> Yes, going to an RIR and requesting a few thousand global ASes is possible, but to me seems inelegant.

I think the issue he raises here is that to provide uniqueness, one could ask for real ASNs, but folks may not or be unable to do this.  If they are not used on the big-I Internet, why should they come from that pool.

> But if there is a single need for 100,000 code points in single coherent space then you have to ask how one could ensure uniqueness within the deployment space, as you are now talking about a large…

I raised this issue privately with someone earlier today as well.  Collisions are likely to happen as someone will either
take the min(private_as_space) and increment, or take max() and decrement.  It's impractical to take a random number from that space, and even if so, does not prevent a collision.  If you have a need for a unique ASN to avoid this case, one should apply for one, even if used on a private network.  In arin region it seems it would be $500 one time + $100/year.  Likely around the cost of those 10G optics or the O&M on the equipment being used so easily justified.

> Obviously I'm unconvinced by such as assertion, and remain opposed to the further progress of this document.

I share this reservation and respectfully disagree with my friend Warren on this topic.

- Jared

---

From: Tony Li <[email-masked]>
Date: Thu, 29 Nov 2012 10:55:36 -0800

> But if there is a single need for 100,000 code points in single coherent space then you have to ask how one could ensure uniqueness within the deployment space, as you are now talking about a large…

Obviously, the private use ASNs would have local uniqueness and specified by the local administration.  Not a big deal.  More to the point, the noise and fluff of administering this is not something that you want foisted on the RIRs, especially when multiplied by the number of sites using it.

We've seen over and over again that the right way of creating scalability is to create hierarchy.  All this is doing is to continue its instantiation.

Tony

---

From: David Farmer <[email-masked]>
Date: Thu, 29 Nov 2012 13:10:27 -0600

> On Nov 29, 2012, at 12:36 PM, Robert Raszuk wrote:
...
> 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 v…
....

To this point, yes the RIR policies could be changed and I would support 
that.  However, the RIR's current policies are based on technical 
recommendations of this community in RFC 1930, and can be summarized as 
essentially one ASN per org and large by comparison block of shared 
Private-Use ASNs, for internal use.  Furthermore, I don't see the RIRs 
changing their policies without IDR updating its technical recommendations.

This Draft simply extends the technical direction of RFC 1930 to provide 
a larger block of Privete-Use ASNs, now that 4-byte ASNs make that 
possible.  By the way, that can't be done by the RIRs, this must be done 
by the IETF as technical allocations like this are in its domain.

However, if you are saying that the technical recommendations of RFC 
1930 are no longer valid or preferred;  And, IDR would prefer that large 
unique blocks of ASNs be handed out to organizations solely for internal 
use, then IDR should provide updated technical recommendations to that 
effect for the RIR policy community to consider.

In my view IDR either needs to do its job and expand technical 
allocation for the Private-Use ASNs or deprecate the technical 
recommendations of RFC 1930 in this regard.  Providing new 
recommendations against the use of Private ASNs all together and that 
large blocks of ASNs should be allocated and registered solely for 
internal use within organizations by the RIRs.  If IDR can't agree on 
one of those two alternatives, then IDR needs to stop extending BGP and 
develop a new protocol to handle all the new applications that are being 
bolted onto BGP.

Thanks.

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 29 Nov 2012 14:10:43 -0500

As I've stated before, mis-configuration or improper use of private use
ASNs doesn't seem to be highly correlated to the size of the range.  If
this were an issue, I guess, we would expect that a network would be
leaking close to 1K ASNs today that then would expand to many thousands
or millions after the draft is approved?

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. 

Jon

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Nov 2012 20:22:05 +0100

Chris,

So what is exactly the concern here ? The fact that folks are trying
to reserve large pool of AS numbers for their own use or that folks
are afraid that this will be used in AFI/SAFI 1/1 and/or 2/1 and will
end up visible in the Internet ?

If really the concern is the latter maybe we should try to address the
right concern (new instance of BGP and/or new SAFI) rather then
resisting the actual idea of extended AS pool reservation ?

Many thx,
R.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 29 Nov 2012 14:27:38 -0500

Sent from my iPad

>   Network          Next Hop            Metric LocPrf Weight Path

If the "private use" ASNs were NOT from a well-known range, you would detect this how?

This actually does a lot to demonstrate the usefulness of the old range, and of having a new range larger in size.

If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8 might not be as clear.
The analogy is pretty clear.

Not only is there value in more space, there is value in distinct ranges.

Having non-globally-unique space that is well known allows third parties to detect leaks, filter, and make permanent bogon filters.

In case it is not obvious:

Support (strongly).

The "first amendment" argument analogy holds: it isn't necessary to agree (or use in this case) to support the right to speak (use).

Brian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 06:55:12 +1100

> I think the issue he raises here is that to provide uniqueness, one could ask for real ASNs, but folks may not or be unable to do this.  If they are not used on the big-I Internet, why should they…

I understand that this is a restatement of Warren's point, but you raise an issue with the registries and the Internet.

I can recall the origination of the registry system - it was not only about the big-I Internet - it was about the allocation of unique code points to folk who needed to rely upon uniqueness.

I'd like to believe that the registry system still works in this way, and should continue to work in this way.

If you need uniqueness then the are registered in the global uniqueness registry - then the context of use is of no importance - you can use them in the big-I Internet - you can use them in Geoff's playland or anywhere else for that matter - they are still unique.

Creating more private use space does not address the need for uniqueness in ASN code points in my view.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 07:03:58 +1100

On 30/11/2012, at 5:55 AM, Tony Li <[email-masked]> wrote:

> Obviously, the private use ASNs would have local uniqueness and specified by the local administration.  Not a big deal.

aaahhh scoped uniqueness

I seem to recall an IPv6 scoped address concept along these lines... thats right ... site local.

"Not a big deal"?

In V6 this concept of scoped uniqueness with a local administration caused massive heartache and was dropped. Are we going to repeat this exercise again and again in different code point spaces? Or are we going to try and understand some more basic architectural considerations that are at play here that imply that the imposition of scope as a moderation of the concept of uniqueness  is often an arbitrary affair that generates way more exceptions and consequent failures than there are strictly conformant cases.

>  More to the point, the noise and fluff of administering this is not something that you want foisted on the RIRs, especially when multiplied by the number of sites using it.
> 

On the other hand, I believe that the RIR's have been foisted with that role from day one.

> We've seen over and over again that the right way of creating scalability is to create hierarchy.  All this is doing is to continue its instantiation.

I fail to appreciate this logic - creating a larger swamp space of clashing private use ASN code points hardly seems to me to be consistent with an objective of underpinning scalable uniqueness in the use of code points in networking.

And yes, I'm still opposed to the progress of this draft from WG Last Call to the IESG.

Geoff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Nov 2012 21:14:29 +0100

Hi Geoff,

So let me ask a very simple question in light of Brian's point ..

Is it better for someone privately to just pick random 100K of ASes
from 4 octet block and apply to his private needs or is it better if
such pool is well known ?

Who is going to stop Jon or Kevin or Sasha to do the former ? Internet-CIA ???

Cheers,
R.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 07:24:14 +1100

> Who is going to stop Jon or Kevin or Sasha to do the former ? Internet-CIA ???

(I love false dichotomies!)

Of course when presented with this kind of either/or argument then the
obvious answer is "neither".

If uniqueness is important then use a registry system that provides
uniqueness of assigned/allocated code points. 

If uniqueness is unimportant then use the same code point, because, well, 
uniqueness was not important was it.

Did I say already that I was opposed to the progress of this draft from
WG Last Call to the IESG? 

Geoff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Nov 2012 21:29:04 +0100

Hi Geoff,

It is not about uniqueness or not. It is about uniqueness within a
scope .. here scope being private network.

If that would not be useful we would not have 2 octet private AS range
nor RFC1918 and I think from personal experience that the last two
serve very well for what they were designed.

Cheers,
R.

> On Thu, Nov 29, 2012 at 9:24 PM, Geoff Huston <[email-masked]> wrote:
>

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 29 Nov 2012 15:32:32 -0500

> uniqueness of assigned/allocated code points. 

Uniqueness within a scope is important. Speaking of false dichotomies, you seem to be suggesting that the only way to have uniqueness is by RIR allocation. This is of course not the case, any (ahem) well-run enterprise can manage their own number resources internally.

Global uniqueness helps when you merge scopes, but that's a well-understood issue.

> uniqueness was not important was it.

Do you think we should revise RFC 1930 to withdraw the existing private AS space?

> WG Last Call to the IESG? 

You did. Duly noted. It would be fine with me to take that part as read from now on.

--John

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 07:54:26 +0900

> Global uniqueness helps when you merge scopes, but that's a well-

well-understood, mostly.  a major charlie foxtrot in many real world
mergers (business or technical).  we've seen this over and over again
in users of rfc1918 space.  and the kludges to 2547 vpns to accommodate
duplicated address space are not pleasant.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Nov 2012 23:37:54 -0500

> ASNs doesn't seem to be highly correlated to the size of the range.  If

agreed.

> not in my opinion.  Folks who have no use for more than a thousand

save the one-time (maybe) change to as-path filters, sure. (not that
that's really an issue)

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Nov 2012 23:46:27 -0500

> end up visible in the Internet ?

my original issue, which I think jon actually does capture in his
draft, is that there are exceptions in code today for 'special asn
blocks', and testing/config-options/etc that goes along with that...
Adding another 'special asn block' is piling onto an already not super
idea, and extending the need for better testing/config-management/etc.

I'm not sure the complexity is helpful. It's not clear to me that
adding more private-asn space is helpful to the larger user base of
BGP either. (should we be fixing corner cases for implementors?)

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Nov 2012 23:54:19 -0500

> If the "private use" ASNs were NOT from a well-known range, you would detect this how?

some other macro of integers perhaps?

> This actually does a lot to demonstrate the usefulness of the old range, and of having a new range larger in size.

how does it help show a larger size range would be helpful?

> The analogy is pretty clear.

expand pls.

> Not only is there value in more space, there is value in distinct ranges.

a distinct range is of value, sure. how are more ranges helpful though?

> Having non-globally-unique space that is well known allows third parties to detect leaks, filter, and make permanent bogon filters.

you mean it makes people carry crufty config for exceptions forever... sure.
it also does show some obvious routing problems to the world, or does
it? maybe it's not a routing problem but a 'forgot to
cut/paste/replace my ASN for my customer ASN' ? it's not clear at all
from the data on the wire, except that the reaction to: "I see 65535
in an as-path" is "that is bad".

if I see:
 198.41.0.0/24 as-path: 1 2 3 26415 65534

is that a leak or a missed configuration on a 26415 device? (forgot to
put remove-private-asn on the upstream neighbor to 3).

> In case it is not obvious:

mostly I'm ambivalent at this point. I'm not really in favor of adding
more complexity here, especially when there is a regular remedy: "Hi
ARIN, I need 300 asns for my next 300 deployments, all which are
scheduled to happen in the next Y days, all of which have a unique
routing policy."

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 14:55:37 +0900

> Having non-globally-unique space that is well known allows third
> parties to detect leaks, filter, and make permanent bogon filters.

boy have we not done well with that one.  large projects and large costs
to clean up 'permanent bogon filters'.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Nov 2012 09:58:30 +0100

Hello Chris,

> I'm not sure the complexity is helpful.

I am somehow puzzled on your "adding complexity to BGP implementation"
issue reg this draft.

MP-BGP extension opened a autobahn for making BGP implementations more
complex. Number of existing BGP extensions and new ones coming soon do
have huge impact to BGP implementations. Are you proposing to freeze
BGP now and not allow any new extensions ?

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.

Best,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 30 Nov 2012 10:36:35 -0500

> with things which BGP is carrying today and perhaps will carry

by all means, once the floodgates are open, why not drive the valdez
through the shoals.

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Nov 2012 07:50:37 -0800

> by all means, once the floodgates are open, why not drive the valdez

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, it's simply not represented by the SP community.  Thus, I suspect that the code will change for commercial reasons alone.  The remaining question is whether you want it standardized or not.

Tony

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 30 Nov 2012 11:07:05 -0500

On Fri, Nov 30, 2012 at 10:50 AM, Tony Li <[email-masked]> wrote:
> The remaining question is whether you want it standardized or not.

if it's to be done, it should be standardized, of course. and my vote
is but one of many... if there's enough call (consensus) then it's
fine that it proceeds.

(I believe my work-colleagues are supporters of this proposal as well,
it'd be nice for ed at least to speak up if he's listening)

-chris

---

From: Chandra Appanna <[email-masked]>
Date: Fri, 30 Nov 2012 09:34:37 -0800 (PST)

Esp since this has generated so much discussion, I figure
the chairs might want to hear from some of us who are reading
but silent so far..

Support.

Chandra.

________________________________
 From: John Scudder <[email-masked]>
To: "idr@ietf. org" <[email-masked]> 
Sent: Wednesday, November 28, 2012 1:26 PM
Subject: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
 
Folks,

Thanks,

--John

---

From: Will White <[email-masked]>
Date: Fri, 30 Nov 2012 10:41:37 -0800

Support

--Will

On Fri, Nov 30, 2012 at 9:34 AM, Chandra Appanna
<[email-masked]>wrote:

>   ------------------------------
> *From:* John Scudder <[email-masked]>
> *To:* "idr@ietf. org" <[email-masked]>
> *Sent:* Wednesday, November 28, 2012 1:26 PM
> *Subject:* [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
>
> Folks,
>
> 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
>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 30 Nov 2012 14:22:54 -0500

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.

--John

---

From: Brian Dickson <[email-masked]>
Date: Fri, 30 Nov 2012 15:15:04 -0500

> some other macro of integers perhaps?

The point I was trying to make was, with the PRIVATE range, the purpose &
intent of the ASNs in THAT range is reasonably well defined.

If a large number of ASNs are used, AND non-contiguous, whose intent is
unclear or not specified (and may or may not be "private", as in, not
intended for announcements towards the Public Internet), there is no
general way for a third party to infer the intent. In fact, generally,
intent cannot be inferred.

On the other hand, if there is a new block where the one rule is, "Do NOT
announce to the Internet", then the only inference rules are very clear.

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.

>
> >
> > This actually does a lot to demonstrate the usefulness of the old range,
> and of having a new range larger in size.
>
> > If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8might not be as clear.

A larger contiguous block means anyone USING that block can impose
structure on that block.
Since the block is private, there are no restrictions on how someone
partitioning their own instance might do so.

Structure => tool-friendly

Using tools is generally preferably to managing things manually, and if
done well, reduces the likelihood of errors that lead to non-Internet ASNs
showing up on the Internet.

E.g. a hierarchical network architecture, which incorporates such private
ASNs, e.g. pre-allocated in blocks (by continent, NFL city, router, etc.),
is much simpler to understand (inside the network doing this), and
scalable, and by having the private ASNs from a single well-known and
re-used range, enables third parties to know that the ASNs are not public
Internet ASNs.

The new range of private ASNs not only works for filters, but also various
OSS systems, e.g systems to monitor BGP announcements, which can alert when
anomalous announcement activity is seen.

>
> > Having non-globally-unique space that is well known allows third parties
> to detect leaks, filter, and make permanent bogon filters.
> >
>
It DOES NOT MATTER what the original intent was, or why you see the
questionable ASN.

What does matter, is that it does not belong, and can/should be
ignored/blocked/whatever.

The only time you SHOULD care (i.e. why it shows up), is if the ASN
immediately to the left (of the private ASN) is your own, at which point
you really should take direct action. The important thing is,  YOU will (or
at least should) have all the info you need to figure out why etc.

Without such a well-defined range, there is not always a clear relationship
between the cause and the effect, and the ideal corrective action.

However, with a pre-defined range or set of ranges, you are actually very
concise when you say, "I see 65xxx and that is bad". Nothing more is needed.

Regardless of cause, the effect is "that is bad". At which point, however
many ways there are to get rid of the bad, the correct course is, "make it
go away". As long as there _is_ a way, things are good.

Additionally,  there are plenty of mechanisms for doing ASN re-writing,
which are more general-purpose than just "remove-private-as". So, prior to
hardcoded support for new ASN blocks, the necessary mechanisms to achieve
the same functionality are ALREADY available. There is no need to tie it to
router firmware, as such. (E.g. AS rewriting for ASN migration during
merger/acquisition activity, etc.)

> scheduled to happen in the next Y days, all of which have a unique
The proposal REMOVES complexity, by removing the non-public ASNs from the
RIR-managed space.
It simplifies the logic for non-Internet ASN usage. And for managing a mix
of public and "other" usage, for an SP, managing two pools of ASNs is
pretty straightforward. Especially if one of those does not require
interaction with an RIR.

Hopefully, this clarifies the questions Chris had, as well as illustrating
some of the finer points made earlier.

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Dec 2012 09:13:09 +0900

> 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: Brian Dickson <[email-masked]>
Date: Fri, 30 Nov 2012 19:33:58 -0500

I'd like to use an example to illustrate the usefulness of a large number
of code points which are not globally unique, but where the same code point
cannot be re-used.

(The identity of the network in question isn't terribly important, but if
anyone wants to know, please contact me off-list.)

One former set-up I worked on, involved simulating the global DFZ routing
environment, including lots of BGP sessions, and the full complement of
ASNs and prefixes.

At the time, the only mechanism available was to set up the environment
using the REAL prefixes and REAL ASNs, and to very carefully ensure that
prefix filters, packet filters, and an air gap, all prevented any
unintentional leakage from this, since clearly this would have been
potentially catastrophic (to both the Internet and my career.)

Clearly, setting up N peering sessions (for very large value of N) isn't
really feasible using a single code point, or even a very small number of N
(like the current available ~1000 private ASNs).

On the other hand, having a second block of private ASNs would not only
facilitate a 1:1 correlation to "real world" ASNs in private ranges, but
also allow simulating connection and re-use of "old-range" private ASNs to
public ASNs, by replacing the public ASNs with "new-range" private ASNs.

The benefit of such a numbering scheme for ASNs would be that any leakage
of announcements would have AS4_PATH values involving only private ASNs,
allowing operators seeing these to quickly determine their non-legitimacy,
and to easily filter them (if filtering were not already being done).

And yes, this was an actual set-up involving BGP announcements with real
ASNs and real prefixes. This is not a hypothetical, white-board scenario.
(The environment even simulated packet latency and loss to the whole
Internet of destinations, needed for the product/service in question.)

Since this example only uses "vanilla" BGP, not any of the MP-BGP
"abominations", it may be a better poster child for the proposal - and I
think illustrates instances where re-use of a subset of code points would
not work (BGP loop avoidance mechanisms being what they are.)

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Dec 2012 09:58:35 +0900

> One former set-up I worked on, involved simulating the global DFZ
> routing environment

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

for real world examples, could we please stick to the real internet?

randy

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Nov 2012 17:00:44 -0800

> you will note a large number of SPs speaking against this proposal

Well, let's put it this way: 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.  Yes, there are more than one of them going this way, they are large and well-funded.  It's going to happen.

Now, again, we can block off a range of numbers, or data center folks are going to end up squatting on public ASNs.  And if that happens, we will end up being asked to implement ASN NAT, at which point we can no longer ensure global uniqueness.

<Yakov>
Can we please be practical?
</Yakov>

Tony

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Dec 2012 10:49:11 +0900

> 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.

update the draft to make these arguments, i will support it, and i
suspect other dissidents will as well.

randy

---

From: David Farmer <[email-masked]>
Date: Fri, 30 Nov 2012 22:26:26 -0600

> precisely, when it has the merger problem, it falls only on the fools

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.

> suspect other dissidents will as well.

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 that exemplify the changing BGP environment that should 
be added as well?

Thanks.