Subject: [GROW] Question about BGP Large Communities

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 4 Feb 2020 18:21:57 +0000

In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?

There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.

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

Details/background:

We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195

RFC 8195 has this table:

                 +-------------------------------+-------------------------+

                 |       RFC8092                    | RFC 8195                |

                 +-------------------------------+--------------------------+

                 | Global Administrator    |      ASN                     |

                 |  Local Data Part 1           |    Function              |

                 |  Local Data Part 2           |   Parameter            |

                 +--------------------------------+-------------------------+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.

For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).

Thank you.

Sriram

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 4 Feb 2020 11:09:01 -0800

On February 4, 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote:

[Speaking as a WG participant.]

Sriram:

Hi!

...
> as a "well-known Transitive Large Community"?

No.

There is no IANA registry for Global Administrator because it is
simply a "four-octet namespace identifier...SHOULD be an ASN"
[rfc8092], but it doesn't have to be.

Skimming through draft-ietf-grow-route-leak-detection-mitigation, I
would say (personal opinion) that you have two options:

(1) Describe the Local Data Parts so that they are well-known when
used by any ASN (Global Administrator).  This has the disadvantage
that the values may collide with existing policies (?).

(2) Request IANA to assign an ASN for this application.  Take a look
at rfc7249/§2.1, which talks about the allocation of special-purpose
AS Numbers.  The advantage is obviously that collisions can be
avoided, but it seems to me that it may be too much (an ASN) for just
this application.

So...if an ASN is requested, it would be independent of Large Communities.

...
> it appears it is *assumed* that the Large Communities are transitive.

rfc8092 "defines the BGP Large Communities attribute as an optional
transitive path attribute".

Regards,

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Feb 2020 20:21:48 +0100

Hi Sriram,

Just to add to what Alvaro said what you are looking for seems to be a new
type for the information required.

Large Communities are really unstructured from the perspective of types
like Extended Communities are.

But please observe that proposed Wide Communities do have support for
types:

https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-05

so perhaps you may want to take a look into this type of carrier as well.
Of course this assumes that more and more vendors will bring support of
Wide Communities to their BGP code at some point :).

Rgs,
Robert.

On Tue, Feb 4, 2020 at 8:09 PM Alvaro Retana <[email-masked]> wrote:

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 4 Feb 2020 20:45:40 +0000

A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) <[email-masked]>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <[email-masked]>; Job Snijders <[email-masked]>; Nick Hilliard <[email-masked]>; John Heasly <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Brian Dickson <[email-masked]>
Subject: Question about BGP Large Communities

Question:

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

Details/background:

RFC 8195 has this table:

                 |       RFC8092                    | RFC 8195                |

Thank you.

Sriram

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Feb 2020 23:18:37 +0100

And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Sriram, Kotikalapudi (Fed) <[email-masked]>
> *Sent:* Tuesday, February 4, 2020 10:22 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Job Snijders <[email-masked]>;
> Nick Hilliard <[email-masked]>; John Heasly <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Brian Dickson <
> [email-masked]>
> *Subject:* Question about BGP Large Communities
>
>
>
>                  |       RFC8092                    | RFC
> 8195                |
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 4 Feb 2020 22:31:32 +0000

The numbers are a trade off. How would you divide the numbers?

Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk <[email-masked]> wrote:

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Job Snijders <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>; John Heasly <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Brian Dickson <[email-masked]<mailto:[email-masked]>>
Subject: Question about BGP Large Communities

Question:

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

Details/background:

RFC 8195 has this table:

                 |       RFC8092                    | RFC 8195                |

Thank you.

Sriram

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Feb 2020 23:37:41 +0100

> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in
extended communities or use wide communities.

But I am a bit biased here ;-)

Best,
R,

---

From: John Heasly <[email-masked]>
Date: Tue, 4 Feb 2020 22:54:58 +0000

> Does anyone want to co-author and suggest changes?

Hey Jacob,
I'd work on that with you.  Job, Morrow and I also started a draft for
Large WKCs, but we have not submitted anything - nor made any recent
progress.

IIRC, the direction we were intending to use 0 (zero) as the ASN, then
define local data part 1 as WKC itself, and local data part 2 to be a
value associated.

I've attached that I have written so far.  Job and Morrow may or may not
endorse this approach at this point.

-heas

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Feb 2020 15:20:04 -0800

Hi, Jakob,
I'm interested/willing to co-author and/or review as needed.
(FYI: it looks like your bit field is mis-aligned, there should be 6 bits
above the 2-bit T value, then 8 bits of WKC.)

I agree that 256 (0-255) is more than enough WKC values, given that like 3
or 4 have been used in old community space.

Brian

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 5 Feb 2020 01:28:41 +0000

> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).  
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well. 

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when 
other LCs use 4-octet ASNs in the Global Administrator field. Agree?
I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider: 
Why not request IANA to assign a range of 256 or 1024 or some number (?) 
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC 
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.
That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -----Original Message-----
> From: John Heasly <[email-masked]>
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Sriram, Kotikalapudi (Fed) <[email-masked]>; Job Snijders
> <[email-masked]>; Nick Hilliard <[email-masked]>; John Heasly
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Brian Dickson
> <[email-masked]>
> Subject: Re: Question about BGP Large Communities
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 5 Feb 2020 01:40:22 +0000

Agree that for this case it may be more convenient to just use extended community with a new type, this could avoid any possible collision with existing deployments, and save the effort of assigning a set of ASNs. Wide community may be too powerful for this:)

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Sriram, Kotikalapudi (Fed) <[email-masked]>; Job Snijders <[email-masked]>; Nick Hilliard <[email-masked]>; John Heasly <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [GROW] Question about BGP Large Communities

> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in extended communities or use wide communities.

Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
The numbers are a trade off. How would you divide the numbers?
Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Thx,
R.

Regards,
Jakob.

Question:

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

Details/background:

RFC 8195 has this table:

                 |       RFC8092                    | RFC 8195                |

Thank you.

Sriram

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Feb 2020 17:43:05 -0800

> RFC 8195 seems to be written in that spirit as well.

They are, by default, transitive, unless local policy is to either strip
them or filter updates based on the values (or some portion out of the
values, like bits 6-7).

> other LCs use 4-octet ASNs in the Global Administrator field. Agree?

Only real ASNs have any reasonable expectation of collision protection and
uniqueness, i.e. ASN values <4,000,000,000

> Then we don't waste any part of the first 32-bits to designate "type" of

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values
>4,000,000,000 as private values.
Reserving only those that start (binary) 111110 is a very small slice off
that range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T
field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 5 Feb 2020 01:44:01 +0000

I'm asking for 67 million AS numbers, after which there will still be over 4 billion AS numbers,
not including the nearly 95 million private AS numbers.
That's not much more than your 1024.

Regards,
Jakob.

-----Original Message-----
From: Sriram, Kotikalapudi (Fed) <[email-masked]> 
Sent: Tuesday, February 4, 2020 5:29 PM
To: John Heasly <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Question about BGP Large Communities

Sriram

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Feb 2020 17:44:51 -0800

Disagree, we want something deployed (large) and deployable (requiring only
IANA action, no vendor activity) immediately.
IMHO, any special handling or new code points or upgrades are non-starters.
This particularly applies to wide and extended
Brian

On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Agree that for this case it may be more convenient to just use extended
> community with a new type, this could avoid any possible collision with
> existing deployments, and save the effort of assigning a set of ASNs. Wide
> community may be too powerful for this:)
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Wednesday, February 5, 2020 6:38 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Sriram, Kotikalapudi (Fed) <[email-masked]>; Job
> Snijders <[email-masked]>; Nick Hilliard <[email-masked]>; John Heasly <
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [GROW] Question about BGP Large Communities
>
>
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 5 Feb 2020 02:02:56 +0000

Private ASNs are 4,200,000,000 upwards.
I am requesting a block just below that > 4,000,000,000.

Regards,
Jakob.

From: Brian Dickson <[email-masked]>
Sent: Tuesday, February 4, 2020 5:43 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: John Heasly <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Question about BGP Large Communities

They are, by default, transitive, unless local policy is to either strip them or filter updates based on the values (or some portion out of the values, like bits 6-7).

Only real ASNs have any reasonable expectation of collision protection and uniqueness, i.e. ASN values <4,000,000,000

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values >4,000,000,000 as private values.
Reserving only those that start (binary) 111110 is a very small slice off that range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian

Sriram

> From: John Heasly <[email-masked]<mailto:[email-masked]>>
> To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
> Cc: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>; Job Snijders
> <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>; John Heasly
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Brian Dickson
> <[email-masked]<mailto:[email-masked]>>

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 5 Feb 2020 09:00:35 +0000

Hi,

In my opinion, when we apply a new function from IANA, we will have to deploy some extra route policies to set and parse the specific function as your suggested way.
With the increase of new functions, the route policies deployed will become more and more complicated.

Best regards,
Shunwan

From: GROW [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Wednesday, February 5, 2020 9:45 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [GROW] Question about BGP Large Communities

Disagree, we want something deployed (large) and deployable (requiring only IANA action, no vendor activity) immediately.
IMHO, any special handling or new code points or upgrades are non-starters.
This particularly applies to wide and extended
Brian

On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Agree that for this case it may be more convenient to just use extended community with a new type, this could avoid any possible collision with existing deployments, and save the effort of assigning a set of ASNs. Wide community may be too powerful for this:)

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>; Job Snijders <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>; John Heasly <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [GROW] Question about BGP Large Communities

Best,
R,

On Feb 4, 2020, at 2:19 PM, Robert Raszuk <[email-masked]<mailto:robert@raszuk..net>> wrote:

Thx,
R.

Regards,
Jakob.

Question:

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

Details/background:

RFC 8195 has this table:

                 |       RFC8092                    | RFC 8195                |

Thank you.

Sriram

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Feb 2020 10:01:37 +0100

Just to clarify one subtle point.

In wide communities types are either operator assigned or IANA driven - no
new code from vendor is required in contrast to extended community. That
along with variable length is what makes wide communities universal.

Sure that some vendors or individuals are scared about policy aspect of
wide communities processing - but implementing policy handling any
arbitrary types (irrespective of IANA or local assignment) is optional.

- - -

To the topic of using Large Communities - I do recommend whichever encoding
is chosen to always be able to insert and carry originator's ASN. All zeros
are meaningless read: anonymous.

Thx,
R.

On Wed, Feb 5, 2020 at 2:45 AM Brian Dickson <[email-masked]>
wrote:

> Disagree, we want something deployed (large) and deployable (requiring
> only IANA action, no vendor activity) immediately.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Feb 2020 10:14:52 +0000

Zhuangshunwan wrote on 05/02/2020 09:00:
> In my opinion, when we apply a new function from IANA, we will have to 
> deploy some extra route policies to set and parse the specific function 
> as your suggested way.
> 

A WKC will generally describe a specific function or set of actions to 
be applied to a prefix. If the WKC also encodes an administrator ASN or 
a target ASN, then it becomes a domain-specific community rather than a 
well-known community.

I'm not against the idea of LC WKCs in theory, but there would need to 
be compelling reasons as to why the existing rfc1997 wkc range didn't 
work.  IOW, we should think twice about setting aside a range unless 
there are specific deployment cases which need LCs, and where rfc 1997 
communities wouldn't work.

Nick

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Feb 2020 02:42:25 -0800

> not including the nearly 95 million private AS numbers.

should be enough.  after all, ipv6 only had 4096 possible providers

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Feb 2020 02:46:39 -0800

> are meaningless read: anonymous.

one can no longer assume all actors have good intent.

communities are arbitrary graffiti whose beauty lies in the eyes of the
beholder.  one can not assume rigor.

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 6 Feb 2020 09:58:45 +0000

If I understand it correctly, the proposed mechanism in Jakob's draft requires to change the encoding of Global Administrator in Large community. In general I like this change, it gives LC a structural encoding, which may be useful for future use cases. OTOH, this change typically would require new code and upgrade of devices, which may not meet the requirement mentioned in Brian's mail...

Best regards,
Jie

> From: GROW [mailto:[email-masked]] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Wednesday, February 5, 2020 9:29 AM
> Otherwise, collisions (ambiguity) could happen when other LCs use 4-octet
> ASNs in the Global Administrator field. Agree?
> The draft that John Heasly shared sets the first 32-bits to ASN value 0 to
> designate WK-LC;  so no part of the first 32-bits is data.
> 
> Why not request IANA to assign a range of 256 or 1024 or some number (?) of
> 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
> A function (e.g., route-leak protection) that requires transitive WK-LC will be
> allocated one these ASN values.
> That cleanly leaves 64 bits for local data (as RFC 8092 specifies) which can
> accommodate two 4-byte ASNs if needed.
> 
> Sriram
> 
> > Cc: Sriram, Kotikalapudi (Fed) <[email-masked]>; Job
> > Snijders <[email-masked]>; Nick Hilliard <[email-masked]>; John Heasly
> > <[email-masked]>; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]; Brian
> > Dickson <[email-masked]>
> > I've attached that I have written so far.  Job and Morrow may or may
> > not endorse this approach at this point.
> >
> > -heas
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 6 Feb 2020 16:02:54 +0000

Jakob,

>I am requesting a block just below that > 4,000,000,000.

That sounds reasonable.
We can discuss trading off some bits between WKLC ID and Data 1
to possibly give room for more than 256 WKLCs.

Sriram