Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

From: "Susan Hares" <[email-masked]>
Date: Tue, 9 Mar 2021 05:17:16 -0500

This begins a WG Adoption call for draft-heitz-idr-wklc-02.txt. 

https://datatracker.ietf.org/doc/draft-heitz-idr-wklc/

In your review of this draft, please consider: 

1) Should IDR standardize a set of "well known large communities"? 

2) Will the transitivity field help these well know large communities?

3) Is this document ready for adoption? 

I've not received Sriram's IPR statement.  If this statement is not received
within 1 week, this WG adoption call will pause waiting for that statement. 

Cheers, Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 10 Mar 2021 12:00:33 +0800

Hi，Jakob:

Considering the communities is used mainly for the tag of BGP routes. 

And as also mentioned in your draft, that there are only about 22 well-known
communites have been used so far. Then what’s the necessary to
define/reserve the well-known large communities?

Why the current well-known
communities(https://www.iana.org/assignments/bgp-well-known-communities/bgp-
well-known-communities.xhtml#bgp-well-known-communities-1) can’t be used to
accommodate the requirements, which is not stated in the draft?

And, after reading the current version of the draft, some confusions are
raised:

1.     Where is the “type” filed, that you mentioned in
https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4, are
you referring the “WKLC ID” field in your encoding?

2.     The length of LC is 12 octets, as defined in
https://datatracker.ietf.org/doc/html/rfc8092, why you just use 10 octets,
and want also to encourage the user to follow the canonical representation
of RFC8092?

3.     From my understanding, your draft just want to reserve some 4 bytes
AS range for the “Global Administrator” part of the large community, is
that right? If so, what’s necessary to divide it into three parts?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Tuesday, March 9, 2021 6:17 PM
To: [email-masked]
Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

1) Should IDR standardize a set of “well known large communities”? 

I’ve not received Sriram’s IPR statement.  If this statement is not
received within 1 week, this WG adoption call will pause waiting for that
statement. 

Cheers, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 10 Mar 2021 06:20:56 +0000

Well known communities have no data field.
Well known large communities have 10 octets of data available for each WKLC.

1. Yes, "type" is meant to be WKLC ID. Thanks for finding it. I'll fix it.

2. the 10 octets of data are divided into 3 fields for convenience of representation.
    I did state that any specific WKLC may define another division.
    Maybe it would be easier to just put 10 octets free form with fields to be defined by each specific WKLC as it is defined.

3. Same answer as for 2. 3 data fields is suggested, as it looks to be the most convenient division for the most likely applications. Perhaps you can come up with better wording?

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Aijun Wang
Sent: Tuesday, March 9, 2021 8:01 PM
To: 'Susan Hares' <[email-masked]>; [email-masked]
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi，Jakob:

Considering the communities is used mainly for the tag of BGP routes.
And as also mentioned in your draft, that there are only about 22 well-known communites have been used so far. Then what’s the necessary to define/reserve the well-known large communities?
Why the current well-known communities(https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml#bgp-well-known-communities-1) can’t be used to accommodate the requirements, which is not stated in the draft?

And, after reading the current version of the draft, some confusions are raised:

1.     Where is the “type” filed, that you mentioned in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4, are you referring the “WKLC ID” field in your encoding?

2.     The length of LC is 12 octets, as defined in https://datatracker.ietf.org/doc/html/rfc8092, why you just use 10 octets, and want also to encourage the user to follow the canonical representation of RFC8092?

3.     From my understanding, your draft just want to reserve some 4 bytes AS range for the “Global Administrator” part of the large community, is that right? If so, what’s necessary to divide it into three parts?

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: Tuesday, March 9, 2021 6:17 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

I’ve not received Sriram’s IPR statement.  If this statement is not received within 1 week, this WG adoption call will pause waiting for that statement.

Cheers, Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 10 Mar 2021 14:30:46 +0800

Would you like to describe the situation that the “well-known communities”
is not enough to tag the BGP routes?

From: Jakob Heitz (jheitz) <[email-masked]> 
Sent: Wednesday, March 10, 2021 2:21 PM
To: Aijun Wang <[email-masked]>; 'Susan Hares' <[email-masked]>;
[email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

2. the 10 octets of data are divided into 3 fields for convenience of
representation.

    Maybe it would be easier to just put 10 octets free form with fields to
be defined by each specific WKLC as it is defined.

3. Same answer as for 2. 3 data fields is suggested, as it looks to be the
most convenient division for the most likely applications. Perhaps you can
come up with better wording?

Regards,

Jakob.

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of
Aijun Wang
Sent: Tuesday, March 9, 2021 8:01 PM
To: 'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi，Jakob:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <idr-bounces@ietf.
org <mailto:[email-masked]> > On Behalf Of Susan Hares
Sent: Tuesday, March 9, 2021 6:17 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Cheers, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 10 Mar 2021 06:49:57 +0000

When the tag requires additional data. For example, when it is necessary to
know which AS added the tag. Then that ASN can be written into the data field.
For example, https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Tuesday, March 9, 2021 10:31 PM
To: Jakob Heitz (jheitz) <[email-masked]>; 'Susan Hares' <[email-masked]>; [email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Would you like to describe the situation that the “well-known communities” is not enough to tag the BGP routes?

From: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 10, 2021 2:21 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: Tuesday, March 9, 2021 8:01 PM
To: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi，Jakob:

Best Regards

Aijun Wang
China Telecom

Cheers, Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 10 Mar 2021 16:10:41 +0800

How about just reserve the 4-byte AS range for the well-known large
community, and leave the other 8-bytes be defined by each WKLC as that done
in
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
04?

I think such arrangement will be conformed with the definition of
LC(RFC8092), also aligned with the proposed DO large community?

Or else, the DO large community should be modified to follow your proposal?

And, what the reason to assign the “111101”value in the first 6bit your
encoding? It is not conformed to general definition of large community, in
which the first 4-bytes is to identify the Global Administrator.

From: Jakob Heitz (jheitz) <[email-masked]> 
Sent: Wednesday, March 10, 2021 2:50 PM
To: Aijun Wang <[email-masked]>; 'Susan Hares' <[email-masked]>;
[email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

know which AS added the tag. Then that ASN can be written into the data
field.

For example,
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
04.

Regards,

Jakob.

From: Aijun Wang <[email-masked]
<mailto:[email-masked]> > 
Sent: Tuesday, March 9, 2021 10:31 PM
To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >;
'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

From: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, March 10, 2021 2:21 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]>
>; 'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 

Regards,

Jakob.

Hi，Jakob:

 

Best Regards

Aijun Wang

China Telecom

Cheers, Susan Hares

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 10 Mar 2021 11:52:05 +0000

Hi Sue,
I have reviewed both revisions of the draft and support adoption. It makes sense to define well-known large communities as has been done for communities and there is already a proposed usage.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday, March 9, 2021 at 5:18 AM
To: IDR List <[email-masked]>
Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Cheers, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 10 Mar 2021 13:17:44 +0000

Consider if there is a real AS that uses 4,093,640,704 as its ASN.
And if this AS were to send a large community of its own.
It would put its ASN into the Global Administrator field of the LC.
This ASN is 11110100000000000000000000000000 in binary.
Then another AS sends a WKLC with WKLC ID 0, Transitivity 0 and Data 1 = 0.
This has the same bit pattern.
To avoid the clash, we need to reserve the ASNs that would clash.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <[email-masked]>; 'Susan Hares' <[email-masked]>; [email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

And, what the reason to assign the "111101"value in the first 6bit your encoding? It is not conformed to general definition of large community, in which the first 4-bytes is to identify the Global Administrator.

---

From: Aijun Wang <[email-masked]>
Date: Wed, 10 Mar 2021 21:37:49 +0800

Yes, if we reserve some 4-bytes AS range, then your concerns will not happen.
The well-known large community need just be allocated from this reserved range. That’s all.
Do we need other definitions in your draft then?

Aijun Wang
China Telecom

> On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> 
> And, what the reason to assign the “111101”value in the first 6bit your encoding? It is not conformed to general definition of large community, in which the first 4-bytes is to identify the Global Administrator.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 12 Mar 2021 15:15:34 +0800

Hi, Jakob:

More questions for your draft:

1.     Do we need to reserve such huge range(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) as you described in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-6 for the countable well-known large communities?
2.     There is some inaccurate description for the current reserved AS number space in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4.  You can check it at https://www.iana.org/assignments/as-numbers/as-numbers.xhtml. The unallocated AS range is 401309-4199999999, not at described in your draft “The range of AS numbers currently unallocated by IANA is 399,261 to 4,199,999,999.”
3.     What’s the necessary to group such WKLC via the WKLC ID? 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Aijun Wang

China Telecom

On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> > wrote:

Regards,

Jakob.

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >; 'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 12 Mar 2021 07:45:01 +0000

1. It is small, not huge as explained in the draft.
2. It got updated and I missed it when I updated my draft. Thanks for catching it.
3. I don't understand your question. Can you expand?

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jakob.

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 12 Mar 2021 16:30:52 +0800

Hi, Jakob:

From: Jakob Heitz (jheitz) <[email-masked]> 
Sent: Friday, March 12, 2021 3:45 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

[WAJ] When compared to the 22 well-known community, “67,108,864 AS numbers” is too large.  I am worrying the unnecessary reservation may prevent the allocation of the unallocated AS-number for other purposes.

[WAJ] why not take the approach directly as that descried in  https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04. ?

That is to say, for each potential well-known large community, reserve one value for the “Global Administrator” part of the large community, and defined the associated data for the other two local parts. Transitive or non-transitive can be defined accordingly. 

Currently, you define “WKLC ID” as the large community type. From the definition of large community(RFC8092), the “Global Administrator” part will be divided into 256 groups, each group will have 2^16 number, that is 2^16 well-known large communities? 

I know you want to leave some field to the data part, but this arises some confusion when your proposed encoding is different from the original definition of RFC8092.

Regards,

Jakob.

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Aijun Wang

China Telecom

Regards,

Jakob.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Mar 2021 10:13:31 -0800

On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Jakob:
>
>
>
> *From:* Jakob Heitz (jheitz) <[email-masked]>
> *Sent:* Friday, March 12, 2021 3:45 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> *[WAJ] When compared to the 22 well-known community, “67,108,864 AS
> numbers” is too large.  I am worrying the unnecessary reservation may
> prevent the allocation of the unallocated AS-number for other purposes.*
>

The range of reserved ASNs occupies two bits of the upper 8 bits, plus the
entirety of the the next 24 bits in its range.
This represents a single value from the 6-bit portion of the ASN space, or
exactly 1/64 of the 32-bit ASN space.
Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus
less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or
about 1/1000.
This still leaves well over 31/32 of the potential ASN space, so I believe
your worry is unjustified.

> *[WAJ] why not take the approach directly as that descried in  *
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04.
> ?
>
> *That is to say, for each potential well-known large community, reserve
> one value for the “Global Administrator” part of the large community, and
> defined the associated data for the other two local parts. Transitive or
> non-transitive can be defined accordingly. *
>
> *Currently, you define “WKLC ID” as the large community type. From the
> definition of large community(RFC8092), the “Global Administrator” part
> will be divided into 256 groups, each group will have 2^16 number, that is
> 2^16 well-known large communities? *
>
> *I know you want to leave some field to the data part, but this arises
> some confusion when your proposed encoding is different from the original
> definition of RFC8092.*
>

The logic for this is as follows:
The initial use case is to establish a structured value of TBD1:TBD2:ASN
for the route-leak-detection-mitigation (as that draft explains).
The TBD2 is a single value out of a 32-bit range which will be in its own
(new) registry. Having a registry allows for future uses in the context of
TBD1, allowing new kinds of LC's in this bigger registered range.

However, the router implementations, for the most part, permit filtering of
LCs on the basis of 3 32-bit values, where either literal values or
wildcards can be used.
Having the elements be aligned on the 32-bit boundary, and having TBD1 and
TBD2 be fixed values, permits LC matching using a patterns of either
TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).
In other words, this structure choice is forced by router implementations,
and really not appropriate to second-guess. It isn't up for negotiation, as
this is a necessary requirement for the first use case.

BTW: Both of these patterns (fixed single value and wild-card of lower
32-bit value) are required to implement the GROW draft you referenced.

Having said that, this is the first out of up to 255 WKLCs, and the maximum
benefit to other potential uses for WKLC is achieved by making the maximum
(reasonable) number of octets available for those other WKLCs, specifically
10 octets of undefined structure.

In particular, it is possible that other WKLCs require two ASN data values
in their encoding (such as a source ASN and a destination ASN), and
additional values (single bits or ranges of values) beyond that. Limiting
the WKLC to having only single Global Administrator values and 8 octets of
data, would be insufficient in that case.

This would require re-design of WKLCs at a later date, and it may not be
possible due to existing usage or reservations of WKLCs.

By providing more octets to EACH WKLC, this problem is prevented. Making
data allocations on power-of-two boundaries at the highest order is
necessary up front. Attempting to expand ranges after allocations is
possible, but may not be compatible with the power-of-two alignment
required by future use cases of WKLC.

You cannot aggregate that which was not initially allocated in a fashion
suitable for aggregation. This was one major outcome of the IP allocation
strategies prior to CIDR addressing for IPv4 address space. We would do
well to learn from the mistakes of others, particularly when those mistakes
were effectively repeated in the ASN space already (16 bits to 32 bits,
because the initial assumption was 16 bits would be sufficient).

So, in summary, the reservation of the range of ASNs is specifically to
permit applying structure to the LC values within that range.
The original LC definition is only applicable to "actual" ASNs as Global
Administrator. RFC8092 says only "intended", and that the value "SHOULD" be
an ASN.
This is a new use case, and is the reason RFCs use "SHOULD" instead of
"MUST".
(What RFC8092 really says is, LCs where the Global Administrator value
corresponds to an actual assigned ASN, are reserved exclusively for the
operator of that ASN.)
Since this proposal sets aside a range of ASNs as a group, the structure of
LCs covering that range can be redefined accordingly, as long as that
redefinition is scoped to that range of ASNs.
This is EXACTLY what this WKLC proposal is doing, and nothing more.
The other draft is for the use of the first assigned WKLC values (single ID
plus the Transitive Bit values).

Hope this clarifies the usage and compatibility with other RFCs.

Brian

>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Aijun Wang <[email-masked]>
> *Sent:* Thursday, March 11, 2021 11:16 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> Hi, Jakob:
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Aijun
> Wang
> *Sent:* Wednesday, March 10, 2021 9:38 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> *From:* Aijun Wang <[email-masked]>
> *Sent:* Wednesday, March 10, 2021 12:11 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; 'Susan Hares' <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
> 3/23)
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 15 Mar 2021 10:14:21 +0800

Hi, Brian:

Based on your intention, I think you should consider to redefine the encoding of LC, not only well-known LC.

Even for the redefinition of LC encoding, you should also state clearly the potential advantages.

More detail replies are inline below.

Best Regards

Aijun Wang

China Telecom

From: Brian Dickson <[email-masked]> 
Sent: Saturday, March 13, 2021 2:14 AM
To: Aijun Wang <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; IETF IDR <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Jakob:

To: Aijun Wang <[email-masked] <mailto:[email-masked]> >

The range of reserved ASNs occupies two bits of the upper 8 bits, plus the entirety of the the next 24 bits in its range.

This represents a single value from the 6-bit portion of the ASN space, or exactly 1/64 of the 32-bit ASN space.

Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or about 1/1000.

This still leaves well over 31/32 of the potential ASN space, so I believe your worry is unjustified.

[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)).  

The initial use case is to establish a structured value of TBD1:TBD2:ASN for the route-leak-detection-mitigation (as that draft explains).

The TBD2 is a single value out of a 32-bit range which will be in its own (new) registry. Having a registry allows for future uses in the context of TBD1, allowing new kinds of LC's in this bigger registered range.

[WAJ] You should state also the reason that such sub-registry under one well-known LC.  Describe some examples may be helpful.  DO community is one example, but there still also no more explanation.

However, the router implementations, for the most part, permit filtering of LCs on the basis of 3 32-bit values, where either literal values or wildcards can be used.

Having the elements be aligned on the 32-bit boundary, and having TBD1 and TBD2 be fixed values, permits LC matching using a patterns of either TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).

In other words, this structure choice is forced by router implementations, and really not appropriate to second-guess. It isn't up for negotiation, as this is a necessary requirement for the first use case.

BTW: Both of these patterns (fixed single value and wild-card of lower 32-bit value) are required to implement the GROW draft you referenced.

Having said that, this is the first out of up to 255 WKLCs, and the maximum benefit to other potential uses for WKLC is achieved by making the maximum (reasonable) number of octets available for those other WKLCs, specifically 10 octets of undefined structure.

In particular, it is possible that other WKLCs require two ASN data values in their encoding (such as a source ASN and a destination ASN), and additional values (single bits or ranges of values) beyond that. Limiting the WKLC to having only single Global Administrator values and 8 octets of data, would be insufficient in that case.

This would require re-design of WKLCs at a later date, and it may not be possible due to existing usage or reservations of WKLCs.

By providing more octets to EACH WKLC, this problem is prevented. Making data allocations on power-of-two boundaries at the highest order is necessary up front. Attempting to expand ranges after allocations is possible, but may not be compatible with the power-of-two alignment required by future use cases of WKLC.

You cannot aggregate that which was not initially allocated in a fashion suitable for aggregation. This was one major outcome of the IP allocation strategies prior to CIDR addressing for IPv4 address space. We would do well to learn from the mistakes of others, particularly when those mistakes were effectively repeated in the ASN space already (16 bits to 32 bits, because the initial assumption was 16 bits would be sufficient).

[WAJ] If you want to accomplish this, I think you should propose to change the encoding of LC, not only the well-known LC.   And, the community is not used to packet forwarding, what’s the necessary to aggregate?

So, in summary, the reservation of the range of ASNs is specifically to permit applying structure to the LC values within that range. 

The original LC definition is only applicable to "actual" ASNs as Global Administrator. RFC8092 says only "intended", and that the value "SHOULD" be an ASN.

This is a new use case, and is the reason RFCs use "SHOULD" instead of "MUST".

(What RFC8092 really says is, LCs where the Global Administrator value corresponds to an actual assigned ASN, are reserved exclusively for the operator of that ASN.)

Since this proposal sets aside a range of ASNs as a group, the structure of LCs covering that range can be redefined accordingly, as long as that redefinition is scoped to that range of ASNs.

[WAJ] This is different from the structure of LC defined in RFC8092, in which only the Local part 1/local part 2 of one Global Administrator is operator-defined.

The other draft is for the use of the first assigned WKLC values (single ID plus the Transitive Bit values).

Brian

Regards,

Jakob.

Hi, Jakob:

Best Regards

Aijun Wang

China Telecom

Aijun Wang

China Telecom

Regards,

Jakob.

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 15 Mar 2021 05:29:06 +0000

[JH] Aijun. I'm glad you agree that there is still abundant space to allocate ASNs.
The reason to reserve space is explained in the introduction.
It is to prevent WKLCs from having the same Global Administrator field as a legitimate AS trying to distribute its LC.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Sunday, March 14, 2021 7:14 PM
To: 'Brian Dickson' <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; 'IETF IDR' <[email-masked]>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

From: Brian Dickson <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, March 13, 2021 2:14 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; IETF IDR <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Jakob:

To: Aijun Wang <[email-masked]<mailto:[email-masked]>>

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

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

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 15 Mar 2021 16:05:13 +0800

Hi, Jakob:

I think your purpose is to define 256 WKLC, each can has its own Data1/Data2/Data3 definition to carry some additional information for the specified WKLC.

To accomplish this, you should reserve  4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) 4-bytes AS number, which can’t be allocated for the legitimate usage by operators.  

The reason to get such results is that you want to define the additional “Data 1” field from the  “Global Administrator”, but there is no description to explain the necessary.  Brian gave some potential examples in this thread and I think expanding them more clearly in your draft maybe more convincible.

Best Regards

Aijun Wang

China Telecom

From: Jakob Heitz (jheitz) <[email-masked]> 
Sent: Monday, March 15, 2021 1:29 PM
To: Aijun Wang <[email-masked]>; 'Brian Dickson' <[email-masked]>
Cc: 'IETF IDR' <[email-masked]>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Regards,

Jakob.

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Sunday, March 14, 2021 7:14 PM
To: 'Brian Dickson' <[email-masked] <mailto:[email-masked]> >
Cc: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >; 'IETF IDR' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Brian:

Best Regards

Aijun Wang

China Telecom

From: Brian Dickson <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, March 13, 2021 2:14 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >; IETF IDR <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

Brian

Regards,

Jakob.

Hi, Jakob:

Best Regards

Aijun Wang

China Telecom

Aijun Wang

China Telecom

Regards,

Jakob.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Mar 2021 18:33:30 -0400

Hi Jacob

I have a few questions related to the draft.

Do you think it would make sense to make this an experimental draft and as
it matures in testing the leak mitigation we can advance to standards track.

The WKLC format change reason as you stated to flip flop the global and
local part as per GROW leak detection proposal to use the WKLC to primary
goal of community usage would be for “route leak detection” and per the
leak draft as you stated the reason for the global and local part flip flop
is so that the field is prevent the legitimate AS from having the same AS
field as the leak routes signaling and tagging.

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

Is this draft updating RFC 8092 and if it is not it is really confusing for
any reader as it does seem that it is being updated to this new format.

How would legitimate traffic use RFC 8092 format and non legitimate use
this new draft format of RFC 8092 is being updated.

Also how can you maintain 2 completely different formats for large
communities one for legitimate following RFC 8092 and one for leak draft
using flip flopped fields.  Or is RFC 8092 being updated and this is a new
format being proposed.  We should state if this draft is updating RFC 8092.

Also in Section 2 encoding the Data fields are not defined as global or
local.  Are the three fields open and not defined maybe to used for global
or local at the operators discretion?

It appears the leak draft defined the 10 byte 3 data fields as NN1:NN2:ASN
however your draft keeps it wide open for the operator to whatever it
chooses for the 10 byte field.   Would that make the RegEx match
complicated and break RegEx matching as now you don’t know what field is
what do you don’t know what to match on.  I can see the advantage idea of
the flexibility of not defining the 3 data fields but I am not sure that
work with RegEx matching.

In thread was mentioned 2 ASN fields mentioned by Brian which does seem
strange.  Usually the ASN data field is set to the originator ASN that is
doing the marking.

So from RFC 8092 to this proposal to account for the route leaking issue
solution WKLC we go from 3 data fields and 12 bytes ASN:NN1:NN2 to 3 data
fields 10 bytes NN1:NN2:ASN using the first two bytes for flags and WKLC
byte.

In the draft in some spots it says the 10 bytes data field is for WKLC but
can’t it be used for any large community usage.

The goal of RFC 8092 was to make the data field larger for 4 byte ASNs but
does not specifically addressing WKLC.

All of these questions need to be made more clear in this draft before it
can be adopted.

The leak draft proposes one format idea for WKLC format, however  I don’t
understand why we are jumping from a standards perspective on this one idea
to flip flop the format or make it open with no defined structure as a
solution to mitigate the route leaking.

The leak detection draft lacks guidance as to why this DO format was chosen
and does not propose any other ideas or options for leak mitigation.

In the leak draft section 3 of community versus attribute and I agree that
a new path attribute would be the way to go but as stated that would
require code upgrades and longer lead time for operators to implement.

It does seem like a rush to get something pushed out as a stop gap measure
“standards bandaid” without thoroughly thinking through all the nuances and
possible ramifications of this flip flop or open ended concept.

I agree that some thought was put into the solution comparing drop leak
detection versus deprioritization and I agree the RFC 8092 LC is the best
method for the solution at this point, but I am not convinced on the
flip/flop format DO community style for route leak mitigation.  Also we
stated how would RegEx match work if you don’t know which field is the
global field and the high field is the local field.  I cannot see this
working.

As with RegEx you can match on any digit in the RFC 8092 style AS:NN1:NN2
versus the flip/flop idea NN1:NN3:AS.

In the draft as the fields are open ended, how are we calculating that WKLC
uses the number of ASNs listed below.

   The range of AS numbers currently unallocated by IANA is 399,261 to
   4,199,999,999.  The WKLC reserves 67,108,864 AS numbers.  That still
   leaves 4,132,491,874 unallocated AS numbers.  For comparison, there
   are 94,968,317 AS numbers reserved for private use.  Thus, the number
   of ASNs reserved for WKLCs is considered insignificant.

As all communities to date have always follows the AS:NN Global:Local part
I am not sure  why the drastic change in format.

Kind Regards

Gyan

On Mon, Mar 15, 2021 at 1:30 AM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> *[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(*4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)*).  *
>
>
>
> It is to prevent WKLCs from having the same Global Administrator field as
> a legitimate AS trying to distribute its LC.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *Sent:* Sunday, March 14, 2021 7:14 PM
> *To:* 'Brian Dickson' <[email-masked]>
> *Cc:* Jakob Heitz (jheitz) <[email-masked]>; 'IETF IDR' <[email-masked]>
> *From:* Brian Dickson <[email-masked]>
> *Sent:* Saturday, March 13, 2021 2:14 AM
> *Cc:* Jakob Heitz (jheitz) <[email-masked]>; IETF IDR <[email-masked]>
> *[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(*4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)*).  *
>
>
>
> *[WAJ] You should state also the reason that such sub-registry under one
> well-known LC.  Describe some examples may be helpful.  DO community is one
> example, but there still also no more explanation.*
>
>
>
> However, the router implementations, for the most part, permit filtering
> of LCs on the basis of 3 32-bit values, where either literal values or
> wildcards can be used.
>
> Having said that, this is the first out of up to 255 WKLCs, and the
> maximum benefit to other potential uses for WKLC is achieved by making the
> maximum (reasonable) number of octets available for those other WKLCs,
> specifically 10 octets of undefined structure.
>
>
>
> *[WAJ] If you want to accomplish this, I think you should propose to
> change the encoding of LC, not only the well-known LC.   And, the community
> is not used to packet forwarding, what’s the necessary to aggregate?*
>
>
>
> Since this proposal sets aside a range of ASNs as a group, the structure
> of LCs covering that range can be redefined accordingly, as long as that
> *[WAJ] This is different from the structure of LC defined in RFC8092, in
> which only the Local part 1/local part 2 of one Global Administrator is
> operator-defined.*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 16 Mar 2021 00:03:04 +0000

Basically, we want to make a better extended community.
The extended community was fine when it was invented.

It allowed a BGP speaker to be uniquely identified and 2 more octets of data.
Since RFC 6286, 8 octets are required to identify a BGP speaker: ASN + BGP identifier.

Another problem with communities in general is containing them within
a small set of ASes where they are intended to be used.
Communities often leak to the wider internet, where they are not wanted and just
use up resources.
Thus many ISPs just filter all communities except the few they are contracted to accept.
So, we invented transitive/non-transitive extended communities.
non-transitive is fine, because many are used just within a single AS.
Then for several reasons, many organizations end up with multiple ASes.
These organizations can't use non-transitive communities within their set of ASes.
Transitive communities still go too far, so need to be carefully controlled.
Basically, Community transitivity is an operational burden.
We want to ease that burden by adding 2 more transitivities:
. One-time transitivity
. Administration transitivity

This draft is a proposal to use large communities to make a better extended community.
The number of data bytes (10) versus discriminator bits (6) is a tradeoff that I
think is reasonable.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Monday, March 15, 2021 1:05 AM
To: Jakob Heitz (jheitz) <[email-masked]>; 'Brian Dickson' <[email-masked]>
Cc: 'IETF IDR' <[email-masked]>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

From: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 15, 2021 1:29 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Brian Dickson' <[email-masked]<mailto:[email-masked]>>
Cc: 'IETF IDR' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Regards,
Jakob.

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, March 14, 2021 7:14 PM
To: 'Brian Dickson' <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; 'IETF IDR' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 16 Mar 2021 00:54:45 +0000

In RFC 8092, the Global Administrator defines the function
of the community, the meaning of the data fields.

https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02
does not require a Global Administrator, because the function
of the community, the meaning of the fields, will be defined
by standards action and not by an AS.

In
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04
the ASN is not the Global Administrator of the function of the community.
It is the AS that sent the community.

No flip-flop. This concept is key. ASN != GA. WKLC needs no GA.

Your suggestion to update RFC 8092 is a good one. Thanks.

Each WKLC begins with the bit pattern 111101.
If we can be sure that no Global Administrator ASN beginning with that bit
pattern exists, then the WKLC can be distinguished from the LC.

The data fields in a WKLC will not be defined by any Global Administrator.
They will be defined by standards action when a specific WKLC is defined.

Most of your other questions stem from the assumption that ASN == GA.
If not, please ask again.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Monday, March 15, 2021 3:34 PM
To: Jakob Heitz (jheitz) <jheitz=[email-masked]>
Cc: IETF IDR <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi Jacob

Do you think it would make sense to make this an experimental draft and as it matures in testing the leak mitigation we can advance to standards track.

The WKLC format change reason as you stated to flip flop the global and local part as per GROW leak detection proposal to use the WKLC to primary goal of community usage would be for “route leak detection” and per the leak draft as you stated the reason for the global and local part flip flop is so that the field is prevent the legitimate AS from having the same AS field as the leak routes signaling and tagging.

Is this draft updating RFC 8092 and if it is not it is really confusing for any reader as it does seem that it is being updated to this new format.

How would legitimate traffic use RFC 8092 format and non legitimate use this new draft format of RFC 8092 is being updated.

Also how can you maintain 2 completely different formats for large communities one for legitimate following RFC 8092 and one for leak draft using flip flopped fields.  Or is RFC 8092 being updated and this is a new format being proposed.  We should state if this draft is updating RFC 8092.

Also in Section 2 encoding the Data fields are not defined as global or local.  Are the three fields open and not defined maybe to used for global or local at the operators discretion?

It appears the leak draft defined the 10 byte 3 data fields as NN1:NN2:ASN however your draft keeps it wide open for the operator to whatever it chooses for the 10 byte field.   Would that make the RegEx match complicated and break RegEx matching as now you don’t know what field is what do you don’t know what to match on.  I can see the advantage idea of the flexibility of not defining the 3 data fields but I am not sure that work with RegEx matching.

In thread was mentioned 2 ASN fields mentioned by Brian which does seem strange.  Usually the ASN data field is set to the originator ASN that is doing the marking.

So from RFC 8092 to this proposal to account for the route leaking issue solution WKLC we go from 3 data fields and 12 bytes ASN:NN1:NN2 to 3 data fields 10 bytes NN1:NN2:ASN using the first two bytes for flags and WKLC byte.

In the draft in some spots it says the 10 bytes data field is for WKLC but can’t it be used for any large community usage.

The goal of RFC 8092 was to make the data field larger for 4 byte ASNs but does not specifically addressing WKLC.

All of these questions need to be made more clear in this draft before it can be adopted.

The leak draft proposes one format idea for WKLC format, however  I don’t understand why we are jumping from a standards perspective on this one idea to flip flop the format or make it open with no defined structure as a solution to mitigate the route leaking.

The leak detection draft lacks guidance as to why this DO format was chosen and does not propose any other ideas or options for leak mitigation.

In the leak draft section 3 of community versus attribute and I agree that a new path attribute would be the way to go but as stated that would require code upgrades and longer lead time for operators to implement.

It does seem like a rush to get something pushed out as a stop gap measure “standards bandaid” without thoroughly thinking through all the nuances and possible ramifications of this flip flop or open ended concept.

I agree that some thought was put into the solution comparing drop leak detection versus deprioritization and I agree the RFC 8092 LC is the best method for the solution at this point, but I am not convinced on the flip/flop format DO community style for route leak mitigation.  Also we stated how would RegEx match work if you don’t know which field is the global field and the high field is the local field.  I cannot see this working.

As with RegEx you can match on any digit in the RFC 8092 style AS:NN1:NN2 versus the flip/flop idea NN1:NN3:AS.

In the draft as the fields are open ended, how are we calculating that WKLC uses the number of ASNs listed below.

As all communities to date have always follows the AS:NN Global:Local part I am not sure  why the drastic change in format.

Kind Regards

Gyan

On Mon, Mar 15, 2021 at 1:30 AM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jakob.

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Mar 2021 01:10:07 -0400

Hi Jacob

Comments in-line

> Basically, we want to make a better extended community.

    Gyan> Understood.  Note that RFC 1977 Standard BGP communities are
widely deployed within enterprises and across the internet by service
providers wherever Global table routing is utilized.  Standard communities
have work very well over the last 20+ years and are still fairly
ubiquitously deployed.

Extended communities are only used and deployed for VPN overlay RT import
for private MPLS and Public MPLS where operators carry the internet table
in a VPN overlay any-any routing which is common with Tier-1, Tier-2 and
Tier-3 providers.

Extended communities have done well over the years until 4 byte ASN came
along and thus support for 4 byte extended community data field in the 8
byte extended community with 6 bytes available yielded 4 octet GA and 2
octet LA.

Thus the need came for a larger data field for extended community which
then came RFC 8092 with 12 octets and 3 4 byte data fields

> Communities often leak to the wider internet, where they are not wanted

    Gyan> Not true as BGP community propagation always required a manual
CLI for send-community for the communities to be advertised.  So explicit
controls were built in.  As well as the ability to send no-export additive
community  to block advertisement to external peers as well as no-advertise
community to block community advertisement to any peers eBGP or iBGP.  Also
all operators both  service providers and enterprises and the concept of
Trust boundary as far as communities as you don’t trust communities coming
from your customers unless a specific rule exists for special multi homing
scenarios and with that the best practice no-trust rule by operators was to
reset the community tag inbound to easily block any communities sent by
customers.  In cases where their is a trust relationship the set  is done
but with additive option so the customer tag can be forwarded to the
internet if desired per provisioning agreement.

> Thus many ISPs just filter all communities except the few they are
     Gyan> Agreer

> So, we invented transitive/non-transitive extended communities.
    Gyan> BGP communities are optional transitive

> non-transitive is fine, because many are used just within a single AS.

     Gyan> BGP communities are natively optional transitive but you can
block the community or choose not to advertise outside the AS by not doing
a BGP send-community.

> These organizations can't use non-transitive communities within their set
    Gyan> As I stated BGP communities are optional transitive attributes

> Transitive communities still go too far, so need to be carefully
 Gyan> As stated they can be easily controlled by not using CLI
send-community to propagate the communities

> Basically, Community transitivity is an operational burden.
Gyan> As I stated not at all a burden as you have plenty of controls built
into use of communities to propagate or not propagate to the internet.

>  Gyan>  I am not understanding the problem.  Can you please restate the
> problem you are trying to solve based on my feedback given that we have
> plenty of built in controls with communities.
>

    Gyan> BGP communities both standard and extended 2 byte AS communities
work fine and have been fine for decades.  The gap being solved with RFC
8092 large communities is with 4 byte AS and the need for a larger data
field.

>  Gyan>  Let’s continue the discussion to understand the problem statement
> fully as to what is broken and what we are trying to fix.
>
> Regards,
>
> Jakob.
>
>
>
> *Sent:* Monday, March 15, 2021 1:05 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; 'Brian Dickson' <
> [email-masked]>
> *Cc:* 'IETF IDR' <[email-masked]>
> I think your purpose is to define 256 WKLC, each can has its own
> Data1/Data2/Data3 definition to carry some additional information for the
> specified WKLC.
>
> To accomplish this, you should reserve  4093640704 (0xF4000000) to
> 4160749567 (0xF7FFFFFF) 4-bytes AS number, which can’t be allocated for
> the legitimate usage by operators.
>
>
>
> The reason to get such results is that you want to define the additional “Data
> 1” field from the  “Global Administrator”, but there is no description to
> explain the necessary.  Brian gave some potential examples in this thread
> and I think expanding them more clearly in your draft maybe more
> convincible.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *Sent:* Monday, March 15, 2021 1:29 PM
> *To:* Aijun Wang <[email-masked]>; 'Brian Dickson' <
> [email-masked]>
> *Cc:* 'IETF IDR' <[email-masked]>
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Mar 2021 01:40:47 -0400

Hi Jacob

In-line comments

I think we both agree that this draft should update RFC 8092 so it does not
add confusion as to the standard as your are completely revamping the
format of the data fields all of that needs to be properly documented.

On Mon, Mar 15, 2021 at 8:54 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

>  Gyan> if this draft is updating RFC 8092 all of the changes and updates
> need to be part of this document as part of the specification being changed
> and not referencing other documents as normative or informative for the
> actual proposed changes.  All of that has to be included in this draft
> proposal.
>
In
>  Gyan>  Historically and to date all communities both standard and
> extended 2 byte and 4 byte AS the ASN as it had been the GA left field in
> the data fields
>
> It has always been the AS that is setting the community is the originator
and Global Administrator of the community and NOT the AS that sends the
community as the community is being propagated hop by hop each node can
tack on an additive community or pass the string upstream with their GA
value added to the community string.  So it’s the “originator AS” is the
Global Administrator and that is how it had been historically from Day 1.

>
>  Gyan>  See my comments above.  I don’t agree that the ASN that sets the
> community is not the Global Administrator of the community.
>
> Gyan> Agreed.  Thanks
>  Gyan> Ok.  Makes sense. the pieces of the puzzle are coming together.
> Please explain that idea better with updated verbiage.
>

    Gyan> I don’t agree with your reasoning as the main purpose of the
Global Administrator for troubleshooting is knowing which AS node
originator set the community.  The Global Adminstrator field is critical
for troubleshooting.

>  Gyan>  So you are saying that their will  not be an explicitly defined
> Global Administrator field however if the operator chooses to use one of
> the data fields as a Global Administrator field so be it as the data field
> are open and can be set to anything.  Even with today’s standard and
> extended communities the fields  RT types 0, 1, 2 the fields can be set by
> the operators to anything the operators want to use the fields for however
> the RFC guidelines of Global Administrator field and local field almost
> 99.9% of the time as always been followed.  That being said I don’t see any
> harm as the operators can set and do whatever we want with the 10 bytes but
> I think it’s a good idea to keep in sync with the historical precedence
> that has existed for decades with the Global Administrative and Local
> fields.
>

    Gyan> Yes most have been related to the ASN==GA.

> If not, please ask again.

Gyan> Will do

>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Monday, March 15, 2021 3:34 PM
> *To:* Jakob Heitz (jheitz) <jheitz=[email-masked]>
> *Cc:* IETF IDR <[email-masked]>
> Is this draft updating RFC 8092 and if it is not it is really confusing
> for any reader as it does seem that it is being updated to this new format.
>
>
>
> The leak detection draft lacks guidance as to why this DO format was
> chosen and does not propose any other ideas or options for leak mitigation.
>
>
>
> In the draft as the fields are open ended, how are we calculating that
> WKLC uses the number of ASNs listed below.
>
>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 16 Mar 2021 05:57:09 +0000

A story if I may.
When I started at Cisco, I wrote the code for Graceful Shutdown.
This was strongly impressed upon me: Operators do not like junk attributes leaking
from far corners of the internet. Make sure you add plenty of safety to prevent
the Graceful Shutdown community from leaking out beyond its intended scope.
This sentiment was built from having to create the "send-community-ebgp" command
that you reference below. Still, when an operator uses that command, they have
to be careful what they send. Every new community used must be carefully
filtered at all inter-AS points.

Another example: the DMZ link-bandwidth extended community is non-transitive.
However, the place it is most useful is across AS boundaries. But only the first boundary.
So, we had to write code to specially send this extcomm across the AS boundary
where the extcomm is originated.

It is this experience with inadequate community transitivity that led me to
devise the extra transitivities.

Regards,
Jakob.

Sent: Monday, March 15, 2021 10:10 PM

Hi Jacob

Comments in-line

On Mon, Mar 15, 2021 at 8:03 PM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:
Basically, we want to make a better extended community.

    Gyan> Understood.  Note that RFC 1977 Standard BGP communities are widely deployed within enterprises and across the internet by service providers wherever Global table routing is utilized.  Standard communities have work very well over the last 20+ years and are still fairly ubiquitously deployed.

Extended communities are only used and deployed for VPN overlay RT import for private MPLS and Public MPLS where operators carry the internet table in a VPN overlay any-any routing which is common with Tier-1, Tier-2 and Tier-3 providers.

Extended communities have done well over the years until 4 byte ASN came along and thus support for 4 byte extended community data field in the 8 byte extended community with 6 bytes available yielded 4 octet GA and 2 octet LA.

Thus the need came for a larger data field for extended community which then came RFC 8092 with 12 octets and 3 4 byte data fields
The extended community was fine when it was invented.

    Gyan> Not true as BGP community propagation always required a manual CLI for send-community for the communities to be advertised.  So explicit controls were built in.  As well as the ability to send no-export additive community  to block advertisement to external peers as well as no-advertise community to block community advertisement to any peers eBGP or iBGP.  Also all operators both  service providers and enterprises and the concept of Trust boundary as far as communities as you don’t trust communities coming from your customers unless a specific rule exists for special multi homing scenarios and with that the best practice no-trust rule by operators was to reset the community tag inbound to easily block any communities sent by customers.  In cases where their is a trust relationship the set  is done but with additive option so the customer tag can be forwarded to the internet if desired per provisioning agreement.
use up resources.

     Gyan> BGP communities are natively optional transitive but you can block the community or choose not to advertise outside the AS by not doing a BGP send-community.
Then for several reasons, many organizations end up with multiple ASes.
These organizations can't use non-transitive communities within their set of ASes.
    Gyan> As I stated BGP communities are optional transitive attributes
Transitive communities still go too far, so need to be carefully controlled.
 Gyan> As stated they can be easily controlled by not using CLI send-community to propagate the communities
Basically, Community transitivity is an operational burden.
Gyan> As I stated not at all a burden as you have plenty of controls built into use of communities to propagate or not propagate to the internet.
We want to ease that burden by adding 2 more transitivities:
. One-time transitivity
. Administration transitivity
 Gyan>  I am not understanding the problem.  Can you please restate the problem you are trying to solve based on my feedback given that we have plenty of built in controls with communities.
This draft is a proposal to use large communities to make a better extended community.

    Gyan> BGP communities both standard and extended 2 byte AS communities work fine and have been fine for decades.  The gap being solved with RFC 8092 large communities is with 4 byte AS and the need for a larger data field.
The number of data bytes (10) versus discriminator bits (6) is a tradeoff that I
think is reasonable.
 Gyan>  Let’s continue the discussion to understand the problem statement fully as to what is broken and what we are trying to fix.
Regards,
Jakob.

To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; 'Brian Dickson' <[email-masked]<mailto:[email-masked]>>

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Mar 2021 14:43:07 -0400

Thanks Jacob for the history and agree  that attribute leaking especially
communities leaking and careful filtering at all exit points  is very
important to operators.

Kind Regards

Gyan

On Tue, Mar 16, 2021 at 1:57 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *Sent:* Monday, March 15, 2021 10:10 PM
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Mar 2021 15:22:25 -0400

Jacob

In my last point I made regarding the 10 byte data fields as anyone can
stuff anything into the data fields literally any value as has existed with
all communities from standard to extended  types 0,1,2 fo now large
communities I think it still makes sense to keep the structure of GA and LA
nomenclature in the fields from a standards perspective. Also by not doing
so I think even the other communities standards nomenclature may erode and
start to not use the  GA==ASN LA== nomenclature in the data fields.

So I don’t think we want to set a negative precedence by not keeping the
nomenclature in place in the RFC 8092 update.  I don’t see any harm in
keeping it in place.

Gyan

On Tue, Mar 16, 2021 at 2:43 PM Gyan Mishra <[email-masked]> wrote:

>> Gyan> As I stated not at all a burden as you have plenty of controls
>> built into use of communities to propagate or not propagate to the internet.
>>
>>     Gyan> BGP communities both standard and extended 2 byte AS
>> communities work fine and have been fine for decades.  The gap being solved
>> with RFC 8092 large communities is with 4 byte AS and the need for a larger
>> data field.
>>
>> The reason to get such results is that you want to define the additional
>> “Data 1” field from the  “Global Administrator”, but there is no
>> description to explain the necessary.  Brian gave some potential examples
>> in this thread and I think expanding them more clearly in your draft maybe
>> more convincible.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> The range of reserved ASNs occupies two bits of the upper 8 bits, plus
>> the entirety of the the next 24 bits in its range.
>>
>> Having the elements be aligned on the 32-bit boundary, and having TBD1
>> and TBD2 be fixed values, permits LC matching using a patterns of either
>> In other words, this structure choice is forced by router
>> implementations, and really not appropriate to second-guess. It isn't up
>> for negotiation, as this is a necessary requirement for the first use case.
>>
>>
>>
>> In particular, it is possible that other WKLCs require two ASN data
>> values in their encoding (such as a source ASN and a destination ASN), and

*Gyan Mishra*

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Mar 2021 14:58:19 -0700

> start to not use the  GA==ASN LA== nomenclature in the data fields.

Hi, Gyan,

I respectfully disagree, very strongly.

Consider that the original BGP Communities (from RFC 1997) has the
following:

   The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

   The rest of the community attribute values shall be encoded using an
   autonomous system number in the first two octets.

The proposal we are discussing, is EXACTLY the same. It is setting aside a
range for use in a way that is distinct from the main range which
correspond to ASNs.

The fact that 8092 DIDN'T include a reserved range, is the reason we need
this, and updating 8092 is the correct (IMNSHO) approach.

It means that, excluding the reserved range, the GA field refers to ASNs,
and for the reserved range, the "GA" is whatever the corresponding RFC(s)
say it is.

Brian

P.S. The need to use LCs as opposed to defining some other attribute, is
precisely because LCs are deployed by router vendors. The route-leaks issue
has been a problem since BGP version 4 was introduced. Waiting another
cycle or two of software deployments isn't really acceptable, given that
operators have already indicated that they WANT these LCs, and are WAITING
ANXIOUSLY for this so they can deploy it.

>>> Extended communities are only used and deployed for VPN overlay RT
>>> import for private MPLS and Public MPLS where operators carry the internet
>>> table in a VPN overlay any-any routing which is common with Tier-1, Tier-2
>>> and Tier-3 providers.
>>>
>>>
>>>
>>>  Gyan>  Let’s continue the discussion to understand the problem
>>> statement fully as to what is broken and what we are trying to fix.
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> It is to prevent WKLCs from having the same Global Administrator field
>>> as a legitimate AS trying to distribute its LC.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakob.
>>>
>>>
>>>
>>> The TBD2 is a single value out of a 32-bit range which will be in its
>>> own (new) registry. Having a registry allows for future uses in the context
>>> of TBD1, allowing new kinds of LC's in this bigger registered range.
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Mar 2021 00:32:19 -0400

Hi Brian

Thank you for the explaining.

> range for use in a way that is distinct from the main range which

Gyan> I  am with you on the reasoning and it completely makes sense to have
a Reserved/Type field.

 I think it would be good to add verbiage in the description from RFC 4360
and RFC 5668  8 byte extended community with the two highest order bytes
reserved for the type field and the remaining 6 bytes for the data field.
I see the parity with T bit which the type high has the T transitive single
bit and here 2 bits and the type low for extended community sub types, and
with this draft the WKLC extended community type field,  255 types agreed
more then enough types as we only have 22 extended communities today.

Add this verbiage would help in understanding the type field reused again
enumeration concept.  Nothing new but still should be stated the
enumeration is used below.

“ The two members in the tuple <Type, Value> should be enumerated to specify
any community value. The remaining octets of the community interpreted
based on the value of the Type field.”

> this, and updating 8092 is the correct (IMNSHO) approach.

   Gyan> Understood.  Agreed we need the RFC 4360 and RFC 5668 like “type
field”.  The type field has the T bit and am good with now having 2 bits
for transitive and having the 2 additional scenario.

> and for the reserved range, the "GA" is whatever the corresponding RFC(s)

   Gyan> Agreed we need the reserved field which is really identical
function to the the RFC 4360 and RFC 5668 like “type field”. You may want
to borrow verbiage from those drafts and call it a type field and not a
reserved field as reserved only refers to MSB 111101 WKLC field and defines
255 different types of extended communities.

So any LC with 111101 MSB is a WKLC Reserved range for WKLC “whatever the
RFC states for IANA range of reserved ASNs” and so any community that is
not 111101 MSB so MSB bits I think inverse of the bits is LC=000010 or
000000 would be LC refers to all other non reserved  “ASN”.

So as this draft not just addressing the WKLC leak issue it is also
updating RFC 8092, so it has to talk to that update representing both the
WKLC communities which is a subset of the in total LC entire range which we
are with the 6 MSB bits making WKLC and LC completely mutually exclusive of
each other for the leak issue.

So since the WKLC is really a Type ID for both WKLC reserved range and for
non reserved range regular AS range based on the MSB 6 bit setting I think
calling the WKLC field a “Type” field makes sense.

As the MSB 6 bits is what determines WGLC or Non WGLC exclusive ranges I
don’t see why you could still have nomenclature make it LC1:LC2:ASN

As you stated the RFC standard defines the WGLC range so you can make it
whatever you like.

Add verbiage to make that more clear with the two higher order bytes and
the bit representation for WKLC versus LC.

As mentioned that there are today 22 types of extended communities is the
goal of LC to be used for all of those types of use cases of sub type
fields defined in RFC 4360 and RFC 5668 and RFC 7153 IANA registers for
extended communities then I think their is a lot more work to be done with
this draft.

I think it make sense to have a type high and type low  sub type field
defined in RFC 4360 and RFC 5668 so that operators have the flexibility to
use Large communities for the existing 22 extended communities used today
can have type and sub type mapped over to LC format.  I think even moreso
for 4 byte as the data field is much mor limiting with GA being 4 bytes, LC
is only 2 bytes.

I believe operators would like to not only use LC for global table routing
where standard communities is predominantly used, but moreso for the 22
different extended community types that exist today and growing.

I think the 8 bits for WKLC field is sufficient but I think we need to
figure out how to redesign the format to accommodate the type high and type
low  sub type field defined in RFC 4360 and RFC 5668

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

I support WG adoption of this draft once it has been updated,  however at
this time I think this draft needs significant updates in the verbiage and
explanation of the proposal as it is now updating RFC 8092.

>>> Thanks Jacob for the history and agree  that attribute leaking
>>> especially communities leaking and careful filtering at all exit points  is
>>> very important to operators.
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>>> Extended communities have done well over the years until 4 byte ASN
>>>> came along and thus support for 4 byte extended community data field in the
>>>> 8 byte extended community with 6 bytes available yielded 4 octet GA and 2
>>>> octet LA.
>>>>
>>>>
>>>>
>>>>     Gyan> Not true as BGP community propagation always required a
>>>> manual CLI for send-community for the communities to be advertised.  So
>>>> explicit controls were built in.  As well as the ability to send no-export
>>>> additive community  to block advertisement to external peers as well as
>>>> no-advertise community to block community advertisement to any peers eBGP
>>>> or iBGP.  Also all operators both  service providers and enterprises and
>>>> the concept of Trust boundary as far as communities as you don’t trust
>>>> communities coming from your customers unless a specific rule exists for
>>>> special multi homing scenarios and with that the best practice no-trust
>>>> rule by operators was to reset the community tag inbound to easily block
>>>> any communities sent by customers.  In cases where their is a trust
>>>> relationship the set  is done but with additive option so the customer tag
>>>> can be forwarded to the internet if desired per provisioning agreement.
>>>>
>>>> use up resources.
>>>>
>>>> 4160749567 (0xF7FFFFFF) 4-bytes AS number, which can’t be allocated
>>>> for the legitimate usage by operators.
>>>>
>>>>
>>>>
>>>> The reason to get such results is that you want to define the
>>>> additional “Data 1” field from the  “Global Administrator”, but there
>>>> is no description to explain the necessary.  Brian gave some potential
>>>> examples in this thread and I think expanding them more clearly in your
>>>> draft maybe more convincible.
>>>>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>>
>>>> Aijun Wang
>>>>
>>>> China Telecom
>>>>
>>>>
>>>>
>>>> *Cc:* Jakob Heitz (jheitz) <[email-masked]>; 'IETF IDR' <[email-masked]
>>>> >
>>>> The initial use case is to establish a structured value of
>>>> TBD1:TBD2:ASN for the route-leak-detection-mitigation (as that draft
>>>> explains).
>>>>
>>>> *[WAJ] You should state also the reason that such sub-registry under
>>>> one well-known LC.  Describe some examples may be helpful.  DO community is
>>>> one example, but there still also no more explanation.*
>>>>
>>>>
>>>>
>>>> However, the router implementations, for the most part, permit
>>>> filtering of LCs on the basis of 3 32-bit values, where either literal
>>>> values or wildcards can be used.
>>>>
>>>> This would require re-design of WKLCs at a later date, and it may not
>>>> be possible due to existing usage or reservations of WKLCs.
>>>>
>>>>
>>>>
>>>> By providing more octets to EACH WKLC, this problem is prevented.
>>>> Making data allocations on power-of-two boundaries at the highest order is
>>>> You cannot aggregate that which was not initially allocated in a
>>>> fashion suitable for aggregation. This was one major outcome of the IP
>>>> allocation strategies prior to CIDR addressing for IPv4 address space. We
>>>> would do well to learn from the mistakes of others, particularly when those
>>>> mistakes were effectively repeated in the ASN space already (16 bits to 32
>>>> bits, because the initial assumption was 16 bits would be sufficient).
>>>>
>>>> The original LC definition is only applicable to "actual" ASNs as
>>>> Global Administrator. RFC8092 says only "intended", and that the value
>>>> "SHOULD" be an ASN.
>>>>
>>>> Since this proposal sets aside a range of ASNs as a group, the
>>>> structure of LCs covering that range can be redefined accordingly, as long
>>>> as that redefinition is scoped to that range of ASNs.
>>>>
>>>> *[WAJ] This is different from the structure of LC defined in RFC8092,
>>>> in which only the Local part 1/local part 2 of one Global Administrator is
>>>> operator-defined.*
>>>>
>>>>
>>>>
>>>> The other draft is for the use of the first assigned WKLC values
>>>> (single ID plus the Transitive Bit values).
>>>>
>>>>
>>>>
>>>> And, what the reason to assign the “111101”value in the first 6bit
>>>> your encoding? It is not conformed to general definition of large
>>>> community, in which the first 4-bytes is to identify the Global
>>>> Administrator.
>>>>
>>>>
>>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>> Spring, MD
>>>
>>> --
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>

*Gyan Mishra*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 19 Mar 2021 01:13:07 +0000

Gyan,

The Global Administrator, or the leading octets in the community are the AS
that defines the community, not the AS that sends the community.

https://tools.ietf.org/html/rfc1997 page 3<https://tools.ietf.org/html/rfc1997%20page%203>
   encoded using an
   autonomous system number in the first two octets.  The semantics of
   the final two octets may be defined by the autonomous system

Also
https://onestep.net/communities/as701/
701:80 is defined by AS701 and sent by a customer to cause AS701 to set Local Pref to 80.

RFC1997 reserves two AS numbers (0 and 0xFFFF) to allow for well known communities:
   The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

So, we are not without precedent.

Your point about the ASN being useful for troubleshooting is a good one.
I will add to the draft the sentence:
"The definition of each WKLC should consider including the BGP identifier
and/or the ASN of the BGP speaker that originates the WKLC value in the
data fields of the WKLC for easier troubleshooting."
Let me know if you want a different text.

Regards,
Jakob.

From: Gyan Mishra <[email-masked]>
Sent: Monday, March 15, 2021 10:41 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: IETF IDR <[email-masked]>; Jakob Heitz (jheitz) <jheitz=[email-masked]>
Subject: [SUSPECTED SPAM] Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi Jacob

In-line comments

I think we both agree that this draft should update RFC 8092 so it does not add confusion as to the standard as your are completely revamping the format of the data fields all of that needs to be properly documented.

On Mon, Mar 15, 2021 at 8:54 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
In RFC 8092, the Global Administrator defines the function
of the community, the meaning of the data fields.

https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02
does not require a Global Administrator, because the function
of the community, the meaning of the fields, will be defined
by standards action and not by an AS.
 Gyan> if this draft is updating RFC 8092 all of the changes and updates need to be part of this document as part of the specification being changed and not referencing other documents as normative or informative for the actual proposed changes.  All of that has to be included in this draft proposal.
In
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04
the ASN is not the Global Administrator of the function of the community.
It is the AS that sent the community.
 Gyan>  Historically and to date all communities both standard and extended 2 byte and 4 byte AS the ASN as it had been the GA left field in the data fields
It has always been the AS that is setting the community is the originator and Global Administrator of the community and NOT the AS that sends the community as the community is being propagated hop by hop each node can tack on an additive community or pass the string upstream with their GA value added to the community string.  So it’s the “originator AS” is the Global Administrator and that is how it had been historically from Day 1.

No flip-flop. This concept is key. ASN != GA. WKLC needs no GA.
 Gyan>  See my comments above.  I don’t agree that the ASN that sets the community is not the Global Administrator of the community.
Your suggestion to update RFC 8092 is a good one. Thanks.
Gyan> Agreed.  Thanks
Each WKLC begins with the bit pattern 111101.
If we can be sure that no Global Administrator ASN beginning with that bit
pattern exists, then the WKLC can be distinguished from the LC.
 Gyan> Ok.  Makes sense. the pieces of the puzzle are coming together.  Please explain that idea better with updated verbiage.
The data fields in a WKLC will not be defined by any Global Administrator.

    Gyan> I don’t agree with your reasoning as the main purpose of the Global Administrator for troubleshooting is knowing which AS node originator set the community.  The Global Adminstrator field is critical for troubleshooting.
They will be defined by standards action when a specific WKLC is defined.
 Gyan>  So you are saying that their will  not be an explicitly defined Global Administrator field however if the operator chooses to use one of the data fields as a Global Administrator field so be it as the data field are open and can be set to anything.  Even with today’s standard and extended communities the fields  RT types 0, 1, 2 the fields can be set by the operators to anything the operators want to use the fields for however the RFC guidelines of Global Administrator field and local field almost 99.9% of the time as always been followed.  That being said I don’t see any harm as the operators can set and do whatever we want with the 10 bytes but I think it’s a good idea to keep in sync with the historical precedence that has existed for decades with the Global Administrative and Local fields.
Most of your other questions stem from the assumption that ASN == GA.

Gyan> Will do

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Monday, March 15, 2021 3:34 PM
To: Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>>
Cc: IETF IDR <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi Jacob

Kind Regards

Gyan

Regards,
Jakob.

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Mar 2021 12:29:53 -0400

WKLC authors,

Let me use Brian's text here as a starting point to raise issues about
interpreting WKLC with regard to their transitivity bits.  I don't believe
the issue here is irreconcilable, but it does play to a point Brian was
illustrating and that it somewhat dilutes the deployed feeature argument.

> this is a necessary requirement for the first use case.

For reference, the layout of a WKLC from the draft 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
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |1 1 1 1 0 1| T |    WKLC ID    |          Data 1               |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 2                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 3                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A property that extended communities had as a result of how the authors
designed the feature, and later firmed up by Eric Rosen as part of registry
work was that a given extended community did NOT have a guarantee of the
same semantics when you had a transitive vs. a non-transitive version.

If it did, using link-bandwidth as an example, one's code would treat the
transitivity bit as a "don't care" for purposes of comparison.  I'm not
aware of any implementation that does this.[1]

The behavior of the transitivity bits for WKLC isn't directly discussed in
the document in terms of whether they have "don't care" semantics or not.

WKLC in particular discusses changing transitivity flags:

:         3 - One-time Transitive: The WKLC is transitive across ASes
:             under the same administration and into an AS under the
:             neighboring administration, but not into an AS under a
:             further administration.  A BGP speaker that receives a WKLC
:             with transitivity 3 on an external BGP session on an
:             administrative boundary SHOULD change the transitivity to 2.

The implication here leans toward this meaning they're "don't care", but
that may be my interpretation.

This primarily is an issue for "singleton" communities, like link-bandwidth.
While that may not be the target for the first use cases of the draft, it
should be part of the considerations for the feature's definition.

Related nit: Define your transitivity behavior for BGP confederations.

-- Jeff

[1] In the early 2000's when the extended community feature was being
disussed in IDR and I was a junior BGP dev, I did try to push the authors
toward treating transitivity as a don't care, and the sub-type field as a
"format field" for generic parsing.  Clearly my opinion didn't win out.
This results in extended community parsing being a snake's nest of special
cases with some generic patterns in use.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 19 Mar 2021 20:40:15 +0000

Jeff,

I'm glad you brought that up.
IMO, it's "don't care".

It matters in duplicate detection.
If the LC attribute contains a particular WKLC and the same WKLC
were to be added, say by a route-policy statement, but with a
different transitivity, do you add both of them or just one of
them and if so, which one do you keep?

I'm just going to stick my neck out and say:
keep the value with the longest transitivity.
So, in the draft, the highest numerical transitivity.

The reasoning:
Suppose you keep both. What is the behavior?
Assume that the decision taken by a BGP speaker at a WKLC match
does not depend on the transitivity, but only on the other bits.
If two identical community values exist in a community attribute,
then the decision is exactly the same as if there were only one.
Therefore discarding the value with the shorter transitivity
does not change routing behavior.

The transitivity should matter only in the decision to propagate
and no other decision. If that's a good assumption, then it should work.

I just made this up on the spot, so I might have missed something.
Shoot.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Friday, March 19, 2021 9:30 AM
To: [email-masked]
Subject: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

WKLC authors,

:       0                   1                   2                   3

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Mar 2021 17:43:42 -0400

Jakob,

> I just made this up on the spot, so I might have missed something.

I understand your thinking here.  A few related observations:

Since large communities will exist prior to this feature being added, policy
may occur on some implementation without WKLC that adds communities that
could be duplicate.  This means we already need to be ready to deal with
handling duplicates.

Your policy now has to deal with being able to alter scope.  E.g.:
if match wklc-foo:
	 set wklc-transitivity non-transitive;

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 19 Mar 2021 21:23:35 +0000

Yes.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Friday, March 19, 2021 2:44 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Jakob,

-- Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Mar 2021 19:56:32 -0400

Hi Jacob

In their local configuration as to administrative boundary versus not an
administrative boundary?

Or is it that any eBGP session is administrative boundary and every iBGP
session is a non administrative boundary?

With regards to transitive versus non transitive in the path selection if
their is a match on WKLC or duplicate with existing LC deployed, the higher
less transitive bit is always preferred correct?

        0 - Transitive: The WKLC is transitive across ASes.

        1 - Non-transitive: The WKLC is not transitive across ASes.

        2 - Administration Transitive: The WKLC is transitive across
            ASes under the same administration only.  By default, every
            AS boundary is also an administration boundary.  If an
            external BGP session is configured as a non-administrative
            boundary, then it will send and receive WKLCs with
            transitivity 2, else it will discard the WKLC from the
            UPDATE message.

        3 - One-time Transitive: The WKLC is transitive across ASes
            under the same administration and into an AS under the
            neighboring administration, but not into an AS under a
            further administration.  A BGP speaker that receives a WKLC
            with transitivity 3 on an external BGP session on an
            administrative boundary SHOULD change the transitivity to 2.

Thanks

Gyan

On Fri, Mar 19, 2021 at 5:23 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call
> for draft-heitz-idr-wklc-02 (3/9 to 3/23))
>
> Jakob,
>
-- 

*Gyan Mishra*

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 20 Mar 2021 00:21:13 +0000

A local configuration is required to make an eBGP session NOT
an administration boundary. This configuration should be
applied at both the sender and at the receiver.
Without configuration, every eBGP session is also treated
as an administration boundary.

An iBGP session is no boundary.

The transitivity bits should not be used for LC matching if the LC begins
with the WLC distinguisher bits 111101.
Such LCs should not exist in the public internet, because ASNs beginning
with those bits have not been assigned.

Regards,
Jakob.

From: Gyan Mishra <[email-masked]>
Sent: Friday, March 19, 2021 4:57 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; [email-masked]
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Hi Jacob

In their local configuration as to administrative boundary versus not an administrative boundary?

Or is it that any eBGP session is administrative boundary and every iBGP session is a non administrative boundary?

With regards to transitive versus non transitive in the path selection if their is a match on WKLC or duplicate with existing LC deployed, the higher less transitive bit is always preferred correct?

            UPDATE message.

Thanks

Gyan

On Fri, Mar 19, 2021 at 5:23 PM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:
Yes.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 19, 2021 2:44 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Jakob,

-- Jeff

Gyan Mishra

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Mar 2021 20:22:13 -0400

Thanks Jacob!

In my last email of questions can you review the questions related to the 6
MSB bits set for WKLC and any other bit combinations other than 111101
would  be a LC and that makes WKLC mutually exclusive of LC.  Is
my understanding correct?

Also see how does WKLC draft support the 22 different types of extended
communities defined myriad of sub type defined today in RFC 4360 RFC 5668
RFC 7153?

Gyan

On Thu, Mar 18, 2021 at 9:13 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> https://tools.ietf.org/html/rfc1997 page 3
>
>    encoded using an
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Monday, March 15, 2021 10:41 PM
> *Cc:* IETF IDR <[email-masked]>; Jakob Heitz (jheitz) <jheitz=
> [email-masked]>
> *Subject:* [SUSPECTED SPAM] Re: [Idr] Adoption call for
> draft-heitz-idr-wklc-02 (3/9 to 3/23)
>
>
>
>
>
> Hi Jacob
>
>
>
> In-line comments
>
>
>
> I think we both agree that this draft should update RFC 8092 so it does
> not add confusion as to the standard as your are completely revamping the
> *From:* Idr <[email-masked]> *On Behalf Of *Gyan Mishra
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 20 Mar 2021 00:38:36 +0000

Inline.

Regards,
Jakob.

From: Gyan Mishra <[email-masked]>
Sent: Friday, March 19, 2021 5:22 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: IETF IDR <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
Subject: Re: [SUSPECTED SPAM] Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Thanks Jacob!

In my last email of questions can you review the questions related to the 6 MSB bits set for WKLC and any other bit combinations other than 111101 would  be a LC and that makes WKLC mutually exclusive of LC.  Is my understanding correct?

[JH] Yes. this is analogous to a regular community that begins with 16 bits of 1 or 16 bits of 0.

Also see how does WKLC draft support the 22 different types of extended communities defined myriad of sub type defined today in RFC 4360 RFC 5668 RFC 7153?

[JH] I see no need to duplicate extended communities into WKLC.
If anyone feels the need to add up to 4 octets to any extended community
or to use the enhanced transitivity, then they are free to define a WKLC for it
using the standards procedure.

Gyan

On Thu, Mar 18, 2021 at 9:13 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

Also

Regards,
Jakob.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 15, 2021 10:41 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: IETF IDR <[email-masked]<mailto:[email-masked]>>; Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>>
Subject: [SUSPECTED SPAM] Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi Jacob

In-line comments

Gyan> Will do

Regards,
Jakob.

Hi Jacob

Kind Regards

Gyan

Regards,
Jakob.

Hi, Brian:

Best Regards

Aijun Wang
China Telecom

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Mar 2021 20:47:47 -0400

Hi Jakob

In line

Thanks

On Fri, Mar 19, 2021 at 8:38 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *Sent:* Friday, March 19, 2021 5:22 PM
> *Cc:* IETF IDR <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
> *Subject:* Re: [SUSPECTED SPAM] Re: [Idr] Adoption call for
> In my last email of questions can you review the questions related to the
> 6 MSB bits set for WKLC and any other bit combinations other than 111101
> Gyan> RFC 5568 4 byte AS support defining type 2 has only a 2 byte local
> administrative compare to type 0 for 2 byte AS has 4 byte local
> administrative.
>

   See RFC 8092 bottom of section 1 introduction

Since the adoption of four-octet ASNs [RFC6793
<https://tools.ietf.org/html/rfc6793>], the BGP Communities
   attribute can no longer accommodate the above encoding, as a two-
   octet word cannot fit a four-octet ASN.  The BGP Extended Communities
   attribute [RFC4360 <https://tools.ietf.org/html/rfc4360>] is also
unsuitable.  The six-octet length of the
   Extended Community value precludes the common operational practice of
   encoding four-octet ASNs in both the Global Administrator and the
   Local Administrator sub-fields.

   To address these shortcomings, this document defines a BGP Large
   Communities attribute encoded as an unordered set of one or more
   twelve-octet values, each consisting of a four-octet Global
   Administrator field and two four-octet operator-defined fields, each
   of which can be used to denote properties or actions significant to
   the operator of the AS assigning the values.

 My understanding is that this was the primary goal of LC and secondary
> goal was WKLC leak mitigation solution.
>
>
>
> Gyan
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Ben Maddison <[email-masked]>
Date: Sat, 20 Mar 2021 09:54:41 +0200

Hi Jakob,

> as an administration boundary.
I fear this may end up being a bit too binary.
Depending on the semantics that end up in WKLCs, a pair of operators may
need to treat a session as a boundary with respect to WKLC-A, but not
with respect to WKLC-B.
Without knowing exactly what semantics may be defined in the future,
it's rather hard to know whether this will be important or not.

> An iBGP session is no boundary.
CE-PE via iBGP in an IP-VPN?
This probably needs to be a configurable default too.

> with those bits have not been assigned.
Has the assumption that these don't exist in the wild wild DFZ been
checked?

One of the motivations for the shape of LCs was to give operators an
alternative to defining semantics in private/unallocated ASN namespaces,
so these *shouldn't* have appeared.
But I wouldn't put money on the fact that some bright spark hasn't gone
and polluted this range already.

Cheers,

Ben

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 21 Mar 2021 00:58:42 +0000

Any transitivity can be done with route-policy.

What started me thinking about transitivity was a few things.
1. Operators don't like totally transitive communities,
   because they will spread far, where they're not wanted.
   We had to implement a feature many years ago that
   blocked all communities by default at AS boundaries.
2. Link bandwidth extended community is non-transitive,
   but useful across a single AS boundary.
   We had to implement a feature to send it across the AS
   boundary where it was originated.
3. Some operators have several ASes.

Sriram's draft ideally needs 2 AS hop transitive.
It needs it by default, because if vendors block
it by default, it will never work.

I got 2 bits for transitivity and don't want to burn another bit
for it. So I'm thinking of replacing administration transitive with
2 AS hop transitive.

About bright sparks using ASNs they're not supposed to:
That's their mistake and will be their failure.
We cannot stop people attaching incorrect communities to routes.
We cannot let the possibility of bright sparks doing dumb things
impede progress.

Regards,
Jakob.

-----Original Message-----
From: Ben Maddison <benm=[email-masked]> 
Sent: Saturday, March 20, 2021 12:55 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; [email-masked]
Subject: Re: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

Hi Jakob,

Cheers,

Ben

---

From: Alexander Azimov <[email-masked]>
Date: Sun, 21 Mar 2021 19:29:06 +0300

Dear colleagues,

I've read the draft and discussion that have already happened on this
mailing list and IMO the document that should be simple stupid grow
overcomplicated.
I believe that the design principle of well-known large communities
should mimic the behavior of 'old' communities.

Why we can't define this registry as
65535:ID:Value, or, 4294967295:ID:Vaue?

I also don't feel in favor of adding the logic of transit-non-transit
behavior for the LC. I don't see use cases where it can improve routing
policy/filtering - the main use case of LC.
And another issue that looks for me very important, the RFC8642 states:

   When establishing new attributes similar to those in [RFC1997
<https://tools.ietf.org/html/rfc1997>] (large
   communities, wide communities, etc.), RFC authors should state
   explicitly how the new attribute is to be handled.

I have a strong feeling that this part is missed.

сб, 20 мар. 2021 г. в 03:48, Gyan Mishra <[email-masked]>:

> Since the adoption of four-octet ASNs [RFC6793 <https://tools.ietf.org/html/rfc6793>], the BGP Communities
>    attribute [RFC4360 <https://tools.ietf.org/html/rfc4360>] is also unsuitable.  The six-octet length of the
>> Do you think it would make sense to make this an experimental draft and
>> as it matures in testing the leak mitigation we can advance to standards
>> track.
>>
>>
>>
>>
>>
>> It appears the leak draft defined the 10 byte 3 data fields as
>> NN1:NN2:ASN however your draft keeps it wide open for the operator to
>> whatever it chooses for the 10 byte field.   Would that make the RegEx
>> match complicated and break RegEx matching as now you don’t know what field
>> is what do you don’t know what to match on.  I can see the advantage idea
>> of the flexibility of not defining the 3 data fields but I am not sure that
>> In the draft in some spots it says the 10 bytes data field is for WKLC
>> but can’t it be used for any large community usage.
>>
>>
>>
>> The goal of RFC 8092 was to make the data field larger for 4 byte ASNs
>> but does not specifically addressing WKLC.
>>
>>
>>
>> In the leak draft section 3 of community versus attribute and I agree
>> that a new path attribute would be the way to go but as stated that would
>> It does seem like a rush to get something pushed out as a stop gap
>> measure “standards bandaid” without thoroughly thinking through all the
>> nuances and possible ramifications of this flip flop or open ended concept.
>>
>>
>>
>> As all communities to date have always follows the AS:NN Global:Local
>> part I am not sure  why the drastic change in format.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Kind Regards
>>
>>
>>
>>
>>
>> Gyan
>>
>>
>>

-- 
Best regards,
Alexander Azimov

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 23 Mar 2021 15:01:40 +0000

> This draft is a proposal to use large communities to make a better 

the original LC RFC specifies a global administrator field.  This draft 
attempts to retrofit semantics into various bits in that field.  I can 
see why it's tempting to attempt this, but it introduces a significant 
degree of interpretation semantics and, more importantly, backwards 
incompatibility.

At the time when we were still discussing 
draft-heitz-idr-large-community, the issue of future flexibility and 
semantic interpretation was extensively discussed, and the consensus of 
the authors + working group was that it was more important to get a 
draft out there which implemented "deployed + simple" rather than going 
for a slightly more complex design which would have allowed future 
extensibility.

The opportunity to use a more flexible structure was not taken at the 
time, for good reasons, and we knew at the time what those long term 
consequences of those decisions would be.

Retrofitting this complexity into rfc8092 reopens these arguments, but 
from the point of view of watching the ship after it's sailing past the 
horizon.

If we need a better asn32-compatible extended community, then we should 
define a better, asn32-compatible extended community and do the job 
properly.  We should not try to claim that rfc8092 provides an 
appropriate framework for this, because it doesn't and because if we try 
to bend LCs in this way, it will leave us with a legacy of perpetual 
dysfunction.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Mar 2021 17:00:43 +0100

I must agree with Nick point of view in 100% here.

Indeed when discussions on LC were going on there was strong support from
operators stating this is what we want and it is good enough. Let's keep it
simple.

For more advanced including well known actions let's focus on wide
communities as they have public and private use of communities build in
from day one.

Many thx,
R.

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 23 Mar 2021 16:40:44 +0000

I support the adoption as a working group document.

From following the discussions on the list, I believe there is enough interest from the WG to have this work being adopted as a working group item. I believe all current issues discussed can be worked out while it is a WG document. As it looks to me though, I would like to see this draft updating RFC 8092 rather than standing alone. Especially where it introduces additional transitivity bits within the first bits of the attribute and I would like to see more clarity on that within the draft.

Oliver

-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday, March 9, 2021 at 5:17 AM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

https://datatracker.ietf.org/doc/draft-heitz-idr-wklc/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-heitz-idr-wklc%2F&data=04%7C01%7Coliver.borchert%40nist.gov%7C8a8e11e810df492fb8ff08d8e2e4976d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637508818745715782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=IPfIDxrFjrs03iADETClS1rQ2armk4SVB%2BhPktxrlpI%3D&reserved=0>

Cheers, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 24 Mar 2021 05:37:02 -0400

+1

Cheers,

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Mar 2021 15:17:54 -0400

Brian: 

<WG chair hat on> 

This brief justification for the ASN space even for 4-byte AS is not sufficient.   A separate draft will need to specify why so much ASN space that is managed by IANA. 

In the original work with route-leaks, John Scudder and I agreed to help the route-leaks folks obtain 2-8 ASNs specifically for the route leaks.  Modifying your grow draft will obtain approval for a small amount of special ASNs.   I have discussed your need with IANA so that we had a sense of whether it would be approved. 

Asking for 1/64 of the address space requires substantial justification as it significantly limits the future uses of 4 byte-AS.    

The IDR WG allotted private ASN space for uses within an AS (or a Confederation AS) that spans multiple uses.   If you can make use of this space + 2-8 AS, your proposal can go forward.  If not, a separate proposal will be needed to justify that amount of address space. 

Thank you for being clear in this discussion with Aijun. 

Sue 

<WG Chair hat off> 

From: Idr [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Friday, March 12, 2021 1:14 PM
To: Aijun Wang
Cc: IETF IDR
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <[email-masked]> wrote:

Hi, Jakob:

Brian

Regards,

Jakob.

Hi, Jakob:

Best Regards

Aijun Wang

China Telecom

Aijun Wang

China Telecom

Regards,

Jakob.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Mar 2021 12:41:56 -0700

On Fri, Mar 26, 2021 at 12:18 PM Susan Hares <[email-masked]> wrote:

> Brian:
>
>
>
> <WG chair hat on>
>
> This brief justification for the ASN space even for 4-byte AS is not
> sufficient.   A separate draft will need to specify why so much ASN space
> that is managed by IANA.
>
>
>
> In the original work with route-leaks, John Scudder and I agreed to help
> the route-leaks folks obtain 2-8 ASNs specifically for the route leaks.
> Modifying your grow draft will obtain approval for a small amount of
> special ASNs.   I have discussed your need with IANA so that we had a sense
> of whether it would be approved.
>
>
>
> Asking for 1/64 of the address space requires substantial justification as
> it significantly limits the future uses of 4 byte-AS.
>
>
>
> The IDR WG allotted private ASN space for uses within an AS (or a
> Confederation AS) that spans multiple uses.   If you can make use of this
> space + 2-8 AS, your proposal can go forward.  If not, a separate proposal
> will be needed to justify that amount of address space.
>
>
>

Would a request for reserving 255 ASNs for WKLC and establishing an WKLC
registry (which would maintain parity with the original WKC reservation) be
a reasonable compromise?
Our GROW draft would then request something on the order of 2-4 of those
values for the needs of the route-leaks draft.

Thanks for your consideration.

Brian
(The only hats I wear are the ones to keep the sun out of my eyes and off
my head. :-) )

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Brian Dickson
> *Sent:* Friday, March 12, 2021 1:14 PM
> *To:* Aijun Wang
> *Cc:* IETF IDR

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 30 Mar 2021 23:36:30 +0000

Best chance for Sriram is to do it with a new attribute.

Community fields semantics do not belong in router code.
They belong in operator code, which is route-policy/route-map.
As soon as you define any structure into the community,
then the semantics must be interpreted in router code.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Brian Dickson
Sent: Friday, March 26, 2021 12:42 PM
To: Susan Hares <[email-masked]>
Cc: IETF IDR <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Fri, Mar 26, 2021 at 12:18 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Brian:

<WG chair hat on>

Would a request for reserving 255 ASNs for WKLC and establishing an WKLC registry (which would maintain parity with the original WKC reservation) be a reasonable compromise?
Our GROW draft would then request something on the order of 2-4 of those values for the needs of the route-leaks draft.

Brian
(The only hats I wear are the ones to keep the sun out of my eyes and off my head. :-) )

Sue
<WG Chair hat off>

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Dickson
Sent: Friday, March 12, 2021 1:14 PM
To: Aijun Wang
Cc: IETF IDR
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Mar 2021 20:45:29 -0400

Hi Jacob

The last question I had asked about type 2 4 byte AS extended communities
defined in RFC 5568 due the 4 byte AS eating up an extra 2 bytes in the
Global Admin field you are only left with 2 bytes in the Local Admin
field.  RFC 8092 was supposed to solve that shortcoming with a larger local
administrative field.

As this draft is updating RFC 8092, I think it really should account for
shortcomings of 4 byte extended communities.  With large communities we
have 10 bytes of data fields even with the 2 high order bytes used we
should still be able to accommodate.

Thanks

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Mar 2021 15:39:51 +0200

Hey Jakob,

>   They belong in operator code, which is route-policy/route-map.

We clearly have different opinions on this part.

You keep stating that all route-policy must be typed by operator.

I am saying route-policy can be typed by operators from atomic match and
set primitives or route-policy can be smart enough to understand some
predefined policies. Especially if those are predefined in the RFCs. Think
of it in terms of pre-made policy templates like objects. They can be
enabled by default or disabled and enabled on a per needed/expected basis.

That way you do not need to write your policy each time from scratch :) Let
the router's vendor help you ...

I bring it here as that is also I think your key opposition to implementing
wide communities which can easily accommodate by design all requests
mentioned in this thread so far.

Best,
Robert.

On Wed, Mar 31, 2021 at 1:36 AM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Brian Dickson
> *Sent:* Friday, March 26, 2021 12:42 PM
> *To:* Susan Hares <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Mar 2021 11:02:39 -0400

Gyan,

> should still be able to accommodate.

Our current status quo with large communities perhaps should serve as a
cautionary tale for those who want to "move fast" and "keep it simple".

As Sue noted in her chairs' response, there was discussion about
transitivity, and about whether we wanted to set aside code space in the new
feature for special treatment.  The pattern we had as an example of such
special treatment is the space set aside for well known communities in RFC 1997.

The strong consensus of the working group and the rather fervent portion of
the operational community at that time was "keep it simple, ship it now".
We did.  The feature is now heavily deployed.  

We don't get to change such a feature easily, there's too many pieces of
running code that wouldn't respect the new semantics.  

One of the hardest thing about working on BGP is dealing with incremental
deployment circumstances.  We don't have a lot of easy options here.

draft-ietf-grow-route-leak-detection-mitigation quite nicely summarizes some
of the additional headaches of trying to force behaviors to fit into generic
community features.  From that document:

:    On the other hand, BGP Communities do not require a router OS update.
:    The potential disadvantage of using a Community for the route-leak
:    detection signal is that it is more likely to be dropped somewhere
:    along the way in the AS path.  Currently, the use of BGP Communities
:    is somewhat overloaded.  BGP Communities are already used for
:    numerous applications: different types of route marking, route policy
:    control, blackholing, etc.  It is observed that some ASes seem to
:    purposefully or accidentally remove BGP Communities on receipt,
:    sometimes well-known ones.  Perhaps this issue may be mitigated with
:    strong policy guidance related to the handling of Communities.
: 
:    Large Communities have much higher capacity, and therefore they are
:    likely to be less overloaded.  Hence, Large Community is proposed to
:    be used for route-leak detection.  This document suggests reserving
:    <TBD1> class for the purpose of transitive well-known Large
:    Communities that MUST NOT be stripped on ingress or egress.

Basically, "people do these things with communities that can break this
feature, if carried in communities".  "Don't do that" doesn't scale terribly
well.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 31 Mar 2021 17:38:46 +0000

My opinion is based on the fact that I write router code
and I wrote all the code and tests, including the route-policy code
(by far the biggest part) of the large-community code in IOS-XR.

I also know that too many people want too many different things
out of communities.

My key opposition to wide communities is that I realize how massive
a job it would be to implement. Coding it on the wire is trivial.
It's all the route-policy stuff, checking the myriad of tiny details
to ensure no conflicts, error detection and recovery that is the
nightmare that will never be right. It will be a cesspool of bugs.

I'm happy to fix any bugs in large community code. If you can just find one.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, March 31, 2021 6:40 AM
To: Jakob Heitz (jheitz) <jheitz=[email-masked]>
Cc: IETF IDR <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hey Jakob,

I am saying route-policy can be typed by operators from atomic match and set primitives or route-policy can be smart enough to understand some predefined policies. Especially if those are predefined in the RFCs. Think of it in terms of pre-made policy templates like objects. They can be enabled by default or disabled and enabled on a per needed/expected basis.

That way you do not need to write your policy each time from scratch :) Let the router's vendor help you ...

I bring it here as that is also I think your key opposition to implementing wide communities which can easily accommodate by design all requests mentioned in this thread so far.

Best,
Robert.

On Wed, Mar 31, 2021 at 1:36 AM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:
Best chance for Sriram is to do it with a new attribute.

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Dickson
Sent: Friday, March 26, 2021 12:42 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: IETF IDR <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

<WG chair hat on>

Brian

Sue
<WG Chair hat off>

Brian

Regards,
Jakob.

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

Regards,
Jakob.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 31 Mar 2021 18:37:18 -0400

Thanks Jeffrey that makes sense.

So in essence the main goal of the WKLC as it is new as well as would not
get overloaded with the RFC 8092 12 byte data field or proposed WKLC 10
byte data field much higher capacity as it is néw and  would only be used
 for route leak detection using the same semantics for WKLC as RFC 1997
special space. For the route leak signaling per GROW draft makes sense the
special transitivity feature for WKLC class that cannot be stripped.

Makes sense.

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*