Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

[Ben Maddison <[e-mail]>]

Hi all,

Thanks for all the contributions so far.

I'd like to echo the support for this proposal already voiced.
We operate a transit network, and define multiple informational and action communities for signaling policy to/from our customers and peers.
As it stands, the primary shortcoming in this scheme is our inability to indicate scope of a 4B ASN. This proposal fixes that simply and elegantly, and does not break any elements of our existing deployment.

It is trivial to map our current community namespace into a new enlarged namespace, thus providing a migration path that can remain in a transitional state for as long as necessary.
I would point out that this operational simplicity derives from the fact that the handling of the proposed attribute is the same as the current std. community attribute in every respect other than length - in particular transitivity. Without this, one cannot use both short and long communities to express a single policy during transition.

As others have pointed out, the same issue is felt acutely by holders of 4B ASN and by route server operators.
In the Afrinic numbers region, the community has even resorted to what can only be described as a "resource policy hack" [1] that reserves the remaining pool of 2B ASNs for allocation to IXP RS operators, so that they can define per-peer policy communities. Even this measure of course does not help where IXP participants have 4B ASNs.
Fixing operational problems with Internet standards is clearly not the proper role of resource policy, and highlights the brokenness of the status quo, whereby we are unable to agree on a reasonable protocol based solution to an immediate protocol related problem.
I have copied the authors of that policy, all of whom operate IXPs in our region, in case they would like to add their thoughts. 

[1] http://afrinic.net/en/library/policies/1423-afpub-2014-gen-004-draft-03 

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     [phone]
Mobile:   [phone]
Email:      [e-mail]
SIP:          [e-mail]



-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Joe Provo
Sent: Monday, September 19, 2016 10:39 PM
To: [e-mail]
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)


TL;DR - forward motion on -large would prevent making networks deploying 32b today ASNs as second-class citizens^Wcarriers of the global Internet.


On Thu, Sep 15, 2016 at 02:03:06PM -0400, Christopher Morrow wrote:
> (shortcut; I'd like to see -large get finished, some reasoning below)
> 
> On Thu, Sep 15, 2016 at 12:56 PM, Randy Bush <[e-mail]> wrote:
> 
> > is
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                      Autonomous System number                 |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                          Local Data Part 1                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                          Local Data Part 2                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > sufficient?  that is a binary question.  i am interested in answers 
> > from operators such as nick, gert, ...
> >
> > iff your answer is "no," what would be sufficient?
> >
> 
> I'll bite... So, it seems to me that a minimum answer for 
> compatibility going forward is 4:4, it also seems that if we're adding 
> more bits to this,
> 4:8 is attractive for some of the use-cases Jared brings up above.
> 
> The -large option seems like a good step to bring parity to 
> tooling/etc that we use today in the network.
[snip]

What my colleague says regarding parity is critical. We may not *like* the existing tools, approaches, or configuration management (and many parties are seeking to correct this), but the operations end of the Internet requires forward progress with the least friction. A more thorough rethinking of communicating routing policies is a laudable goal, but that's not something we'll see in the near-term.

As Nick observed, the well of 16b ASNs is dry at the source. When the RIRs are unable to fulfill requests, we'll see operators of 32b ASNs forced to abandon best current practices in policy signaling (the danger of overloading private-ASN signaling and making stripping errors or re-writes have already been raised) or find some means of obtaining 16b ASNs.  Flatly, any such with BGP downstreams will be forced to have substandard offerings to their customers and the collective we are affecting their business offering.

Many of the relevant points have been touched on by others, most notably the common framework indicated by Martijn. In a comment, Jared pointed to the elegance of "<actor>:<target>:<action>" signals.
I would take that a step further to say empowering that simplicity would increase stability of the Internet. In Martijn's excellent policy framework summary, one of the footnote-referred websites might not be familiar to non-operators: https://onestep.net/communities/ This site is a compilation of various provider community lists, not always published to non-customers, and a fairly important reference for those crafting announcements or diagnosing what happened to a prefix or traffic. If you pick a few at random, you'll note that any which are providing action (and not just documenting origin) need to define their own format and action look-up table. Human touching/configuring devices are known to be the root of most inter-provider turbulence; humans have been known to set the policy matching provider A's LUT on provider B's session, sometimes with bad results. Setting the stage to reduce complexity in this realm by providing the bitspace for a simple, uniform "<actor>:<target>:<action>" signal would increase stability as it was adopted.

The need is real and imminent. There are multiple implementations of the proposal. A chorus of people facing these issues on a daily basis support the proposal.  Let us please move forward.

Cheers!

Joe


-- 
        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr