[arin-ppml] ARIN-PPML 2018-1

[Jason Schiller]

David,

This is exactly the right question.
To what extent is there working code to support AS numbers larger than
65535,
and how costly/dfifficult is it to support them.


We examined this very question when we passed 2009-6.

The community concluded that there was really no technical reason
why the larger ASNs could not work, and the adoption of 2007-19
was to put the community on notice that they had until 12/31/2009
to sort this out (about two years from when the community supported it).

This was modified by 2009-6 to push back the action by one year.

In April of 2014, the IANA asked for advice on this policy.

It seemed there was an RIR who was out of 4-byte ASNs, but
still had so many 2-byte ASNs that they did not qualify for
additional 4-byte ASNs.

The question was if it was in the best interest to hold the two-byte
ASNs in reserve, and issue more 4-byte ASNs?  Surely the intent
was not to force them to burn through their existing 2-byte ASN holdings?

This came to a crisis during the April ARIN meeting, and the communtiy was
consulted at lenght.  The ARIN community (at that time) mostly said there
really wasn't a technical reason that made supporting the larger ASNs
problematic.  If you have a router that is less than 5 years old, just
upgrade
the code!

The result was that the RIR should burn through the two byte ASNs, and IANA
could not look the other way on two byte ASNs that were set aside.
It was also noted that RIR could manage their two byte and four byte ASNs
as they saw fit, but might need to ensure they did not set so many two-byte
ASNs aside which could prevent them from getting additional four-byte ASNs.

We also suggested that the IANA and the RIR could agree to take a fixed
amount
of their 1024 ASNs in two-byte, but if they did reach such an agreement,
that it
should be transparent.

How are things different now?

Where does the community currently stand on the question of
how costly/dfifficult is it to support ASNs larger than 65535?

-------------------------------

my take:

I initially came at this from the same perspective the community had in
2009.  This is just s simple software fix.  Everyone agrees that there is no
technical reason preventing the support of big ASNs.  Anyone running
BGP (or about to run BGP) surely has equipment that is current enough
to run current code that supports big communities.

But in discussions, some have pointed out, to not allow ASN transfers,
supports the encumbants, and is a barrier to entry for a smaller ISP
who has a four byte ASN.  This transit provider may have a down stream
customer with older hardware that cannot run code that suppots big
communities.  As a result, their down stream customer (with old gear)
cannot participate in BGP TE as they cannot encode their upstream ISP's
four-byte ASN into a big BGP community.

Secondary to this, the same four-byte ASN using transit provider may want
to purchase transit (or Peer) with a network that supports only two
byte-ASN, and
will not be able to BGP peer.

I'm not sure how big a problem this is, and how costly / dfifficult is it
to support
big BGP communities in this space.    My support or oppision to this
proposal
hinges on hearing answers to this question from those in the space descibed.


___Jason



On Mon, Feb 5, 2018 at 2:54 PM, David R Huberman <daveid at panix.com> wrote:

>
> If I may, I'd like to try and re-focus the discussion of 2018-1 on the
> network engineering problem that prompted this draft proposal. The solution
> this draft policy proposal offers to the problem is where I think the real
> value is, and where I think PPML needs to focus.
>
> Since the publication of RFC1997 in the 1996, network engineers have
> utilized an extension of BGP called the BGP communities attribute to
> enginer traffic (to "shape traffic") in a desirable way.
>
> RFC1997 only supports the use of 2-byte ASNs.  As the free pool of 2-byte
> ASNs began to shrink, a solultion was needed to enable networks labelled
> with 4-byte ASNs to utilize BGP community attributes.
>
> In 2010, a draft of Flexible Community attribute was discussed, but no
> working code was widely released. In 2016, a draft of Wide Comunity
> attributes was released, but also resulted in no working code.  Finally, in
> February 2017, RFC8092 was published, and Large BGP Communities became the
> protocol standard for defining 4-byte AS numbers within the BGP community
> attribute.
>
> Working code exists for some equipment and software, is planned for other
> equipment and software, but the point is that RFC8092-compliant code is not
> prevelant in the DFZ.  This is important because it means a network
> operator who wants to shape their traffic properly with BGP communities
> still needs a 2-byte ASN or it won't work.
>
> This proposal addresses the problem by allowing registrants of an unused
> or unwanted 2-byte ASN to transfer the registration to a network operator
> who needs one, all within the existing and community agreed-upon framework
> of Inter-RIR transfers.
>
> For this reason, I support draft policy proposal ARIN-2008-1.
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180216/562d1770/attachment.htm>