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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 31 March 2021 00:45 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2FF3A0C64 for <idr@ietfa.amsl.com>; Tue, 30 Mar 2021 17:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrtZwT4xVWoI for <idr@ietfa.amsl.com>; Tue, 30 Mar 2021 17:45:43 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7563A0C5B for <idr@ietf.org>; Tue, 30 Mar 2021 17:45:42 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id f2-20020a17090a4a82b02900c67bf8dc69so301184pjh.1 for <idr@ietf.org>; Tue, 30 Mar 2021 17:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8vfmX634gDdMBpjtradudGul2OQIBdBDKraJBU24PjI=; b=GYXk1IOK8Kp/ZBzfKx1eF263SxJZFzZrYklI4O/PiS7JzEN7VQwP49+PQqmhrIXhwM lXeBFoicMY8DGXhr5L2BducY4lgmkVsMwSTv6ecm3whga/X3S7W87qD/2GDaLq2kO1jZ 7daWSNv7nQS9Tj5VPOl7VbtKfRjoTcAOo6pfVrZF1pp2l7qwKTQw1Q1ZvA1463W5T0vv 37LodqsqMw8Q7hl8CZzJ/HsU9Nq92poONfEMMoEtkApTPXH51dp+DfXv2kIRRo3i5nmh fJ9N8MD18Hmsqw10+EKs6VvT8ylA3nEa5vhvUbx1J15TSMmDFL55HLt2sX/W5whg3V1l lbeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8vfmX634gDdMBpjtradudGul2OQIBdBDKraJBU24PjI=; b=QuqcI8zk6IZ5v57uF8ASXnUHpZCy9bpc/MebqmyqaHKIKNiNjswUZZ7nJCjTfuOc+P Qlu1VJpkLls6Y3SP8Jg3jmsKRiKGGdL3csb9Uuww43XRZx92DROw12WXnB5DXFbw/vPT QU3fg2A5uMV+aaY7W2648CEjgfHEPF0Gv7wORsE2V/yp+N68iFs42bH8Spa9HhgfR5HK PdCeWCIeTYxQhHXILAvOq14CF3g49vbq1r/CFyfvB+79oVB2KbDNSmjPU6iffPaXiY6b ZEACWNRn26URsvqlRmoQhuPIndwbP8DUxhpq75Lr5btz7EH3Xc0QxcspwxFIXmVkUIsq F/dA==
X-Gm-Message-State: AOAM530VzOUmwM5IQRUMKwKHBUA7IoUnNb2lUj6u2NEUNBwgUjHQ0KG3 Jd5cyaHesVO9fLA6Kv8fTkT51iknFtTnZUclHy4=
X-Google-Smtp-Source: ABdhPJzIcOXuxcnMKVAbvsflKn/UtH7M2gYlmUngLkN6xabgExNnqiQVTP9ei/K8GkIFIF9IVKwl/VTVuA0cn73Y2Z4=
X-Received: by 2002:a17:902:fe09:b029:e4:951e:2d2e with SMTP id g9-20020a170902fe09b02900e4951e2d2emr831676plj.22.1617151540429; Tue, 30 Mar 2021 17:45:40 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <000501d71940$e9b87420$bd295c60$@tsinghua.org.cn> <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1UotP6Zc-YhvbBbj0XDiH-nnu3raUH9c0agVJ6B-D32A@mail.gmail.com> <BYAPR11MB320787166ECA326B9E05B2B2C06B9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV071G9LPV4zjDzJU=YvcTHaJ3KP4yzjEuP62mkLLy_njg@mail.gmail.com> <BYAPR11MB3207F0D8480B4B8EF992406CC0689@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV27YxKhmOjYq6v9Yj_Tqe7rV8wHBhdh6Z_oRZ5-U0E_9g@mail.gmail.com> <BYAPR11MB3207DA25A51E243C011D2B35C0679@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV25atsaC=DASeSSzTmBNN8W_Ju2MOhpGG+d-EY=+GJAxQ@mail.gmail.com>
In-Reply-To: <CABNhwV25atsaC=DASeSSzTmBNN8W_Ju2MOhpGG+d-EY=+GJAxQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 30 Mar 2021 20:45:29 -0400
Message-ID: <CABNhwV3pyQo=ZMpP08x7a=6Amb=7LqsysAcAMxFtNdzSoRKRVA@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: IETF IDR <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d87c805beca6f59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2yc99M5biTHovth0zeuoAgHXIcQ>
Subject: Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 00:45:49 -0000

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

On Fri, Mar 19, 2021 at 8:47 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> 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>rg>; 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>rg>; 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>om>; '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>om>; 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>om>; 'Susan Hares' <
>> shares@ndzh.com>gt;; 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*
>
> --

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