Subject: [Idr] AS numbers - flat vs hierarchical

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Dec 2012 00:17:35 +0100

I think that this thread reg private AS range extension has
demonstrated the real problem with the current AS definition.

Let me post a very simple question ... Why current AS numbers are flat ?

I think all current issues would be solved if we would define and
provide two level AS numbers "AS-PUBLIC.AS-PRIVATE" which btw was
perhaps a bit indirectly  expressed in the other email I have sent
except it called to look at the tuples of private and public AS.

Perhaps it's time we revisit the AS_PATH attributes (two and four
octets) and allow for required flexibility by defining new
FLEX_AS_PATH attribute other then keep fighting on point issues today
and in the future...

Best,
R.

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Dec 2012 15:23:32 -0800

> Let me post a very simple question ... Why current AS numbers are flat ?

Because as of the time that Yakov and Kirk started the protocol, that was the 'obvious' approach.  Remember that they ended up creating the AS number space in its entirety.

As we have seen in practice, we allocate them hierarchically, first through the RIRs, and now private numbers within the domain.

The generalization should be obvious to all.

But the horse has long since left the barn.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Dec 2012 00:33:24 +0100

> The generalization should be obvious to all.

Well ... I think while are frequencies may match we may be out of
orbit for others ;)

> But the horse has long since left the barn.

Likewise BGP was not MP at the stable. Then even Yakov took a step
back and asked Ravi to implement MP.

Maybe we need to make BGP AS_PATH fit the needs of today ?

Yes it is very unfortunate that our close friends where spend time to
define 4 octet AS just before .. but as it seems this does not help
the real world.

So anyone willing to fix the the main problem other then to work on
the patches ???

r.

> On Thu, Dec 13, 2012 at 12:23 AM, Tony Li <[email-masked]> wrote:
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 13 Dec 2012 00:10:42 +0000

It seems reasonable to expand BGP ASN to something like what IPv6 has --
in the name of GUA and ULA [RFC4193]
 
Cheers.

Rajiv

PS: Perhaps, Reserve one bit in 4 octet space to mean Private ASN,
perhaps, and keep the same 4-octet length for private ASN.

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, December 12, 2012 6:33 PM
To: Tony Li <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] AS numbers - flat vs hierarchical

>> Because as of the time that Yakov and Kirk started the protocol, that
>>was the 'obvious' approach.  Remember that they ended up creating the AS
>>number space in its entirety.
>>
>> As we have seen in practice, we allocate them hierarchically, first
>>through the RIRs, and now private numbers within the domain.
>>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Dec 2012 01:23:12 +0100

Hi Rajiv,

> perhaps, and keep the same 4-octet length for private ASN.

Well this was exactly as I suggested yesterday .. but I think only
you have acked on it :)

After second thought I think (and TLI states it as obvious) long term
we need much more hierarchical AS_PATH where the real AS will have a
freedom to assign subordinates ,,,

r,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Dec 2012 10:15:43 +0000

> freedom to assign subordinates ,,,

Forgive my ignorance, but I don't what you're getting at here.  Can you
explain?  ASN deployment has always been piecemeal, and ASNs bitfields have
never been part of any routing discrimination mechanism.  Are you proposing
to change this, and if so, why?

Nick

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 13 Dec 2012 13:40:31 +0000

I am just falling into the discussion here. 

Would hierarchical ASN's maybe aid with the operation of confederations and making it simpler to deploy instead of using the private ASN space?
(I am thinking out loud here)

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: 13 December 2012 11:16
To: Robert Raszuk
Cc: idr wg
Subject: Re: [Idr] AS numbers - flat vs hierarchical

> freedom to assign subordinates ,,,

Forgive my ignorance, but I don't what you're getting at here.  Can you explain?  ASN deployment has always been piecemeal, and ASNs bitfields have never been part of any routing discrimination mechanism.  Are you proposing to change this, and if so, why?

Nick

---

From: Will White <[email-masked]>
Date: Thu, 13 Dec 2012 06:55:58 -0800

The general idea they seem to be working on here is to allow a single ASN
public allocation to have Y number of private ASN assigned to it.  So if
FOO company was assigned FOO ASN.  Then X company could use FOO.Y for
private internal ASNs.  Y could be a predefined bit length allowing all
companies to have a predefined set of private ASNs per public ASN.

This is of course just one method of doing that.  The general concept they
are looking at is a way to give companies private ASNs without running into
the problem of ASN duplication when buying a company or some other business
to business need.  This would allow companies to do things with BGP in the
datacenter with having less worry of running out of numbers or accidentally
announcing to the internet.

Additionally the hierarchical concept could also be expanded to allow for
something like transit and non-transit ASNs to help reduce the
re-announcement of google's or facebook's blocks by making a transit
provider register for a transit ASN rather than giving every fresh company
a transitable ASN.

Just a couple thoughts.

Will

On Thu, Dec 13, 2012 at 5:40 AM, Gunter Van de Velde (gvandeve) <
[email-masked]> wrote:

> Would hierarchical ASN's maybe aid with the operation of confederations
> and making it simpler to deploy instead of using the private ASN space?

---

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

> to change this, and if so, why?

I'm glad the conversion came back around to this, I've been thinking 
about a straw-man for ASN hierarchy ever since TLI brought the issue up 
a couple weeks ago.

Here is my straw-man for ASN hierarchy;

Create a new BGP atribute, call it ASN-Partition or something like that. 
  It would have to be transitive, but local significance within an ASN. 
  It would contain an 4-byte ASN and ANS-Partition identifier, maybe 
implement it as a extended community.

But, then modify the loop detection algorithm, if a loop is found in the 
AS-Path attribute using the classic algorithm, further check if there is 
an ASN and ASN-Partition tuple for your ASN-Partition, and only then 
treat as a loop, otherwise don't.

Also ASN-Partition would have to be part of neighbor negotiation.  Using 
eBGP rules between neighbors of different ASN-Partitions within the same 
ASN, and iBGP rules between neighbors of the same ASN-Partition.

This would need a lot more work and thinking through, I'm not sure it 
doesn't encourage excessive attribute bloat, or that its not just 
another version of confederations, or something, and the code 
implementation is a lot more complicated than adding an additional 
4-byte private ASN range.

However, there could be several use cases, the obvious ones of BGP-VPNs 
and the Data Center stuff being talked about.  But, there could be some 
interesting big-I use cases too, that people use the "allow-in" and 
other hacks to implement now.  Basically we could create a much less 
hackish way of bypassing normal loop detection.

At least that is my idea.

-- 
================================================
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: Jeff Wheeler <[email-masked]>
Date: Thu, 13 Dec 2012 12:57:18 -0500

On Thu, Dec 13, 2012 at 11:43 AM, David Farmer <[email-masked]> wrote:
> AS-Path attribute using the classic algorithm, further check if there is an
> ASN and ASN-Partition tuple for your ASN-Partition, and only then treat as a
> loop, otherwise don't.

I read your post a few times but I do not understand.  Could you give
an example?

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

---

From: Tony Li <[email-masked]>
Date: Thu, 13 Dec 2012 10:08:31 -0800

> I read your post a few times but I do not understand.  Could you give

I'm not convinced that this is necessary.  While hierarchy for allocation and assignment seems useful, why not retain a flat approach for loop detection?

Tony

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Dec 2012 14:26:51 -0600

> I'm not convinced that this is necessary.  While hierarchy for allocation and assignment seems useful, why not retain a flat approach for loop detection?

Because this approach allows a discontinuous AS to appear as a single AS to the outside world and even its L3VPN providers.  Example, all of the sites of an enterprise could use the same public ASN and each use a separate AS-Partition identifier. Peering with one or more L3VPN provider backbones and even getting Internet connectivity locally at a site from there L3VPN provider or separate ISP if they wish.  This approach allows for arbitrarily complicated topologies that happen when you select from multiple L3VPN providers or ISPs simultaneously per site based on multiple competitive factors and/or redundancy needs for each site.  And, I believe you wouldn't need to resort to the Allow-In or Remove-Private-AS hacks.  Basically this allows an ASN to be discontinuous between between AS-Partitions but not within a partition.

Yes, that violates the classic view of an ASN, but that classic view is an out dated anachronism with a lot of the new uses for BGP are taken into account.  And, we are using hacks like Allow-In or Remove-Private-AS hacks to make strange groups of BGP clouds look like they are classic ASNs.  Lets just admit there are new kinds of critters in the zoo today.

Hope that helps, but like I said this is a straw-man and I'm not sure he has all his arms and legs yet. :)

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

---

From: Allan Eising <[email-masked]>
Date: Thu, 13 Dec 2012 23:54:02 +0100

I must admit I fail to see the benefit of this.
I like to see an AS as identifying a common routing policy. While you may
have internal private systems, customers and networks that have individual
policies, your external policy, the one regarding the on the internet
visible ASN is still a common one. I cannot help but feel that trying to
communicate internal structures on the internet overcomplicates things, and
furthermore tries to communicate information that is not meant to be
relayed through BGP. When it comes to routing policy and specifically
filtering I fail to see the benefit of this increased complexity.

Maybe you could clarify your proposal with a few examples?

/Allan Eising

On Thu, Dec 13, 2012 at 9:26 PM, David Farmer <[email-masked]> wrote:

> > I'm not convinced that this is necessary.  While hierarchy for
> allocation and assignment seems useful, why not retain a flat approach for
> loop detection?
> >
> > Tony
>
> Because this approach allows a discontinuous AS to appear as a single AS
> to the outside world and even its L3VPN providers.  Example, all of the
> sites of an enterprise could use the same public ASN and each use a
> separate AS-Partition identifier. Peering with one or more L3VPN provider
> backbones and even getting Internet connectivity locally at a site from
> there L3VPN provider or separate ISP if they wish.  This approach allows
> for arbitrarily complicated topologies that happen when you select from
> multiple L3VPN providers or ISPs simultaneously per site based on multiple
> competitive factors and/or redundancy needs for each site.  And, I believe
> you wouldn't need to resort to the Allow-In or Remove-Private-AS hacks.
>  Basically this allows an ASN to be discontinuous between between
> AS-Partitions but not within a partition.
>
> Yes, that violates the classic view of an ASN, but that classic view is an
> out dated anachronism with a lot of the new uses for BGP are taken into
> account.  And, we are using hacks like Allow-In or Remove-Private-AS hacks
> to make strange groups of BGP clouds look like they are classic ASNs.  Lets
> just admit there are new kinds of critters in the zoo today.
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Dec 2012 23:56:21 +0000

On 13/12/2012 22:54, Allan Eising wrote:
> When it comes to routing policy and specifically filtering I fail to see
> the benefit of this increased complexity.

the proposal also omits the concept of an ASN mask, so I'm guessing it's
heading down the direction of classful ASN assignment and we know what a
bad idea that is.

Or maybe someone wants to suggest an ASN assignment mask?

But I think at this stage, reductio ad absurdum has been achieved on this
particular suggestion.  AS usage is flat and always has been.  Changing
this would be virtually impossible.

Now, can we divert out of this rathole and head back to
as-private-reservation again?

Nick

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 13 Dec 2012 19:22:03 -0500

> Because this approach allows a discontinuous AS to appear as a single AS

I still don't get how you imagine implementing this.  Would really like to
see an example.

The trouble I imagine is, if you need to identify which ASNs in the AS_PATH
belong to a given Administrative Domain, it sounds like you propose a new
Attribute for this.  How will a receiver supporting this capability
determine which AS_PATH elements match up with which AD identifier, given
that the AS_PATH is being modified en-route by BGP speakers who are not yet
aware of this capability?  Will the AD identifier count from the end of the
AS_PATH (the originating ASN) and define a range?  For example:

4474 16631 65000 65001 6461 65000 1239

+----------------+---------------+----------------+----------------+
| flags          | type          | length = 12    | AD <asn32>
+----------------+---------------+----------------+----------------+
  ..AD<asn32> cont'd   VALUE=6461                 | offseta = 1    |
+----------------+---------------+----------------+----------------+
| span = 1       | AD <asn32> VALUE=16631
+----------------+---------------+----------------+----------------+
                 | offseta = 3   | span = 2       |
+----------------+--------------------------------+

Above is how I imagine your idea.  Every time you need to add one of your
Administrative-Domain-specific spans of ASns into the AS_PATH you need to
basically push an entry onto this attribute which identifies the
globally-unique Administrative Domain (by global ASN) and the offset of
that span, from the right of the AS_PATH, as well as the span size (number
of ASNs there which are private.)

Problem is if someone in the middle, say a DFZ router, strips out what it
sees as a "private ASN" then your offsets are all screwed up.  I don't
imagine this can be assured of not happening because some uninformed router
might do almost anything to the path,  Maybe you need bounds like "between
ASN 1239 and AS 6461" instead?

4474 16631 65000 65001 6461 65000 1239

+----------------+---------------+----------------+----------------+
| flags          | type          | length = 16    | RESERVED       |
+----------------+---------------+----------------+----------------+
| private_right=1239                                               |
+----------------+---------------+----------------+----------------+
| private_left=6461                                                |
+----------------+---------------+----------------+----------------+
                                ...
| private_right=6461                                               |
+----------------+---------------+----------------+----------------+
| private_left=16631                                               |
+----------------+---------------+----------------+----------------+

The above encoding gets rid of that problem I suppose, so you just scan the
AS_PATH from the right and it will give you the bounds of each group of
private ASNs.  It assumes the left-most ASN in each bounding-pair
identifies the Administrative Domain by its 4-octet ASN.  You could add
more attributes for that if you didn't want them to be tied to ASN but that
seems like a logical place to start.

I don't know if this is exactly your idea.

I'm not advocating this concept or the above encoding, either.  I think you
are suggesting something that is unlikely to be implemented.  But this is
the way I could imagine it working, and it isn't really that HARD to
implement it.

Please note the RESERVED field above is just for formatting in the email.
 You can't guarantee a BGP attribute of arbitrary length has its values
aligned without adding, or not, a reserved field based on the attribute
length, because of the optional Extended Length bit in the attribute flags.