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

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 <hayabusagsm@gmail.com>:

>
> Hi Jakob
>
> In line
>
> Thanks
>
> On Fri, Mar 19, 2021 at 8:38 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
> wrote:
>
>> Inline.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>> *Sent:* Friday, March 19, 2021 5:22 PM
>> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *Cc:* IETF IDR <idr@ietf.org>; Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *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> 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
>>
>>
>>
>> On Thu, Mar 18, 2021 at 9:13 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
>> wrote:
>>
>> 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
>>
>>    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 <hayabusagsm@gmail.com>
>> *Sent:* Monday, March 15, 2021 10:41 PM
>> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *Cc:* IETF IDR <idr@ietf.org>; Jakob Heitz (jheitz) <jheitz=
>> 40cisco.com@dmarc.ietf.org>
>> *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) <jheitz@cisco.com>
>> 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> Yes most have been related to the ASN==GA.
>>
>> If not, please ask again.
>>
>>
>>
>> Gyan> Will do
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Gyan Mishra
>> *Sent:* Monday, March 15, 2021 3:34 PM
>> *To:* Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>
>> *Cc:* IETF IDR <idr@ietf.org>
>> *Subject:* Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to
>> 3/23)
>>
>>
>>
>>
>>
>> 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=
>> 40cisco.com@dmarc.ietf.org> 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)*).  *
>>
>>
>>
>> [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 <wangaijun@tsinghua.org.cn>
>> *Sent:* Sunday, March 14, 2021 7:14 PM
>> *To:* 'Brian Dickson' <brian.peter.dickson@gmail.com>
>> *Cc:* Jakob Heitz (jheitz) <jheitz@cisco.com>; 'IETF IDR' <idr@ietf.org>
>> *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 <brian.peter.dickson@gmail.com>
>> *Sent:* Saturday, March 13, 2021 2:14 AM
>> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
>> *Cc:* Jakob Heitz (jheitz) <jheitz@cisco.com>; IETF IDR <idr@ietf.org>
>> *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 <wangaijun@tsinghua.org.cn>
>> wrote:
>>
>> Hi, Jakob:
>>
>>
>>
>> *From:* Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *Sent:* Friday, March 12, 2021 3:45 PM
>> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
>> *Cc:* idr@ietf.org
>> *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 <wangaijun@tsinghua.org.cn>
>> *Sent:* Thursday, March 11, 2021 11:16 PM
>> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *Cc:* idr@ietf.org
>> *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:* idr-bounces@ietf.org <idr-bounces@ietf.org> *On Behalf Of *Aijun
>> Wang
>> *Sent:* Wednesday, March 10, 2021 9:38 PM
>> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
>> *Cc:* idr@ietf.org
>> *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) <jheitz@cisco.com> 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 <wangaijun@tsinghua.org.cn>
>> *Sent:* Wednesday, March 10, 2021 12:11 AM
>> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>; 'Susan Hares' <
>> shares@ndzh.com>; idr@ietf.org
>> *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
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> 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 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 Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *M 301 502-1347*
>>
>>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
Best regards,
Alexander Azimov