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

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,

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

​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.

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
>

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
-- 
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: 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.