Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Donald Eastlake <d3e3e3@gmail.com> Tue, 03 August 2021 17:10 UTC

Return-Path: <d3e3e3@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 09EE33A2A49 for <idr@ietfa.amsl.com>; Tue, 3 Aug 2021 10:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 uT92Vt05_pUr for <idr@ietfa.amsl.com>; Tue, 3 Aug 2021 10:10:04 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 C03A43A2A43 for <idr@ietf.org>; Tue, 3 Aug 2021 10:10:04 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id f6so19265445ioc.6 for <idr@ietf.org>; Tue, 03 Aug 2021 10:10:04 -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=UWJ9TsHIajPDLuZLYWUWLlOjRbnjgDox2K6ovgjoOqA=; b=FMwHgXWE15bbdmQRexIlnp7C69HY2effFAlfcjG7G1Gz5qTpZPs4Vf1o90VuCSgfdy NexDDlvCWhcJrgk+jc/29CefN4S8UUDgx42f1yLEzPZZkN27b7LKXqu9NDICfUihdZjL yw8CD/dAvapX2zVcbY64j4gkn9JGWcIbzF8GskcCr/QkE4GqF8vhCpcuSoSTVKqiy3pq nKn66uMg38qNNeGx/tNnsy7RK6yajWRoMt1pxP8behDsxPsEpdXkpx8YegjmBz+slA49 FmG3w4CmVf5AWE5XsN/xyvkNRSIU2XVqDKIPdf/FP5cCqTe+paP3/Fpzq83oRyVMkvyE SdGA==
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=UWJ9TsHIajPDLuZLYWUWLlOjRbnjgDox2K6ovgjoOqA=; b=MQA7n+CkkVz7qhFMOw3Y6MJtr/833NZ8JNUdKzJgp16Ej5ABUBRWqkEFED4/pA5QnK rBwMu7CRLx+NIxYLn9+J6d1C7yM0R/qrNobaG4cBkIqJdcI745GsTawm9+Hpza86iSYn KibTzHIJK2x5bMVaxrDgg/gOsvz+J2ULfONdXybnkdTicKF+u+59reYa7CmocwQzPheA Ol5HOFstAFr2yBTZgFIPTD//+kcrhTFs2Ol8AkZ//ig/2V4MDnZkkYcT9dvDCcXUcQMP 3c0oPRqw8tuzz4Ei9alBSCz3kSw9SoPnGu8HiPxYsPTCdbe9/3M6tsqClb+FbUJ6Gl5L GxYw==
X-Gm-Message-State: AOAM530nzddWpKfKNgtnto7CKI/hqrctqs18hcH9RosCKps+nwXhE73B XQVJmFuvLz8dJtYEZrJjW60W7hykiYmfw+Cc9sI=
X-Google-Smtp-Source: ABdhPJz0c2/tvv06ph7HPSdevkGPnuxxIga/yVQJbpYWBrCp2W4rOhziYJ8TaJkBAALsHwy/MMcoPkGaxSjR+3GW9Zg=
X-Received: by 2002:a02:2a07:: with SMTP id w7mr20233798jaw.96.1628010603391; Tue, 03 Aug 2021 10:10:03 -0700 (PDT)
MIME-Version: 1.0
References: <025001d77fe7$64d93b50$2e8bb1f0$@ndzh.com> <CAF4+nEEgGiiL9enOVJ58mz4i63qLgX63o8ukNd67oZ7-F+1J3Q@mail.gmail.com>
In-Reply-To: <CAF4+nEEgGiiL9enOVJ58mz4i63qLgX63o8ukNd67oZ7-F+1J3Q@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 3 Aug 2021 13:09:51 -0400
Message-ID: <CAF4+nEE+yc2EN05pTi-=rH-A1yMxFTquNVnV2tZT8SQtzp0BKQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bIujPXAlOqy76SqxTPGoHBhOHfQ>
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
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: Tue, 03 Aug 2021 17:10:10 -0000

Hi,

It may be my fault, but I was still having some trouble really
understanding the IP Prefix sub-sub-TLV in the RouteAttr Atom sub-TLV.
But Huaimo helped in some private mail. Below is a suggested change in
wording that might assist future readers on this text.

OLD
   M-Type:  4-bit field specifying match type.  The following four
      values are defined:

      M-Type = 0:  Exact match with the Mask length IP address prefix.
         GeMask and LeMask MUST be sent as zero and ignored on receipt.

      M-Type = 1:  Match prefix greater than or equal to the given
         masks.

      M-Type = 2:  Match prefix less than or equal to the given masks.

      M-Type = 3:  Match prefix within the range of the given masks.

   Flags:  4 bits.  No flags are currently defined.

   IPv4 Address:  4 octets for an IPv4 address.

   Mask:  1 octet for the IP address prefix length.

   GeMask:  1 octet for match range's lower bound, must not be less than
      Mask or be 0.

   LeMask:  1 octet for match range's upper bound, must be greater than
      Mask or be 0.

NEW
   M-Type:  4-bit field specifying match type.  The following four
      values are defined. IPtlv is the IP address prefix in the
      sub-sub-TLV while IProute is the IP route being matched.

      M-Type = 0:  Exact match with the Mask length IP address prefix.
         GeMask and LeMask MUST be sent as zero and ignored on receipt.

      M-Type = 1:  Matches if the Mask number of prefix bits exactly
         match between IPtlv and IProute and the actual prefix length
         of IProute is greater than or equal to GeMask. LeMask MUST be
         sent as zero and ignored on receipt.

      M-Type = 2:  Matches if the Mask number of prefix bits exactly
         match between IPtlv and IProute and the actual prefix length
         of IProute less than or equal to LeMask. GeMask MUST be sent
         as zero and ignored on receipt.

      M-Type = 3:  Matches if the Mask number of prefix bits exactly
         match between IPtlv and IProute and the actual prefix length
         of IProute is less than or equal to LeMask and greater than
         or equal to GeMask..

   Flags:  4 bits.  No flags are currently defined. MUST be sent as
      zero and ignored on receipt.

   IPv4 Address:  4 octets for an IPv4 address.

   Mask:  1 octet for the IP address prefix length that needs to exactly
      match between the IP address in the sub-sub-TLV and the route.

   GeMask: 1 octet for route prefix length match range's lower bound,
      must not be less than Mask or be 0.

   LeMask: 1 octet for route prefix length match range's upper bound,
      must be greater than Mask or be 0.


Also, I noticed a couple of other minor things:
the reference to RFC 5575 should probably be updated to 8955;
since it is not used in the body of the draft, I think RFC 1997 can be
removed from the normative references;
and since RFC 8126 is not actually used in the body of the draft, it
could be removed from the references or, alternatively, you could add
a sentence between the Section 9 heading and the Section 9.1 heading
something like "The IANA Considerations below follow [RFC8126]."

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Wed, Jul 28, 2021 at 5:21 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
>
> I support this draft and believe it is useful. However, I think the
> wording in the specification of the IP prefix sub-TLV needs to be
> clarified. See below for my comments on that wording and on a few
> other minor points.
>
> Section 4.1:
>
> On the Distinguisher, to avoid ambiguity on what lower/smaller and
> higher/larger mean I suggest
> "4 octet value" -> "4 octet unsigned integer that"
>
> MP_Reach_NLRI -> MP_REACH_NLRI
>
> Section 4.2.1:
>
> I found the specification of the IP prefix sub-TLV confusing. The
> document says that the "Mask" field is "1 octet for mask length". That
> combined with the first example makes it reasonably clear that the
> M-Type=0 is an exact match on the "Mask" number of prefix bits in the
> IP address given in the sub-TLV with the IP address being tested.
> Assuming my interpretation is correct and following the usual IETF
> convention, where unused fields are sent as zero and ignored on
> receipt, my first suggested changes are as follows:
> OLD
>    M-Type:  4 bits for match types, four of which are defined:
>
>       M-Type = 0:  Exact match.
> NEW
>    M-Type:  4-bit field specifying match type. The following four
> values are defined:
>
>       M-Type = 0:  Exact match with the Mask length IP address prefix.
> GeMask and LeMask MUST be sent as zero and ignored on receipt.
> OLD
>    Mask:  1 octet for the mask length.
> NEW
>    Mask:  1 octet for the IP address prefix length.
>
> M-Type=1 is considerably more confusing. We now have, I assume, two
> prefix lengths: Mask and GeMask. And we have two IP addresses, the
> sub-TLV IP address and the IP address being tested. I cannot figure
> out from the draft which mask is applied to which IP address and
> exactly what "greater than" comparison is being made. The terse
> example does not help me. The same comments apply to M-Type=2.
> M-Type=3 is even more complex; there are 3 masks, two IP addresses,
> and, presumably, two comparisons... I think the text here should be
> made clearer and more explicit
>
> Section 9.1:
>
> Delete all occurrences of the word "new". Drafts should use the
> wording desired in the final RFC. These values are not "new" anymore.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> On Fri, Jul 23, 2021 at 1:23 PM Susan Hares <shares@ndzh.com> wrote:
> >
> > This begins a 2 week WG last call on draft-ietf-idr-rpd-11.txt.
> >
> >
> >
> > There is one missing IPR statement from Liang Ou.
> >
> > Liang should send the IPR statements in response to this WG LC.
> >
> >
> >
> > The implementation report is at:
> >
> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20impolementations%20
> >
> >
> >
> > The two implementations are different implementations from Huawei.
> >
> >
> >
> > This document describes BGP Extensions for Routing
> >
> >    Policy Distribution (BGP RPD) to support this.
> >
> >
> >
> > Please consider in your review of this draft:
> >
> > 1) if this draft is ready for deployment,
> >
> > 2) if the BGP extensions for routing policy distribution
> >
> > Help deployments of BGP in the Internet.
> >
> >
> >
> > Cheerily, Susan Hares
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr