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

From: Susan Hares <[email-masked]>
Date: Mon, 19 Sep 2016 17:21:45 -0400

RandyJohn and I are listening to the frustration in operators.  
Have you exchanged email with Jeff and Jared on their desire for a common header with 1 extra byte to allow policy to track at community level?  I just want to be sure that this switch is frustration + informed consent.

Sue
Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------From: Randy Bush <[email-masked]> Date: 9/18/16  12:25 PM  (GMT-05:00) To: Sander Steffann <[email-masked]> Cc: Interminable Discussion Room <[email-masked]> Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community -
  Working Group Adoption call (9/6 to 9/20) 
>> can we please focus on the content and let the process go to the cloud,
>> where process is processed?
>> 
>> 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, ...
> 
> Yep, that seems to do just fine. I like the simplicity.

while operators keep saying this, it is utterly uncreative and shows
zero cleverness.  how do professional ietf standards makers turn this
into resume enhancing material?

randy

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Sep 2016 00:38:57 +0200

Dear Sue,

Let me just point out to everyone that when we have been discussing
proposal of 32:32:32 and while everyone is in complete agreement for the
above as described in large-community draft the questioned common header is
only one option to leave room for future extensible solution even if for
now we would just stay with use case of simple 32:32:32.

That is simply standardize communities of the format 32:32:TLV where only
mandatory TLV today would be say type 1 == 32.

IMHO overhead of 3 octets (1 octet for TLV type and 2 for TLV length) is
negligible as compared with future potential of adding more structures to
last part of the community as seems fit by IETF WG consensus.

Best regards,
Robert Raszuk

PS. The above is fully compatible with current -large-communities draft and
I think there is already a proposed text for it.

On Mon, Sep 19, 2016 at 11:21 PM, Susan Hares <[email-masked]> wrote:

>
> Randy
> John and I are listening to the frustration in operators.
>
> Have you exchanged email with Jeff and Jared on their desire for a common
> header with 1 extra byte to allow policy to track at community level?  I
> just want to be sure that this switch is frustration + informed consent.
>
>
> Sue
>
> -------- Original message --------
> From: Randy Bush <[email-masked]>
> Date: 9/18/16 12:25 PM (GMT-05:00)
> To: Sander Steffann <[email-masked]>
> Cc: Interminable Discussion Room <[email-masked]>
> Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community -

---

From: Ben Maddison <[email-masked]>
Date: Tue, 20 Sep 2016 00:38:38 +0000

Hi Robert,

I would not support the proposed modification.
The problem that this proposal seeks to address is specifically that the possible range of RFC1997 community values is too small to accommodate the range of semantics that they are intended to communicate. More specifically, it is a common practice amongst operators to express the significance and scope of policy in terms of ASN values, and to map those ASN values into the community values signaling that policy.
By increasing the ASN range without simultaneously increasing the community value range, we broke that mapping. In my opinion, and judging from the views expressed here on this subject, this is the **only** respect in which the current mechanism is broken.
I would personally prefer not to add to the complexity of a solution to a real current problem, in order to fix a hypothetical future problem that no operators seem to be anticipating or remotely concerned about.
All that said, if there are operators out there with real-life use cases requiring a more complex variable-length (of > 12 octets) encoding, then please speak out, and I shall happily eat my words.

Best regards,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:      [email-masked]<mailto:[email-masked]>
SIP:          [email-masked]<sip:[email-masked]>

[Workonline Communications]<http://www.workonline.co.za/>

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 20, 2016 1:39 AM
To: Susan Hares <[email-masked]>
Cc: Interminable Discussion Room <[email-masked]>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

Dear Sue,

Let me just point out to everyone that when we have been discussing proposal of 32:32:32 and while everyone is in complete agreement for the above as described in large-community draft the questioned common header is only one option to leave room for future extensible solution even if for now we would just stay with use case of simple 32:32:32.

That is simply standardize communities of the format 32:32:TLV where only mandatory TLV today would be say type 1 == 32.

IMHO overhead of 3 octets (1 octet for TLV type and 2 for TLV length) is negligible as compared with future potential of adding more structures to last part of the community as seems fit by IETF WG consensus.

Best regards,
Robert Raszuk

PS. The above is fully compatible with current -large-communities draft and I think there is already a proposed text for it.

On Mon, Sep 19, 2016 at 11:21 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Randy

Sue

-------- Original message --------
From: Randy Bush <[email-masked]<mailto:[email-masked]>>
Date: 9/18/16 12:25 PM (GMT-05:00)
To: Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: Interminable Discussion Room <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

randy

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Tue, 20 Sep 2016 09:44:20 +0200

Hi,

> mandatory TLV today would be say type 1 == 32.

Please no.  No TLVs.  *Simple*.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Sander Steffann <[email-masked]>
Date: Tue, 20 Sep 2016 14:08:29 +0200

Hi Robert,

> IMHO overhead of 3 octets (1 octet for TLV type and 2 for TLV length) is negligible as compared with future potential of adding more structures to last part of the community as seems fit by IETF WG…

It's not the extra octets that I'm worried about, it's the extra complexity in the code and user interface that the extra possible permutations of representation would require.

A simple example: how to encode communities 111111:222222:1234 and 111111:222222:2345? With large the only way would be:

 0                   1                   2                   3
|                               111111                          |
|                               222222                          |
|                                1234                           |
|                               111111                          |
|                               222222                          |
|                                2345                           |

On a Cisco box you would probably be able to set this with something like:

route-map TEST permit 10
 set large-community 111111:222222:1234 111111:222222:2345

Simple.

Now introduce TLVs, how do we encode this?

 0                   1                   2                   3
|                               111111                          |
|                               222222                          |
|    type=1     |           length=4            | ⏎
|                                1234                           |
|                               111111                          |
|                               222222                          |
|    type=1     |           length=4            | ⏎
|                                2345                           |

or maybe

 0                   1                   2                   3
|                               111111                          |
|                               222222                          |
|    type=1     |           length=8            | ⏎
|                                1234                           |
|                                2345                           |

How would the user interface for this work? Maybe:

route-map TEST permit 10
 set tlv-community 111111:222222 type 1 value 1234 111111:222222 type 1 value 2345

vs

route-map TEST permit 10
 set tlv-community 111111:222222 type 1 values 1234, 2345

And I'm not even talking about how to filter them yet...

Adding a seemingly simple extension adds an exponential level of complexity in both code and user interface. I understand that from a flexibility point of view it seems no big deal, but I really really understand all the people objecting to this.  I personally agree with them: it is a big deal.

Lt's stick to the KISS principle and make it easy to implement and easy to use.

Cheers,
Sander

---

From: Joe Provo <[email-masked]>
Date: Tue, 20 Sep 2016 08:29:15 -0400

On Tue, Sep 20, 2016 at 02:08:29PM +0200, Sander Steffann wrote:
[snip]
>  set large-community 111111:222222:1234 111111:222222:2345

...and a simple, obvious extenion of what people do today.

[snip]
> Adding a seemingly simple extension adds an exponential level of
> complexity in both code and user interface. I understand that from
> a flexibility point of view it seems no big deal, but I really
> really understand all the people objecting to this.  I personally
> agree with them: it is a big deal.
[snip]

WRT my 'objections', I'll join Mr Morrow on the bench of "why not 
both?"  I understand Jeff's concern regarding a proliferation of 
alternates, and to that end we should push the common header & TLV 
format to be implemented before there's the next ASN size bump and
time for operators to adjust. 

But the burning need addressed by -large has multiple implementations,
is a logical (invisible to users) extension of current practice, and
has a proposal in front of the WG.

Cheers!

Joe

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

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 20 Sep 2016 16:00:56 +0100

Hi Sander,

> A simple example: how to encode communities 111111:222222:1234 and 111111:222222:2345? With large the only way would be:

There are two separate aspects on user interface representation and 
encoding on the wire here. User interface needs to hide any and all 
types and present a single uniform way in a format of 
111111:222222:1234. Whether a common context container is present or not 
that is implementation and wire encoding aspect, and operationally it is 
not that much important. However the user interface representation needs 
to be stable and unambiguous - no types, no TLVs, exactly as RFC1997 
standard communities only with wider fields. Types and subtypes are a 
domain for extended communities and eventual their extension to 
accommodate AS4:AS4 semantics - as extended communities do have inherent 
typing, types and TLVs fit there naturally, and an equivalent mechanism 
is needed for their widened extension.

The benefit of a common container header to save a few bytes on the wire 
is rather weak one - at least 5 large communities would be needed to see 
any benefit, while implementation aspects of efficient update packing 
would result in far bigger savings. Filtering all path attributes via 
single type instead of having separate filters for each specific path 
attribute of extended, large, wide, and extended-AS4 again seems to fall 
more into the domain of implementation specifics and less so into policy 
expression possibilities and operational complexity. Different types of 
communities are handled differently today so no major change.

Ignas

---

From: t.petch <[email-masked]>
Date: Tue, 20 Sep 2016 16:50:49 +0100

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Susan Hares" <[email-masked]>
Cc: "Interminable Discussion Room" <[email-masked]>
Sent: Monday, September 19, 2016 11:38 PM

> now we would just stay with use case of simple 32:32:32.

Yes, it does seem clear that this is the only option to provide for
future enhancements,

It is also clear that the history of protocol development is that there
is always a need for future enhancements, it is just a matter of when.

But it is also clear that the IETF rarely looks forward more than a
couple of years or so and so does not see the need for future proofing.
The counter argument here seems to be code
complexity, the cost of adding

if bytes xyz == abc, treat as large
else treat as incomprehensible

Clearly operators want the functionality, can coders cope with the
complexity?

As to user interface, why change anything now? As and when new options
appear, then is the time to consider how to offer them to the user,
which should be the default, which requires extra information and so on.
For the moment, nothing changes.

Tom Petch

> > >>   |                          Local Data Part 1
|
> > >>   |                          Local Data Part 2
|
> > into resume enhancing material?

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

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 20 Sep 2016 21:44:29 +0300

Dear colleagues,

>From my perspective main dispute here is between flexibility and
simplicity. Engineers love flexibility, don't we? But flexibility without
wisdom will bring troubles: I think today BGP needs simplification of
configuration process and strict rules even more than flexibility. I do
support adoption of this draft, but I would like to see specification of
common usages for 32:32:32 as strict as possible (with SHOULD statement)
included in this draft. Otherwise we will still face with results of today
flexibility (AS number is filtered):

>    - remarks: - To prepand or deny prefix use FILTERED:5RSSA, where:
>
>
>    - remarks: R - Geographical region code:
>
>
>    - remarks: 1 - Russia
>
>
>    - remarks: 2 - Europe
>
>
>    - remarks: 3 - Asia
>
>
>    - remarks: 4 - America
>
>
>    - remarks:
>
>
>    - remarks: A - action:
>
>
>    - remarks:
>
>
>    - remarks: 0 - don't announce prefix
>
>
>    - remarks: 1 - announce with one prepend
>
>
>    - remarks: 2 - announce with two times prepend
>
>
>    - remarks: 3 - announce with three times prepend
>
>
>    - remarks:
>
>
>    - remarks:
>
>
>    - remarks: SS - peer number:
>
>
>    - remarks:
>
>
>    - remarks: Russia
>
>
>    - remarks: 01 - Megafon - AS31133
>
>
>    - remarks: 03 - Vimpelcom - AS3216
>
>
>    - remarks: 04 - Comstar - AS8359
>
>
>    - remarks: 10 - Vkontakte - AS47541
>
>
>    - remarks: 11 - Rostelecom - AS12389
>
>
>    - remarks: 12 - Mailru & Odnoklassniki - AS47764
>
>
>    - remarks:
>
>
>    - remarks:
>
>
>    - remarks: Europe
>
>
>    - remarks: 06 - Level3 - AS3356
>
>
>    - remarks: 07 - CHINA TELECOM - AS4134
>
>
>    - remarks: 09 - TeliaSonera - AS1299
>
>
>    - remarks: 14 - Cogent - AS174
>
>
>    - remarks: 15 - TATA - AS6453
>
>
>

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Sep 2016 21:21:53 +0200

As some folks already observed also my observation is that we are mixing
few different topics within this discussions on new BGP communities format.

- One is how to design an engine
- The other how to design the cockpit
- And now third one pop-ed out how to drive/fly it ...

How to design an engine is the topic for IDR WG.

How to design the user/pilot/driver interface is the topic for NETCONF,
OPENCONFIG, I2RS or vendors CLI/API.

How to drive/fly is the topic for all the *NOGs/BCPs.

All of the above are very important topics, but quite different and
orthogonal.

And the apparent problem seems to be pretty common believe that if we
follow 20 years old RFC1997 design of the two cylinder engine and only add
two more cylinders to it ignoring the lessons learned via last 20 years
everything else will stay the same.

Oh well ... let's see. But let's notice that via all of those years number
of proposals in BGP already uses TLVs and sub-TLVs (example: RFC7752) and
that today's cockpits already have to be able to handle that - unless we
really start to simplify BGP and start moving all of those modern BGP
extensions to historic.

Cheers,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 20 Sep 2016 15:53:50 -0400

> How to drive/fly is the topic for all the *NOGs/BCPs.
can I suggest that part of the problem / process here should be: "Make an
ops-group put for a BCP  to replace rfc1998 that talks about the best
method to use these shiny-new-communities being specified." ?

probably something in ops and related to routing  on a global scale...
GROW? :)
This would also let us (ietf) specify that there's a requirement for the
abiltity to express policy in the same fashion 1998 specifics only with
these larger ASN/etc.

> everything else will stay the same.
maybe also we can provide requirements for other uses of this community, or
other requirements for bgp attributes in other use-cases?

-chris

---

From: John Scudder <[email-masked]>
Date: Tue, 20 Sep 2016 20:27:57 +0000

> On Sep 20, 2016, at 2:44 PM, Alexander Azimov <[email-masked]> wrote:
> I think today BGP needs simplification of configuration process and strict rules even more than flexibility.

I think -- speaking only as a WG member -- that it's a mistake to assume a simplistic wire representation equates to simple configuration, or that a more elaborate wire representation must have a complex configuration. One can look at other fields in computing to see that very complex underpinnings can have simple UI presentations. It's also the case that simple configuration atoms don't necessarily produce simple configurations or simple systems. .asm is simple, but (almost!) nobody prefers to read .asm programs. 

I say this only because I think it needs to be said and not because I imagine it will change anyone's mind one way or the other on the question of large-.

Regards,

--John

P. S. I also reread "The Rise of Worse is Better" today. It has aged well.

---

From: Andrew Lange <[email-masked]>
Date: Tue, 20 Sep 2016 16:18:01 -0700

Agreed!

The vendor community has tended to do a poor job with UI.  In the past it’s been a CLI to program fields in packets.  Router vendors can, and should, do a better job.

Andrew

> On Sep 20, 2016, at 1:27 PM, John Scudder <[email-masked]> wrote:
>

---

From: Andrew Lange <[email-masked]>
Date: Tue, 20 Sep 2016 16:11:56 -0700

Sander,

There is a HUGE amount of complexity in the current community system.  Have you looked at your full policy lists?

If we have a TLV header, we can create things like neighbor classes, to allow automatic groupings, for example, and make things a LOT easier.   As a reminder, we’re not talking about doing that now, just putting in a TLV header to allow us to transition in the future without another headache.

Now the UI discussion is also at issue - fine, vendors frequently do a poor job of understanding that the UI is a user interface, and not a direct bit encoder.  This is a UI problem, not a protocol spec problem.  

Andrew

> On Sep 20, 2016, at 5:08 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Robert,
>

---

From: Andrew Lange <[email-masked]>
Date: Tue, 20 Sep 2016 16:22:28 -0700

Hi Alexander,

I share your concern about overly complex policies.  That is what drove flex and wide comms.  That is why we need a common TLV header.  It’s the only way we’ll ever improve the situation, otherwise we just kick the can down the road.

Andrew

> On Sep 20, 2016, at 11:44 AM, Alexander Azimov <[email-masked]> wrote:
> 
> Dear colleagues,
> 
> From my perspective main dispute here is between flexibility and simplicity. Engineers love flexibility, don't we? But flexibility without wisdom will bring troubles: I think today BGP needs simplification of configuration process and strict rules even more than flexibility. I do support adoption of this draft, but I would like to see specification of common usages for 32:32:32 as strict as possible (with SHOULD statement) included in this draft. Otherwise we will still face with results of today flexibility (AS number is filtered):
> 
> remarks:         - To prepand or deny prefix use FILTERED:5RSSA, where:
> remarks:         R - Geographical region code:
> remarks:         1 - Russia
> remarks:         2 - Europe
> remarks:         3 - Asia
> remarks:         4 - America
> remarks:
> remarks:         A - action:
> remarks:         
> remarks:         0 - don't announce prefix
> remarks:         1 - announce with one prepend
> remarks:         2 - announce with two times prepend
> remarks:         3 - announce with three times prepend
> remarks:         
> remarks:         
> remarks:         SS - peer number:
> remarks:         
> remarks:         Russia
> remarks:         01 - Megafon - AS31133
> remarks:         03 - Vimpelcom - AS3216
> remarks:         04 - Comstar - AS8359
> remarks:         10 - Vkontakte - AS47541
> remarks:         11 - Rostelecom - AS12389
> remarks:         12 - Mailru & Odnoklassniki - AS47764
> remarks:         
> remarks:         
> remarks:         Europe
> remarks:         06 - Level3 - AS3356
> remarks:         07 - CHINA TELECOM - AS4134
> remarks:         09 - TeliaSonera - AS1299
> remarks:         14 - Cogent - AS174
> remarks:         15 - TATA - AS6453
> 
> 
> 
> 2016-09-20 18:50 GMT+03:00 t.petch <[email-masked] <mailto:[email-masked]>>:
> From: "Robert Raszuk" <[email-masked] <mailto:[email-masked]>>
> To: "Susan Hares" <[email-masked] <mailto:[email-masked]>>
> Cc: "Interminable Discussion Room" <[email-masked] <mailto:[email-masked]>>
> > On Mon, Sep 19, 2016 at 11:21 PM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > >
> > > Randy
> > > From: Randy Bush <[email-masked] <mailto:[email-masked]>>
> > > To: Sander Steffann <[email-masked] <mailto:[email-masked]>>
> > > Cc: Interminable Discussion Room <[email-masked] <mailto:[email-masked]>>
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> > >
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> > >
> > >
> >
> 
> 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> 
> -- 
> | mailto: [email-masked] <mailto:[email-masked]>
> | visit: www.qrator.net <http://www.qrator.net/>_______________________________________________
> Idr mailing list
> [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Sep 2016 09:20:22 +0100

Andrew Lange wrote:
> There is a HUGE amount of complexity in the current community system.
> Have you looked at your full policy lists?
> 
> If we have a TLV header, we can create things like neighbor classes,
> to allow automatic groupings, for example, and make things a LOT
> easier.   As a reminder, we’re not talking about doing that now, just
> putting in a TLV header to allow us to transition in the future
> without another headache.
> 
> Now the UI discussion is also at issue - fine, vendors frequently do
> a poor job of understanding that the UI is a user interface, and not
> a direct bit encoder.  This is a UI problem, not a protocol spec
> problem.

Andrew,

There is complexity, yes, but I don't quite see why you claim that "no
one except a handful of backbone operators" understands how to use the
current communities system, because that is glaringly not the case.

If you have concrete proposals on how to define an algebra which can
simplify this - even better, with sample grammars so we can understand
how it might work in real life - then feel free to put a draft on the
table and the working group can discuss it.  When consensus is reached,
with multiple vendor support and running code, I don't see any reason
why this couldn't complement -large- as an important tool in the service
providers' toolbox.  In the interim, suggestions about things that could
exist some time in the future isn't a good argument that -large should
be blocked today.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Sep 2016 11:14:06 +0200

/* Adding GROW as most of this discussion is applicable to GROW WG */

Nick,

> current communities system, because that is glaringly not the case.

​The problem with 16:16 and now with endorsing 32:32:32 is that it still
requires an external oracle to manually translate encoded magic number into
set of actions.

Let me provide an example:

​I have 400 PEs and I want to do 10 different length of prepends depending
on the peering AS.

So today when I advertise the prefix I need 10 different communites for it
and 10 different policies on each out of my 399 egress PEs to translate
such magic number into an action.

While injecting 10 communities is not a big deal maintaining 10 different
policies across all 399 PEs adds-up and this is what makes the current BGP
policies very long and difficult to maintain.

And if we just add simple integer which will indicate the size of prepend
and within given AS make one magic number to indicate this is prepend
request we are neatly done.

> how it might work in real life - then feel free to put a draft on the

There is ​IDR WG doc -wide-communities as well there is written but not
posted yet simple idea of 32:32:tlv.

​We do not need algebra for that. Algebra was discussed to inject not 10
but 1 community to accomplish the above example. Without algebra just
​properly building the community fields is all what is needed to simplify
your policy configuration.

There is no free lunch ... why operators would highly benefit - vendors
need to add code to current policy language to handle new fields. And this
is where the crux of the issue is why -flex or -wide was not yet been
implemented.

- - - -

Hi Brian,

> To those who really really want TLVs, please do so using the
> following method:
> - reserve specific 32-bit ASNs from the reserved block(s)
> ...

I have DC and 15,000 CEs (multihomed customer sites across 3 global ASes).

I want per each application address I advertise from DC inject a community
which will do AS_PATH prepend from my 399 PEs to CEs based on the *IPv6
peering address* of the CEs.

Please tell me how said IPv6 prefix will be able to fit into -large
community such that I do not need to touch any of the 399 PE each time I
want to steer traffic to go via North or via South CE from each customer
site depending on central logic ?

Many thx,
R.

---

From: Gert Doering <[email-masked]>
Date: Wed, 21 Sep 2016 12:59:17 +0200

Hi,

On Wed, Sep 21, 2016 at 11:14:06AM +0200, Robert Raszuk wrote:
> ???I have 400 PEs and I want to do 10 different length of prepends depending
> on the peering AS.
> 

This is a very poor example for encoding such complexity into the *protocol*.

An implementation could easily do this in their route-policy language

  if ( community in ( MYAS:PEERAS:([1-9]) ) ) then
      set as-path prepend MYAS times $1 
  endif

with "MYAS" and "PEERAS" properly pre-defined in route-policy context.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Wed, 21 Sep 2016 13:19:28 +0200

Hi,

> ​The problem with 16:16 and now with endorsing 32:32:32 is that it still requires an external oracle to manually translate encoded magic number into set of actions. 

It provides flexible behaviour that can be agreed upon between consenting network operators. This is a feature, not a bug.

> ​I have 400 PEs and I want to do 10 different length of prepends depending on the peering AS. 
> 
> So today when I advertise the prefix I need 10 different communites for it and 10 different policies on each out of my 399 egress PEs to translate such magic number into an action. 
> 
> While injecting 10 communities is not a big deal maintaining 10 different policies across all 399 PEs adds-up

Networks with 400 PEs have management tools for that.

> and this is what makes the current BGP policies very long and difficult to maintain.
> 
> And if we just add simple integer which will indicate the size of prepend and within given AS make one magic number to indicate this is prepend request we are neatly done.

I think -large combined with documented best practices on how to encode actions in the last 32 bit field would be much better. A best practice document is much easier to update and use than having to define new TLV types and waiting for router vendors to implement them.

And it allows people to copy&paste the best practice when they want, and implement their own policy if not.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Sep 2016 14:02:22 +0200 (CEST)

On Wed, 21 Sep 2016, Robert Raszuk wrote:

> need to add code to current policy language to handle new fields. And 
> this is where the crux of the issue is why -flex or -wide was not yet 
> been implemented.

So while your proposal seems like a good idea, it's also a can of worms. 
All of a sudden we're going to have discussions on typical actions people 
will want to do (prepending is one), how to represent them, perhaps even a 
common way to configure it so each vendor has similar look and feel.

We need feature parity for 32bit ASNs now. Not in 12-18 months that I 
estimate above work would take (if even that quick).

Since we're not immediately running out of codepoints, let's do 32:32:32 
according to -large, and then let the existing work on -wide run its 
course and create a good solid framework for that with on-wire format that 
makes sense, and actions and UI that are well thought out. I think there 
are multiple people willing to work on it. It just requires lots more work 
than there is immediate need for, to solve the immediate problem. You 
probably want to announce the work to NANOG, bring in more people from the 
operator community to get their opinion, get buy-in from vendors that 
they're willing to commit resources to crate code to support this 
extensive framework, etc.

I would have supported your proposal if this was 2010 and we had 5+ years 
before we ran out of 16bit ASNs. Unfortunately, that's not the situation 
we're in. Unfortunately, now is the time for a quick-fix that's not that 
elegant and flexible, but gets the job done to create feature parity 
between 16 and 32bit ASNs.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Sep 2016 14:40:43 +0200

Hi Gert,

> with "MYAS" and "PEERAS" properly pre-defined in route-policy context.

Are you suggesting to embed the action (here prepend) into MYAS:PEERAS
fields ? Last part would be a parameter ... cool.

So if I need to also send different MED I would need yet one more magic
pair MYAS:PEERAS .... correct ?

Cheers,
R.

---

From: Gert Doering <[email-masked]>
Date: Wed, 21 Sep 2016 14:48:21 +0200

Hi,

On Wed, Sep 21, 2016 at 02:40:43PM +0200, Robert Raszuk wrote:
> fields ? 

Well, the example was not ideal.  The action would have to be part of
the 3rd field, so the match would be more along the lines of 

  if ( community in ( MYAS:PEERAS:1000([1-9]) ) ) then
      set as-path prepend MYAS times $1
  endif
  if ( community in ( MYAS:PEERAS:20([0-9][0-9][0-9]) ) ) then
      set med $1
  endif

> Last part would be a parameter ... cool.

This is what I've heard how people consider to use this, yes.

> pair MYAS:PEERAS .... correct ?

Well, since MYAS and PEERAS are the same for a given combination of 
"my AS" and "my peer AS", bits from the (vast!) 32 bit number space
in field 3 would be needed.

But the point is: this can be *signalled* using 32:32:32 just fine,
and how easy it is to make policy statements out of this is a matter of
flexibility of the vendors's route policy language.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Sep 2016 14:49:41 +0200 (CEST)

> pair MYAS:PEERAS .... correct ?

Communities have always been an ugly hack. Nobody disagrees. I'd love to 
have better tools to do things.

We just can't wait for them to get properly designed, agreed on, 
documented, implemented, tested, and then deployed.

So just give us the chance to continue with the ugly hack the same way 
it's been done for 20 years NOW, and we'd be grateful if there was a new 
great tool in 5 years. Go to SIDR, they might have need something as well. 
We can flesh out everybodys need over the next 6-18 months.

Design a wonderful new TLV based framework with everything we might need, 
do it well, it's ok if it takes 2-3 years until we're done.

But we need 32bit ASN parity with the old 16 bit ASN hack, and we need it 
now, we need it in deployable code in 2017. Please don't complicate 
things that make it a lot harder to implement.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Sep 2016 13:04:16 +0100

Robert Raszuk wrote:
> requires an external oracle to manually translate encoded magic number
> into set of actions. 

I'm struggling to understand how and why this is relevant to adopting
large as-is.

Operators are free to choose their own semantics and their own
constructions.  If you feel that it should be otherwise, post a bunch of
drafts to IDR and GROW and let's discuss them.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Sep 2016 18:01:38 +0200

Because if we say adopt large as 4:4:4:4 amount of this mapping is reduced.

Or we can adopt as-is then enlarge ...

Thx,
r.