Subject: [Idr] 16bit ASN exhaustion

From: Nick Hilliard <[email-masked]>
Date: Mon, 23 Sep 2013 14:12:45 +0100

Looks like IANA handed out the last chunk of unallocated 16 bit ASNs:

http://www.iana.org/assignments/as-numbers/as-numbers.xhtml

Does IDR have recommendations for how to handle BGP community support in a
32 bit environment?

Nick

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 23 Sep 2013 08:14:25 -0400

> Does IDR have recommendations for how to handle BGP community support in a

Above and beyond RFC6793 Section 5?

-Jon

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 23 Sep 2013 15:25:46 +0100

> Above and beyond RFC6793 Section 5?

I probably should have been more specific. Until 4byte asns came along we
could do stuff like encoding other ASNs in the local administrator field.
There are some well known examples of this, e.g.

http://onesc.net/communities/as8714/
http://onesc.net/communities/as6695/

But more generally, this is a very useful feature on transit networks which
has effectively disappeared if you're using ASN4s.

draft-raszuk-wide-bgp-communities would have fixed this, although the
implementation details looked pretty messy and I'm not sure that it was a
good approach to take as a long term fix for the problem.

As operators, we need 32-bit:32-bit communities, not just 32:16.  Whatever
about the implementation issues, Robert's wide-communities draft looked
like it would solve a pile of problems.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 16:56:41 +0200

Hi Nick,

Just an update on draft-raszuk-wide-bgp-communities ..

In Berlin all involved folks have met and I think we clarified the
issues which were holding it.

Basically while we have tried to made it more flexible then the
original idea it quickly became to complex from number of aspects
including operation. So we revered back to predefined wide communities
rather then spending more time on putting algebra language into them.

That means that hopefully soon (one of the co-authors has the src at
this point) - maybe before YVR we will have a proposed draft out.

So stay tuned .. the work is not abandoned.

Cheers,
R.

On Mon, Sep 23, 2013 at 4:25 PM, Nick Hilliard <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2013 14:50:44 -0400

Nick,

> good approach to take as a long term fix for the problem.

http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06
is more intended to solve the "4byte AS equivalent community" problem.  Wide
communities is biting off more of the general community problem.

> like it would solve a pile of problems.

That's one thing that could be done in wide comms, but seems overkill.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2013 14:51:57 -0400

> this point) - maybe before YVR we will have a proposed draft out.

And as that individual, I'm working through my work queue for IETF and
finally making progress.  Hopefully we'll see that in the next week or so.

-- Jeff (who has been traveling for 3.5 of the last 6 weeks and is a bad
road warrior)

---

From: Jared Mauch <[email-masked]>
Date: Mon, 23 Sep 2013 14:58:25 -0400

> That's one thing that could be done in wide comms, but seems overkill.

I'll chime in saying based on general usage u32:u32 is what the BGP using end-users will expect.

- Jared

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 23 Sep 2013 20:07:23 +0100

Yes .. I am still wondering why it is still not available but I am sure that reading the archive of the list will enlighten me ....

Thomas

Sent from my iPad

> On 23 Sep 2013, at 19:58, Jared Mauch <[email-masked]> wrote:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 23 Sep 2013 15:26:43 -0400

> I'll chime in saying based on general usage u32:u32 is what the BGP using end-users will expect.

Wide comms can accommodate it.  Just seemed overkill to expand the number
space.

Ah well, another use case to add - perhaps to the base spec.

-- Jeff

---

From: Arturo Servin <[email-masked]>
Date: Tue, 24 Sep 2013 09:34:56 -0300

Do not believe my word (ask IANA) but I though that there where still
some ASNs to allocate to RIRs from this last chunk:

64000-64495	Reserved by the IANA

	Anyway, it may be irrelevant because they may go away in any moment.

Regards,
as

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 24 Sep 2013 13:44:16 +0100

> 	Anyway, it may be irrelevant because they may go away in any moment.

those are reserved rather than unallocated.  By comparison, the available
ASN32 ranges are marked as "unallocated".

Nick

---

From: Arturo Servin <[email-masked]>
Date: Tue, 24 Sep 2013 10:00:42 -0300

Yes, I know.

	But check this archived version of the IANA registry:

http://web.archive.org/web/20111020211749/http://www.iana.org/assignments/as-numbers/as-numbers.xml

	Note that ASNs that are marked as "Reserved" are now allocated. As I
said, ask IANA for clarification but my impression is that those are
reserved for allocation and not for any other use.

Regards,
as

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 24 Sep 2013 14:25:06 +0000

> reserved for allocation and not for any other use.

IANA can only allocate blocks of 1024. So, the space is technically depleted

Policy Ref: https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm

Roque

---

From: Arturo Servin <[email-masked]>
Date: Wed, 25 Sep 2013 12:32:54 -0300

It says "IANA allocates ASNs to RIRs in blocks of 1024 ASNs" Those
could be 1 ASN of 2 bytes and 1023 ASNs of 4 bytes.

	They do not do that extreme case, but just check how many 16 bits ASNs
were given to APNIC (it was half block of 1024).

	Also, in NANOG, IANA clarifies that they still have ASNs to allocate.

http://mailman.nanog.org/pipermail/nanog/2013-September/061191.html

/as