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

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Wed, Jul 28, 2021 at 5:21 PM Donald Eastlake <[e-mail]> 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   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> On Fri, Jul 23, 2021 at 1:23 PM Susan Hares <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr