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

From: "Susan Hares" <[email-masked]>
Date: Fri, 23 Jul 2021 13:22:56 -0400

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: Huaimo Chen <[email-masked]>
Date: Fri, 23 Jul 2021 20:28:57 +0000

I support the publication of this draft.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Friday, July 23, 2021 1:22 PM
To: [email-masked] <[email-masked]>
Subject: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Sat, 24 Jul 2021 02:12:33 +0000

I support the publication.

1)       As I known, some ISPs have deployed this solution.

2)       It makes easier to adjusting inbound traffic.

Best regards,
Haibo

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)

Cheerily, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Sat, 24 Jul 2021 02:58:32 +0000

Hi All,

I support the publication. There have been implementations and deployments. And the concept BGP is used as the south bound protocols of the controller has been well accepted in the industry.

Best regards,
Zhenbin (Robin)

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

Cheerily, Susan Hares

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 25 Jul 2021 01:15:01 +0000

Linda Dunbar

________________________________
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 23, 2021 1:22 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Cheerily, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 25 Jul 2021 11:36:48 -0400

I support publication of this draft.

This draft provides a valuable automated method for operators to deploy
complex policies without manual configuration using a new BGP extension for
policy distribution.

Regards

Gyan

On Sat, Jul 24, 2021 at 9:15 PM Linda Dunbar <[email-masked]>
wrote:

> ------------------------------
>
> *From:* Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Sent:* Friday, July 23, 2021 1:22 PM
> *To:* [email-masked] <[email-masked]>
> *Subject:* [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 26 Jul 2021 00:11:23 +0000

Regards,
Shunwan

Cheerily, Susan Hares

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 27 Jul 2021 16:15:17 -0400

Support.
Thanks,
- Xufeng

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 28 Jul 2021 17:18:04 +0800

Hi, All:

I think there are some points should be addressed before it publication:

1)     Will the draft-ietf-idr-wide-bgp-communities-05
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-wide-bgp-communities-0
5#page-12> [Wide Community], which is one of normative reference documents
for the draft-ietf-idr-rpd-11.txt, be forwarded later? I think the [Wide
Community] document will influence the final publication of this draft.  If
[Wide Community] will not be forwarded, would it better to define its own
container for the attached attributes sub-TLV?

2)     Should the "RouteAttr" described in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.1 be
Sub-TLV of Target TLV, and other associated Sub-TLV be sub-sub TLV?

3)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.2
describes the "Routing Policy Type" registry, is it necessary? 

In https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.1, it
describes:

"Policy Type:  1 octet indicates the type of a policy.  1 is for Export
policy. 2 is for Import policy.  If the Policy Type is any other value, the
NLRI is corrupt and the enclosing UPDATE message MUST be ignored."  

Is this the place to use the "Routing Policy Type"? If so, it is
unreasonable to use other values as required by the IANA considerations.

4)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.5
is named as "Attribute Change Sub-TLV" Registry, should it be "Parameter
TLV" as indicated in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.2

Best Regards

Aijun Wang

China Telecom

 

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

 

Cheerily, Susan Hares

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Jul 2021 17:21:39 -0400

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]

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 29 Jul 2021 05:02:40 +0000

Hi Aijun,

    Thank you very much for your comments.

    My responses are inline below with [HC].

Best Regards,
Huaimo

________________________________
From: Idr <[email-masked]> on behalf of Aijun Wang <[email-masked]>
Sent: Wednesday, July 28, 2021 5:18 AM
To: 'Susan Hares' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Hi, All:

1)     Will the draft-ietf-idr-wide-bgp-communities-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-wide-bgp-communities-05%23page-12&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226848366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5ZpdHDve2j0dLW%2BkW90OyEwNfluQT3D7wXqXnZrHL5M%3D&reserved=0>[Wide Community], which is one of normative reference documents for the draft-ietf-idr-rpd-11.txt, be forwarded later? I think the [Wide Community] document will influence the final publication of this draft.  If [Wide Community] will not be forwarded, would it better to define its own container for the attached attributes sub-TLV?

[HC]: Wide Community is very powerful. It will eventually

become a RFC. In addition to this document, there are other
working group documents that use Wide Community. The authors
of the Wide Community document also work on it.

2)     Should the “RouteAttr” described in https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.2.1&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226848366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aSFPm1btQgvbCHdsGJumAMCsL6ohrM1u9ZNU%2Fa9bLg0%3D&reserved=0> be Sub-TLV of Target TLV, and other associated Sub-TLV be sub-sub TLV?

[HC]: We have changed "TLV/Sub-TLV" to "Sub-TLV" and rephrased the related text accordingly.

3)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-9.2&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226858324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jtCxWAlBaUGtAwowgUTEmLLnlCLkUAIQwshtgoD9vkk%3D&reserved=0> describes the “Routing Policy Type” registry, is it necessary?

In https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.1&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226858324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IDMdeBVRm4koo3Bwlo3c8N2bMxk0qcc8hPh34y5KJj8%3D&reserved=0>, it describes:

“Policy Type:  1 octet indicates the type of a policy.  1 is for Export policy. 2 is for Import policy.  If the Policy Type is any other value, the NLRI is corrupt and the enclosing UPDATE message MUST be ignored.”

Is this the place to use the “Routing Policy Type”? If so, it is unreasonable to use other values as required by the IANA considerations.

[HC]: You are right. There is no other policy type except

for export and import. The "Routing Policy Type" registry

is not needed. We have removed it.

4)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.5<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-9.5&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0wvPK%2BNvk7V8UsowNyKqFNAton5b9aYO5dB9rl%2FnGgo%3D&reserved=0> is named as “Attribute Change Sub-TLV” Registry, should it be “Parameter TLV” as indicated in https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.2.2&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xqOrDBG3UWbMvzJmSKPSNnee%2Bn1pNbBJclM7kHXmazw%3D&reserved=0>

[HC]: The “Attribute Change Sub-TLV” is within the “Parameter TLV”.

Best Regards

Aijun Wang

China Telecom

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20impolementations%20<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-rpd%2520impolementations%2520&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ITkstVwx5lYqsyihPPr5S13Z81Qk0tvV5ypcRSPTTNE%3D&reserved=0>

Cheerily, Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 29 Jul 2021 13:48:54 +0800

OK, I support its publication.  

The answer to the questions from the Chairs are the followings:

1)      if this draft is ready for deployment

[WAJ] Yes.

2)      if the BGP extensions for routing policy distribution Help
deployments of BGP in the Internet. 

[WAJ] I think rpd can help the deployment of routing policy via BGP
protocol.

Best Regards

Aijun Wang

China Telecom

From: Huaimo Chen <[email-masked]> 
Sent: Thursday, July 29, 2021 1:03 PM
To: Aijun Wang <[email-masked]>; 'Susan Hares' <[email-masked]>;
[email-masked]
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Hi Aijun,

Best Regards,

Huaimo

  _____  

From: Idr <[email-masked] <mailto:[email-masked]> > on behalf of
Aijun Wang <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, July 28, 2021 5:18 AM
To: 'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] IPR call for draft-ietf-idr-rpd-11.txt (7/23 to 8/6/2021)

Hi, All:

1)     Will the draft-ietf-idr-wide-bgp-communities-05
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-wide-bgp-communities-05%23page-12&
data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe
8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226848366%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C1000&sdata=5ZpdHDve2j0dLW%2BkW90OyEwNfluQT3D7wXqXnZrHL5M%3D&reserved=
0> [Wide Community], which is one of normative reference documents for the
draft-ietf-idr-rpd-11.txt, be forwarded later? I think the [Wide Community]
document will influence the final publication of this draft.  If [Wide
Community] will not be forwarded, would it better to define its own
container for the attached attributes sub-TLV?

2)     Should the "RouteAttr" described in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.1
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.2.1&data=04%7C01%7
Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3
b240189c753a1d5591fedc%7C1%7C0%7C637630607226848366%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd
ata=aSFPm1btQgvbCHdsGJumAMCsL6ohrM1u9ZNU%2Fa9bLg0%3D&reserved=0>  be Sub-TLV
of Target TLV, and other associated Sub-TLV be sub-sub TLV?

[HC]: We have changed "TLV/Sub-TLV" to "Sub-TLV" and rephrased the related
text accordingly.

3)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.2
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-9.2&data=04%7C01%7Ch
uaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b2
40189c753a1d5591fedc%7C1%7C0%7C637630607226858324%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
a=jtCxWAlBaUGtAwowgUTEmLLnlCLkUAIQwshtgoD9vkk%3D&reserved=0>  describes the
"Routing Policy Type" registry, is it necessary? 

In https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.1
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.1&data=04%7C01%7Ch
uaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b2
40189c753a1d5591fedc%7C1%7C0%7C637630607226858324%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
a=IDMdeBVRm4koo3Bwlo3c8N2bMxk0qcc8hPh34y5KJj8%3D&reserved=0> , it describes:

4)     https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-9.5
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-9.5&data=04%7C01%7Ch
uaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3b2
40189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
a=0wvPK%2BNvk7V8UsowNyKqFNAton5b9aYO5dB9rl%2FnGgo%3D&reserved=0>  is named
as "Attribute Change Sub-TLV" Registry, should it be "Parameter TLV" as
indicated in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd#section-4.2.2
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-rpd%23section-4.2.2&data=04%7C01%7
Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C0fee8ff2a3
b240189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd
ata=xqOrDBG3UWbMvzJmSKPSNnee%2Bn1pNbBJclM7kHXmazw%3D&reserved=0> 

[HC]: The "Attribute Change Sub-TLV" is within the "Parameter TLV".

Best Regards

Aijun Wang

China Telecom

 

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

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20impolementations%20
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf
.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-rpd%2520impolementations%2520&data
=04%7C01%7Chuaimo.chen%40futurewei.com%7Cb67d9b53c2244e6381a008d951a8afe8%7C
0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637630607226868271%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C1000&sdata=ITkstVwx5lYqsyihPPr5S13Z81Qk0tvV5ypcRSPTTNE%3D&reserved=0>   

Cheerily, Susan Hares