Re: [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  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 

Re: [arin-ppml] ARIN-PPML 2018-1

[Brian Jones]

On Mon, Feb 5, 2018 at 2:54 PM David R Huberman  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.
>
>
I support this proposal for the same reason given:

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

—
Brian


> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[Owen DeLong]

I will note that there is also working code widely deployed for extended 
communities which do have formats which can work for all currently issued 
32-bit ASNs.

(RFCs 4360 and 7153)

Owen

> On Feb 5, 2018, at 11:54 , David R Huberman  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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[Aaron Dudek]

We ran an international network with a single ASN using addresses from
ARIN, RIPE, and APNIC with no issues.

Aaron

On Mon, Feb 5, 2018 at 9:38 AM, William Herrin  wrote:
> On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel  wrote:
>> I need a small clarification.
>> The Caribbean region has 3 RIRs
>>
>> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE
>> If my base is arin and offer wholesale services to same geo. Region
>> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS
>> numbers?
>
> Hi Rudolph,
>
> Under ARIN rules, there is no need for separate AS numbers. I can't
> speak for RIPE or LACNIC rules, or for any rules imposed by your
> upstream network providers.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[David Farmer]

On Mon, Feb 5, 2018 at 8:11 AM, Rudolph Daniel 
wrote:

> I need a small clarification.
> The Caribbean region has 3 RIRs
>
> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE
> If my base is arin and offer wholesale services to same geo. Region
> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate
> AS numbers?
>
> rd
>

As I said previously; there are no technical or policy requirements, at
least that I'm aware of, that an ASN only routes address blocks from the
same registry.  In other words, a RIPE ASN can route ARIN IP blocks and
vice versa. So, there is no requirement for you to use more than one ASN,
at least realted to the region an islands belong too. You may have other
reasons to use diffrent ASNs, like you have no network interconnecting your
seperate networks on each island, and have a seperate upstream provider on
each island.

By the way, both the RIPE and ARIN websites say Martinique its part of the
ARIN region.

https://www.arin.net/knowledge/rirs/ARINcountries.html
https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[Sergio Rojas. . .]

Dear Rudolph,

There is not a policy in the LACNIC manual that prohibit to announce
IPv4/IPv6 ranges through ASNs allocated by other RIRs, of course the
IPv4/IPv6 received by LACNIC must be used in Trinidad.

Regards,

Sergio Rojas. . .


El 5/2/18 a las 11:38, William Herrin escribió:
> On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel  wrote:
>> I need a small clarification.
>> The Caribbean region has 3 RIRs
>>
>> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE
>> If my base is arin and offer wholesale services to same geo. Region
>> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS
>> numbers?
> Hi Rudolph,
>
> Under ARIN rules, there is no need for separate AS numbers. I can't
> speak for RIPE or LACNIC rules, or for any rules imposed by your
> upstream network providers.
>
> Regards,
> Bill Herrin
>
>
>


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[William Herrin]

On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel  wrote:
> I need a small clarification.
> The Caribbean region has 3 RIRs
>
> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE
> If my base is arin and offer wholesale services to same geo. Region
> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS
> numbers?

Hi Rudolph,

Under ARIN rules, there is no need for separate AS numbers. I can't
speak for RIPE or LACNIC rules, or for any rules imposed by your
upstream network providers.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML 2018-1

[Rudolph Daniel]

I need a small clarification.
The Caribbean region has 3 RIRs

St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE
If my base is arin and offer wholesale services to same geo. Region
countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate
AS numbers?

rd




On 3 Feb 2018 14:17,  wrote:

Send ARIN-PPML mailing list submissions to
arin-ppml@arin.net

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-requ...@arin.net



Today's Topics:

   1. Weekly posting summary for p...@arin.net (nar...@us.ibm.com)
   2. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow
  Inter-regional ASN Transfers (Aaron Dudek)
   3. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow
  Inter-regional ASN Transfers (hostmas...@uneedus.com)
   4. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow
  Inter-regional ASN Transfers (Scott Leibrand)


--

Message: 1
Date: Fri, 02 Feb 2018 00:53:02 -0500
From: nar...@us.ibm.com
To: arin-ppml@arin.net
Subject: [arin-ppml] Weekly posting summary for p...@arin.net
Message-ID: <201802020553.w125r3hv024...@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii

Total of 32 messages in the last 7 days.

script run at: Fri Feb  2 00:53:02 EST 2018

Messages   |  Bytes| Who
+--++--+
 21.88% |7 | 27.63% |   169157 | far...@umn.edu
  9.38% |3 | 12.88% |78835 | jschil...@google.com
  9.38% |3 |  7.02% |42959 | jcur...@arin.net
  6.25% |2 |  9.69% |59336 | ch...@semihuman.com
  6.25% |2 |  8.93% |54678 | o...@delong.com
  9.38% |3 |  4.96% |30392 | j...@ntt.net
  6.25% |2 |  7.37% |45115 | orobe...@bell.ca
  6.25% |2 |  4.37% |26761 | hvgeekwt...@gmail.com
  6.25% |2 |  3.81% |23298 | hostmas...@uneedus.com
  6.25% |2 |  3.06% |18719 | i...@arin.net
  3.12% |1 |  3.86% |23613 | m...@iptrading.com
  3.12% |1 |  2.52% |15439 | alison.w...@oregon.gov
  3.12% |1 |  2.27% |13881 | scottleibr...@gmail.com
  3.12% |1 |  1.64% |10023 | nar...@us.ibm.com
+--++--+
100.00% |   32 |100.00% |   612206 | Total



--

Message: 2
Date: Fri, 2 Feb 2018 13:45:49 -0500
From: Aaron Dudek 
To: David Farmer 
Cc: "Roberts, Orin" , "arin-ppml@arin.net"

Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy
ARIN-2018-1: Allow Inter-regional ASN Transfers
Message-ID: