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

From: Chenshuanglong <[email-masked]>
Date: Tue, 3 Aug 2021 02:21:15 +0000

Hi all,

This draft helps simplify the configuration of routing policies.
I support the publication of this draft.

Regards
Shuanglong

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, July 24, 2021 1:23 AM
To: [email-masked]
Subject: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 3 Aug 2021 10:56:22 +0800

Hi all,

    I support the publication of the draft. 

    It is helpful to simplify the work of the operators.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Chenshuanglong
Date: 2021-08-03 10:21
To: Susan Hares; [email-masked]
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
Hi all,

Regards
Shuanglong

 

 

Cheerily, Susan Hares

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 3 Aug 2021 13:09:51 -0400

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
 [email-masked]

On Wed, Jul 28, 2021 at 5:21 PM Donald Eastlake <[email-masked]> 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
>  [email-masked]
>
> On Fri, Jul 23, 2021 at 1:23 PM Susan Hares <[email-masked]> wrote:
> >
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/idr

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 4 Aug 2021 03:11:01 +0000

Hi Sue and All,

The following is Liang Ou’s IPR statement. I forward it to the IDR list per his request.

Thanks,
Shunwan

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 3, 2021 5:04 PM
To: Zhuangshunwan <[email-masked]>
Subject: 转发: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

发件人: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
发送时间: 2021年8月3日 15:25
收件人: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: 回复: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

I am not aware of any undisclosed IPR related to this draft, and I support the publication of this draft.

Liang Ou
China Telecom Research Institute
Zhongshan Ave. 109#
Guangzhou, P.R.China

Cheerily, Susan Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 5 Aug 2021 03:30:23 +0000

Yes, support.

There is no doubt that markets and network customers have a need for a BGP optimizer.
Experience in recent years has shown that direct manipulation of BGP routes is prone to route hijacking and leakage. As Job expressed(https://mailman.nanog.org/pipermail/nanog/2018-May/095341.html), IETF needs a solution. RPD provides such a solution.

This solution is used to control the routing policy of the local network and does not generate additional routes or specific routes for optimization. This avoids route hijacking and leakage caused by traditional BGP optimizers.

Thanks,
Cheng

Cheerily, Susan Hares