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

[Gyan Mishra <[e-mail]>]

Hi Brian

Thank you for the explaining.

On Tue, Mar 16, 2021 at 5:58 PM Brian Dickson <[e-mail]>
wrote:

>
>
> On Tue, Mar 16, 2021 at 12:22 PM Gyan Mishra <[e-mail]>
> wrote:
>
>>
>> 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.
>>
>
>
> 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.
>

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

>
> The fact that 8092 DIDN'T include a reserved range, is the reason we need
> 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.

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

   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.

>
> 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.
>
>
>>
>> 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 <[e-mail]>
>> wrote:
>>
>>> 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) <[e-mail]>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> *From:* Idr <[e-mail]> *On Behalf Of * Gyan Mishra
>>>> *Sent:* Monday, March 15, 2021 10:10 PM
>>>> *To:* Jakob Heitz (jheitz) <jheitz=[e-mail]>
>>>> *Cc:* IETF IDR <[e-mail]>
>>>> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> Hi Jacob
>>>>
>>>>
>>>>
>>>> Comments in-line
>>>>
>>>>
>>>>
>>>> On Mon, Mar 15, 2021 at 8:03 PM Jakob Heitz (jheitz) <jheitz=
>>>> [e-mail]> 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.
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>     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.
>>>>
>>>> Thus many ISPs just filter all communities except the few they are
>>>> contracted to accept.
>>>>
>>>>      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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> *From:* Aijun Wang <[e-mail]>
>>>> *Sent:* Monday, March 15, 2021 1:05 AM
>>>> *To:* Jakob Heitz (jheitz) <[e-mail]>; 'Brian Dickson' <
>>>> [e-mail]>
>>>> *Cc:* 'IETF IDR' <[e-mail]>
>>>> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> 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) <[e-mail]>
>>>> *Sent:* Monday, March 15, 2021 1:29 PM
>>>> *To:* Aijun Wang <[e-mail]>; 'Brian Dickson' <
>>>> [e-mail]>
>>>> *Cc:* 'IETF IDR' <[e-mail]>
>>>> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> *[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)*).  *
>>>>
>>>>
>>>>
>>>> [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 <[e-mail]>
>>>> *Sent:* Sunday, March 14, 2021 7:14 PM
>>>> *To:* 'Brian Dickson' <[e-mail]>
>>>> *Cc:* Jakob Heitz (jheitz) <[e-mail]>; 'IETF IDR' <[e-mail]
>>>> >
>>>> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> 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 <[e-mail]>
>>>> *Sent:* Saturday, March 13, 2021 2:14 AM
>>>> *To:* Aijun Wang <[e-mail]>
>>>> *Cc:* Jakob Heitz (jheitz) <[e-mail]>; IETF IDR <[e-mail]>
>>>> *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 <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi, Jakob:
>>>>
>>>>
>>>>
>>>> *From:* Jakob Heitz (jheitz) <[e-mail]>
>>>> *Sent:* Friday, March 12, 2021 3:45 PM
>>>> *To:* Aijun Wang <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> 1.      It is small, not huge as explained in the draft.
>>>>
>>>> *[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] 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)*).  *
>>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>> *[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.
>>>>
>>>> *[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.*
>>>>
>>>>
>>>>
>>>> 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 <[e-mail]>
>>>> *Sent:* Thursday, March 11, 2021 11:16 PM
>>>> *To:* Jakob Heitz (jheitz) <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> 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:* [e-mail] <[e-mail]> *On Behalf Of *Aijun
>>>> Wang
>>>> *Sent:* Wednesday, March 10, 2021 9:38 PM
>>>> *To:* Jakob Heitz (jheitz) <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>>>> 3/23)
>>>>
>>>>
>>>>
>>>> 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) <[e-mail]>
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> 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 <[e-mail]>
>>>> *Sent:* Wednesday, March 10, 2021 12:11 AM
>>>> *To:* Jakob Heitz (jheitz) <[e-mail]>; 'Susan Hares' <
>>>> [e-mail]>; [e-mail]
>>>> *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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *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
>>>>
>>>>
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>> Spring, MD
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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