Subject: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Jul 2020 09:11:09 -0400

This begins a 2 week WG LC on draft-ietf-idr-rpd 

from 7/15 to 7/29/2020.  You can obtain this draft at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/

This draft defines a new AFI/SAFI and new atoms 

for the Wide Communities.  This WG LC has been delayed 

as I waited for a resubmission of the Wide Communities draft.  

I had hoped to do these 2 WG LC in parallel. 

I've not received the Wide Communities draft, but we will 

start this WGLC to provide feedback to the authors. 

We may have to run a short follow-up to this WG LC

If there are changes to the Wide Communities draft during 

Its WG LC. 

There is an IPR statement on this draft.

In your responses please answer the following questions: 

1) Do you feel this draft has an solution that is acceptable 

   With the IPR as a WG RFC?  

2) Do you feel this draft is ready to publish?

3) Do you know of implementations of this draft?  

4) Do you know of deployments of this draft?  

If so, is this feature useful in the deploy ments. 

5) Do you feel that Wide Communities is ready for 

Publication?  

Cheerily, Susan Hares

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 15 Jul 2020 20:44:01 +0000

Hi Everyone,

    I support the WGLC of the draft.

Best Regards,
Huaimo as a co-author

________________________________
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Wednesday, July 15, 2020 9:11 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cdb72a70170244f5c73a208d828c0980e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304154968576692&sdata=fGpMx9NBxsL%2FRfP%2BAImmb4R2hbxFmaAn%2FpOWXmapQ10%3D&reserved=0>

I’ve not received the Wide Communities draft, but we will

Its WG LC.

It is acceptable.

It is ready.

Two implementations.

It is useful.

Publication?

 It is ready.

Cheerily, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 17 Jul 2020 01:01:51 +0000

BGP seems the wrong way to distribute routing policy.
IETF has already defined a way to distribute configuration: Netconf.
Netconf provides needed features that BGP does not have:
- Atomic Transactions:
  If one configuration item fails, they all fail.
  They all either succeed or all fail. There is no partial success.
  Multiple configurations in one transaction are applied at the same time.
   . This avoids non-deterministic transient behavior between application of the first policy and the last.
- Feedback:
  BGP is "spray and pray".
  Netconf provides an acknowledgement that the config either failed or was applied,
  which then allows the controller to take the next steps with
  reliable information about what configuration exists in the network.
- Persistence:
  If the BGP session were to go down, all the configuration it sent will be implicitly withdrawn.

If another AS would not allow a foreign AS to configure it with netconf,
it would not allow it with RPD either.

There are already ways in BGP for an AS to signal preference across AS boundaries:
Med, AS-path length, communities.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Wednesday, July 15, 2020 6:11 AM
To: [email-masked]
Subject: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Jul 2020 15:08:18 +0200

Dear IDR WG,

As discussed previously on the list I strongly object to proceed with this
draft any further.

While I am as others quite sceptical about distributing more configuration
over BGP this can be said to be debatable especially for p2mp applications.

However including peer's IP address in the NLRI to which given policy
applies goes completely AGAINST BGP spray principle of p2mp
information distribution. Adding such extension to BGP can only deteriorate
the protocol further. It is not a fit in p2mp protocol to by definition use
it as p2p transport channel.

The prefix 0 which is in the draft is not the solution to the above
problem.

Moreover wide community ATOM also can already contain that peer's address
so placing it in the NLRI of MP_REACH is not needed at all.

To the specific questions asked:

Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

Kind regards,
R.

On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 21 Jul 2020 04:00:42 +0000

Hi Jakob,

    Thank you very much for your valuable comments.
    Our answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo on behalf of co-authors
________________________________
From: Idr <[email-masked]> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]>
Sent: Thursday, July 16, 2020 9:01 PM
To: Susan Hares <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

[HC]: It seems that BGP flow spec has been used widely to distribute policies for redirecting the traffic. It seems work well without some mechanisms in Netconf. BGP RPD should be similar to BGP flow spec.  BGP SR Policy is on the same train.

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

[HC]: Netconf can be used to distribute configurations from a controller to the devices in a network. BGP RPD as an alternative option, may have some advantages in some cases. For example, in the case where BGP as a controller, BGP RPD seems more suitable. Using BGP RPD to control/redirect the traffic dynamically in real time may be more effective.

Regards,

Jakob.

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C12cf72daefe0446d5a7908d829ed0a36%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637305445341383523&sdata=3LvgG6xwElOv27jGetqpyk8ftRub%2B%2B4Ui31Yt8wN87A%3D&reserved=0>

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Jul 2020 04:52:04 +0000

There is an important difference between RPD and Flowspec.
https://tools.ietf.org/html/rfc5575#section-6
states:
   A flow specification NLRI must be validated such that it is
   considered feasible if and only if:

   a) The originator of the flow specification matches the originator of
      the best-match unicast route for the destination prefix embedded
      in the flow specification.

   b) There are no more specific unicast routes, when compared with the
      flow destination prefix, that have been received from a different
      neighboring AS than the best-match unicast route, which has been
      determined in step a).

Effectively, the advertisement of the route takes the same vector as the
advertisement of the matching flowspec. Therefore, if the flowspec did not
reach a node, then the route likely didn't either, so it doesn't matter.

The fact that BGP is spray and pray doesn't matter, because the route and the
flowspec spray to the same places.

RPD policy distribution has no such validation rule.

SR policy distribution suffers from the same problem.

Regards,
Jakob.

From: Huaimo Chen <[email-masked]>
Sent: Monday, July 20, 2020 9:01 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Best Regards,
Huaimo on behalf of co-authors
________________________________
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>
Sent: Thursday, July 16, 2020 9:01 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: Wednesday, July 15, 2020 6:11 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2020 11:12:26 +0200

SR policies propagation is a config push and should never be done in BGP.
At least it is p2mp. Much better option here is
https://tools.ietf.org/html/rfc5440

Your draft is p2p configuration push which is completely an NMS task.
Please tell me why it can not be done with YANG models ?

Maybe instead of picking up one cherry at a time let's define a new
AFI/SAFI - "BGP NMS AF" and stuff all of the p2p configuration there. At
least when things melt it will be easy to recover by just disabling such AF
and still allow for some routing info to go through ....

Thx,
R.

On Tue, Jul 21, 2020 at 6:00 AM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> *From:* Idr <[email-masked]> on behalf of Jakob Heitz (jheitz)
> <jheitz=[email-masked]>
> *Sent:* Thursday, July 16, 2020 9:01 PM
> *To:* Susan Hares <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
> [HC]: It seems that BGP flow spec has been used widely to distribute
> policies for redirecting the traffic. It seems work well without some
> mechanisms in Netconf. BGP RPD should be similar to BGP flow spec.  BGP SR
> Policy is on the same train.
>
>
> [HC]: Netconf can be used to distribute configurations from a controller
> to the devices in a network. BGP RPD as an alternative option, may have
> some advantages in some cases. For example, in the case where BGP as a
> controller, BGP RPD seems more suitable. Using BGP RPD to control/redirect
> the traffic dynamically in real time may be more effective.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Susan Hares
> *Sent:* Wednesday, July 15, 2020 6:11 AM
> *To:* [email-masked]
> *Subject:* [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C12cf72daefe0446d5a7908d829ed0a36%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637305445341383523&sdata=3LvgG6xwElOv27jGetqpyk8ftRub%2B%2B4Ui31Yt8wN87A%3D&reserved=0>
>
>
>

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 23 Jul 2020 06:53:25 +0000

Hi Everyone,

I support the WGLC of the draft.
Reponses inline with [Shunwan].

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, July 15, 2020 9:11 PM
To: [email-masked]
Subject: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

1) Do you feel this draft has an solution that is acceptable
   With the IPR as a WG RFC?
[Shunwan] It is acceptable.

[Shunwan] It is ready.

3) Do you know of implementations of this draft?
[Shunwan] At least 2 implementations.

4) Do you know of deployments of this draft?
If so, is this feature useful in the deploy ments.
[Shunwan] At least 5 deployments as far as I know. It is very useful in the scenario where the routing policies need to be dynamically adjusted.
This solution is initially proposed in a network optimization project of OTT, ISP, and vendor.

5) Do you feel that Wide Communities is ready for
Publication?
[Shunwan] Yes, it is ready. Wide Communities is an excellent container for carrying routing policies.

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Thu, 23 Jul 2020 07:02:06 +0000

Hi Jakob,

1.  Flowspec's validation is used to check whether a device can learn the Flowspec routes from an EBGP peer, but the validation can be performed only for the component of the destination type.
    In practice, the centralized server or controller is often used to send FlowSpec routes to devices.
2.  RPD and SR-Policy also have their own validation. That is, route targets are used to check whether information is sent to the expected node.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 21, 2020 12:52 PM
To: Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 20, 2020 9:01 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Best Regards,
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]..org<mailto:jheitz=[email-masked]>>

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Chenshuanglong <[email-masked]>
Date: Thu, 23 Jul 2020 07:18:39 +0000

Support

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年7月15日 21:11
收件人: [email-masked]
主题: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Cheerily, Susan Hares

---

From: jasonlu(陆素建) <[email-masked]>
Date: Thu, 23 Jul 2020 08:37:14 +0000

Hi Everyone,

I support the WGLC of the draft.
Reponses inline with [Jasonlu].

发件人: Idr <[email-masked]> 代表 Susan Hares
发送时间: 2020年7月15日 21:11
收件人: [email-masked]
主题: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Cheerily, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 23 Jul 2020 10:02:51 +0000

+1 and I also agree on Jakob’s comments/discussion on a parallel thread.

The individual version of this draft was called draft-li-idr-flowspec-rpd. When it came up for WG adoption, perhaps most people thought it was yet another Flowspec extension and did not have a close look at it.

The draft got adopted in Nov 2019 and since then, there has hardly been any change for it (other than IANA allocations update) : https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-00&url2=draft-ietf-idr-rpd-05

I am not sure if this document has received sufficient review and inputs from the WG over the recent 9 months of its life as a WG document. Those provided by Robert previously seem not to have been incorporated?

Not sure if I missed implementation reports or some operator feedback on this.

Some more/other comments on why I believe this draft is not a good idea:

  *   How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
  *   Seems like one can have multiple policies advertised for a single peer/neighbor? How would they be handled?
  *   The draft has support for IPv4 and IPv6 prefix list and AS regex. What other route policy tools does the WG expect to extend in further drafts? Perhaps we end up with yet another boatload of extension drafts for BGP for RPD?

We have Route Policy yang model defined at the IETF for provisioning of route policies that provide better and more comprehensive solution than the proposal in this document. That approach is also very robust from operational perspective. We don’t need to be putting this into BGP protocol.

In summary, my suggestion would also be not proceed further on this document.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: 17 July 2020 18:38
To: Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

As discussed previously on the list I strongly object to proceed with this draft any further.

While I am as others quite sceptical about distributing more configuration over BGP this can be said to be debatable especially for p2mp applications.

However including peer's IP address in the NLRI to which given policy applies goes completely AGAINST BGP spray principle of p2mp information distribution. Adding such extension to BGP can only deteriorate the protocol further. It is not a fit in p2mp protocol to by definition use it as p2p transport channel.

The prefix 0 which is in the draft is not the solution to the above problem.

Moreover wide community ATOM also can already contain that peer's address so placing it in the NLRI of MP_REACH is not needed at all.

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.

Kind regards,
R.

On Wed, Jul 15, 2020 at 3:11 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG LC on draft-ietf-idr-rpd
from 7/15 to 7/29/2020.  You can obtain this draft at:
https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/

Cheerily, Susan Hares
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 23 Jul 2020 17:30:50 +0000

You're missing the point.

Regards,
Jakob.

From: Wanghaibo (Rainsword) <[email-masked]>
Sent: Thursday, July 23, 2020 12:02 AM
To: Jakob Heitz (jheitz) <[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 21, 2020 12:52 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

Hi Jakob,

Best Regards,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 24 Jul 2020 06:23:07 +0000

Hi Jakob,

Can you give some more details about "the route and the flowspec spray to the same places"

Regards,
Haibo

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Friday, July 24, 2020 1:31 AM
To: Wanghaibo (Rainsword) <[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

From: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 12:02 AM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Regards,
Haibo

Regards,
Jakob.

Hi Jakob,

Best Regards,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Fri, 24 Jul 2020 08:04:17 +0000

Hi All,

I support the WG LC of the drafts. My reply on the question list is as follows:

[Robin] Yes

[Robin] Yes

3) Do you know of implementations of this draft?
[Robin] Yes. There are at least 2 implementations.

4) Do you know of deployments of this draft?
If so, is this feature useful in the deployments.
[Robin] Yes. There are multiple deployments. It is very useful to steer traffic through the distribution of the routing policy.
Owing to the change of traffic pattern caused by the COVID-19 pandemic, there are more deployments requirements of
the solution.

5) Do you feel that Wide Communities is ready for
Publication?
[Robin] Yes. It provides a very useful way to convey the route policy information. We always debate if Netconf/YANG or BGP
is appropriate on many topics. BGP Wide Communities and BGP SR Policy are the good examples in practice for better 3-rd party
interworking and incremental deployment.

Best Regards,

Zhenbin (Robin)

________________________________
发件人: Idr [[email-masked]] 代表 Susan Hares [[email-masked]]
发送时间: 2020年7月15日 21:11
收件人: [email-masked]
主题: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Cheerily, Susan Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 24 Jul 2020 08:58:01 +0000

Hi Sue,

I support the WG LC of this document.

Please see further replies inline:

Best regards,
Jie

Yes

Yes

At least 2 implementations.

Yes, there are several deployments, which proves this is a useful feature for operators.

Yes.

Cheerily, Susan Hares

---

From: Huzhibo <[email-masked]>
Date: Fri, 24 Jul 2020 09:02:33 +0000

Hi :

Thanks
Zhibo Hu

Cheerily, Susan Hares

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 24 Jul 2020 09:06:27 +0000

Hi All,
I support the WG LC of the drafts. My answer to the listed questions:

[Jingrong] Yes

[Jingrong] Yes

3) Do you know of implementations of this draft?
[Jingrong] Yes. There are at least 2 implementations.

4) Do you know of deployments of this draft?
If so, is this feature useful in the deploy ments.
[Jingrong] Yes. There are multiple deployments. It is very useful from the feedback of the operators.

5) Do you feel that Wide Communities is ready for
Publication?
[Jingrong] Yes. It provides a very useful way to steer traffic.
We often see debates if Netconf/PCE or BGP is appropriate on many topics, but to me, each has its own merits.
In fact, we have seen BGP being used and preferred in many interactive-like behaviors like SR-policy, MVPN (RFC6514, RFC7524).
The use of BGP in a controller based solution is my personal preference, and I believe there are many others with the same preference.

Thanks
Jingrong Xie

Cheerily, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Fri, 24 Jul 2020 09:20:55 +0000

Hi Robert,

I think your proposed issue maybe make sense 4/5 years ago. Given the fact that SR policy is widely adopted to

distribute specific SR policy to the specified ingress node through, the dependence of P2MP may be not very useful.

From other perspective, P2P can also be seen as the special case of P2MP. Even in the history of BGP, P2P distribution

can also happen through the control of the local policy. I means there is not absolute boundary.

Best Regards,

Zhenbin (Robin)

________________________________
发件人: Idr [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2020年7月17日 21:08
收件人: Susan Hares
抄送: idr@ietf. org
主题: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.

Kind regards,
R.

Cheerily, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Fri, 24 Jul 2020 09:33:05 +0000

Hi Robert,

I cannot see the absolute difference between the SR Policy and the RPD regarding the point you mentioned to look them as the config push.

Regarding your proposal, maybe we can. We also ever proposed the following draft.

https://tools.ietf.org/html/draft-dong-idr-node-target-ext-comm-02

But it seems a little conflicted about your viewpoints. Now such cases can be seen as the special cases of BGP. But if we define the general solutions,

it will go to change your claimed essence of p2mp for BGP you are defending :)

Best Regards,

Zhenbin (Robin)

________________________________
发件人: Idr [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2020年7月21日 17:12
收件人: Huaimo Chen
抄送: Jakob Heitz (jheitz); Susan Hares; [email-masked]
主题: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

SR policies propagation is a config push and should never be done in BGP. At least it is p2mp. Much better option here is https://tools.ietf..org/html/rfc5440<https://tools.ietf.org/html/rfc5440>

Your draft is p2p configuration push which is completely an NMS task. Please tell me why it can not be done with YANG models ?

Maybe instead of picking up one cherry at a time let's define a new AFI/SAFI - "BGP NMS AF" and stuff all of the p2p configuration there. At least when things melt it will be easy to recover by just disabling such AF and still allow for some routing info to go through ....

Thx,
R.

On Tue, Jul 21, 2020 at 6:00 AM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jakob,

Best Regards,
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>>

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Haoweiguo <[email-masked]>
Date: Fri, 24 Jul 2020 09:40:31 +0000

Hi,
I support the WG last call. I think the draft is in good shape and is ready for the publication.

Thanks,
Weiguo

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2020 13:23:27 +0200

Hi Robin,

Then please explain why do we have NMS and why army of people are busy with
YANG models ?

Or are you also suggesting new BGP SAFI for YANG ? If so let's boldly go
for it instead of trying to squeeze little piece of configuration here and
there one at a time into BGP.

Best,
R.

On Fri, Jul 24, 2020, 11:21 Lizhenbin <[email-masked]> wrote:

> distribute specific SR policy to the specified ingress node through, the
> dependence of P2MP may be not very useful.
>
> From other perspective, P2P can also be seen as the special case of P2MP.
> Even in the history of BGP, P2P distribution
>
> *发件人:* Idr [[email-masked]] 代表 Robert Raszuk [[email-masked]]
> *发送时间:* 2020年7月17日 21:08
> *收件人:* Susan Hares
> *抄送:* idr@ietf. org
> *主题:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
> Dear IDR WG,
>

---

From: "Ou Liang" <[email-masked]>
Date: Fri, 24 Jul 2020 20:55:51 +0800

Hi Everyone,

Best Regards,

Liang Ou as a co-author

Its WG LC. 

Publication?  

Cheerily, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jul 2020 09:44:27 -0400

Hi Everyone

There has been a lot of concern related to this draft after being adopted
in 2019 and not having much feedback till now on WGLC.

I agree with Ketan’s comments that it is two early for WGLC as their are
significant questions and concerns that need to be addressed before we can
proceed any further.

A question was raised as is this an NMS function similar to BGP flowspec
and if so then netconf and Yang already provides that solution.

For SR we already have a centralized PCE controller based policy push that
utilizes BGP LS to gather path information from the IGP for path steering.

This draft seems to be reinventing a wheel that has been invented.

   With the IPR as a WG RFC?  No

2) Do you feel this draft is ready to publish? No

3) Do you know of implementations of this draft? No

4) Do you know of deployments of this draft?  No

Publication?

>From the data tracker for wide communities the draft was adopted but since
has expired.  The RPD draft is hinged on publication of wide communities.
If wide communities has been abandoned I think that would impact this draft.

https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/

My suggestion as others have stated is to not proceed with this document on
WGLC and have further discussion if agreed to analyze how this draft fills
a gap that exist today given the current solutions we have today with NMS
Yang and Netconf as well as existing centralized PCE controller based
solution for SR-TE policy push.

Kind Regards

Gyan

On Fri, Jul 24, 2020 at 8:56 AM Ou Liang <[email-masked]> wrote:

> *发件人:* Idr [mailto:[email-masked]] *代表 *Susan Hares
> *发送时间:* 2020年7月15日 21:11
>
> *收件人:* [email-masked]
> *主题:* [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2020 16:02:24 +0200

> If wide communities has been abandoned

It has not been abandoned. We were waiting for more implementations -
that's all.

Thx.
R.

On Fri, Jul 24, 2020 at 3:44 PM Gyan Mishra <[email-masked]> wrote:

> My suggestion as others have stated is to not proceed with this document
> on WGLC and have further discussion if agreed to analyze how this draft
> fills a gap that exist today given the current solutions we have today with
> NMS Yang and Netconf as well as existing centralized PCE controller based

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jul 2020 16:26:41 -0400

Thanks Robert.  Glad to hear.👍

Gyan

On Fri, Jul 24, 2020 at 10:02 AM Robert Raszuk <[email-masked]> wrote:

>> For SR we already have a centralized PCE controller based policy push
>> that utilizes BGP LS to gather path information from the IGP for path
>> steering.
>>
>> From the data tracker for wide communities the draft was adopted but
>> since has expired.  The RPD draft is hinged on publication of wide
>> communities. If wide communities has been abandoned I think that would
>> impact this draft.
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>

*Gyan Mishra*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 24 Jul 2020 20:28:10 +0000

Let me try a different way.
Flowspec is designed to install a filter everywhere to mitigate DDoS.
Even if the filter does not install in a few routers, the DDoS is still mitigated.
It does not matter which nodes install it before other nodes.
Therefore, the spray and pray of BGP is ok for Flowspec.

Routing policy distribution could cause unpleasant routing transients if
it is not installed or installed late on random nodes.

Regards,
Jakob.

From: Wanghaibo (Rainsword) <[email-masked]>
Sent: Thursday, July 23, 2020 11:23 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Regards,
Haibo

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Friday, July 24, 2020 1:31 AM
To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

Hi Jakob,

Regards,
Haibo

Regards,
Jakob.

Hi Jakob,

Best Regards,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Jul 2020 23:23:37 +0200

In addition to points already mentioned let's examine what the draft
actually defines ... not sure if this is just the tip of the iceberg or
full set of match and set tools authors envision to have.

Match:

IPv4 prefix,
IPv6 prefix,
AS-PATH regex
Community

Set:

MED,
Arbitrary AS-PATH

- So first don't we see a need to match on Peer's ASN ?
- Don't we need to match on the peer ? (NLRI itself just matches on
the ASBR making it p2p)
- How about to match on link bandwidth to the specific peer ?
- The draft talks about outbound traffic engineering from local AS  ...
well that is done typically by setting local preference which is not even
mentioned in the document
- The defined community sub-TLV merely covers RFC1997. How about Extended
or Large Communities ? No use ? No need to match ?

Kind regards,
R.

On Fri, Jul 24, 2020 at 10:28 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> *From:* Wanghaibo (Rainsword) <[email-masked]>
> *Sent:* Thursday, July 23, 2020 11:23 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Huaimo Chen <
> [email-masked]>; Susan Hares <[email-masked]>; idr@ietf..org
> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> Hi Jakob,
>
>
>
> Can you give some more details about "the route and the flowspec spray to
> the same places“
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Jakob Heitz (jheitz) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, July 24, 2020 1:31 AM
> *To:* Wanghaibo (Rainsword) <[email-masked]>; Huaimo Chen <
> [email-masked]>; Susan Hares <[email-masked]>; [email-masked]
> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> *From:* Wanghaibo (Rainsword) <[email-masked]>
> *Sent:* Thursday, July 23, 2020 12:02 AM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Huaimo Chen <
> [email-masked]>; Susan Hares <[email-masked]>; [email-masked]
> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
> 7/29/2020)
>
>
>
> Hi Jakob,
>
>
>
> 1.  Flowspec’s validation is used to check whether a device can learn the
> Flowspec routes from an EBGP peer, but the validation can be performed only
> for the component of the destination type.
>
> 2.  RPD and SR-Policy also have their own validation. That is, route
> targets are used to check whether information is sent to the expected node.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Idr [mailto:[email-masked] <idr-bounces@ietf..org>] *On
> Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Tuesday, July 21, 2020 12:52 PM
> *To:* Huaimo Chen <[email-masked]>; Susan Hares <
> [email-masked]>; [email-masked]
> *From:* Huaimo Chen <[email-masked]>
> *Sent:* Monday, July 20, 2020 9:01 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Susan Hares <
> [email-masked]>; [email-masked]
> *From:* Idr <[email-masked]> on behalf of Jakob Heitz (jheitz) <
> jheitz=[email-masked]..org <jheitz=40cisco.com@dmarc..ietf.org>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jul 2020 18:34:51 -0400

Authors

I read through the draft again and based on the comments thus far trying to
see what gap this draft is addressing that does not exist exist today.

I have commented on this draft earlier on before WGLC and from what I
remember the result of the comments was that this draft is for Non SR or
MPLS and solely for pure IP based networks that require routing policy push
and no traffic steering in the context of PCE based path steering
instantiation that already exists today.

This is purely a policy push concept using BGP large communities new path
attribute container to accomplish the task.

So with that the idea is that this would accomplished by a centralized
controller.

Looking at controller based instantiation you start thinking PCE and BGP LS
for IGP path attributes propagation to the PCE, however in this particular
case we are not doing any traffic steering.

So from thinking PCE and IP based steering got me thinking about this draft
which I see a few authors are on this draft as well.

https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-09

So bottom line is this new MP Reach AFI SAFI code point assigned for IP
based routing control point only which can be managed with a centralized
controller doing the policy push via the new AFI SAFI code point.

One complex design I had worked on years ago which I mentioned in the prior
thread was based on standard community architecture where both sides are a
control point  multi active routing based on communities set.  Imagine you
have two MPLS core transports and have a edge CE that is connected as many
different locations all around the world and you want you tag all CEs off
each core with discrete communities and now you have a special perpending
pattern let’s say it’s 3 ties to make it easy and it’s 0x 2x 3x and so now
you match communities and set a prepend.  So now you duplicate that on both
sides so you don’t backhaul across the other core so you geographically
optimally route between each core over all the many tie points.  This does
get extremely complex but back then it worked and was all accomplished via
standard communities and to this day is still working, however of course
management of the policy changes is still a very very complex task.

So now this use case given could use Roberts Large communities draft and
apply this RPD  new routing policy AFI SAFI to make changes to a complex IP
policy deployment now becomes very simple deploy and manage for day to day
operations.

Based on what I have stated I support advancement of the draft with a
caveat.  I would like to add my use case to the draft and I think that
would help tremendously in explaining the gap and use case being addressed
by this draft.

Kind Regards

Gyan

On Fri, Jul 24, 2020 at 5:24 PM Robert Raszuk <[email-masked]> wrote:

>> Can you give some more details about "the route and the flowspec spray
>> to the same places“
>>
>>
>>
>> Regards,
>>
>> Haibo
>>
>>
>>
>> *From:* Idr [mailto:[email-masked] <idr-bounces@ietf...org>] *On
-- 

*Gyan Mishra*

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Sat, 25 Jul 2020 08:16:16 +0000

Hi Gyan,

Thanks for your comments.

 “So now this use case given could use Roberts Large communities draft and apply this RPD  new routing policy AFI SAFI to make changes to a complex IP policy deployment now becomes very simple deploy and manage for day to day operations.”
This is actually a rather precise usage summarization of this draft.

I’d state a little bit more about the rationale behind it.

So in a nutshell, the RPD does more than simply distributing route policy using a new BGP AFI/SAFI, more importantly, it introduces an independent procedure to the route policy process. Conventionally, either by using CLI or Netconf to configure a route policy, the policy change finally is inserted somewhere in the existing policy structure. Finding the right place for the policy to correctly take effect could be truly a hard work, since the policy can be extremely complex as pointed by Gyan. So distributing policy by using RPD jumps out of the box, it adds a final check procedure after the existing policy processing. Thus, it reliefs you from the complex and error-prone policy management, and guarantees you with a deterministic outcome.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Saturday, July 25, 2020 6:35 AM
To: Robert Raszuk <[email-masked]>
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Authors

I read through the draft again and based on the comments thus far trying to see what gap this draft is addressing that does not exist exist today.

I have commented on this draft earlier on before WGLC and from what I remember the result of the comments was that this draft is for Non SR or MPLS and solely for pure IP based networks that require routing policy push and no traffic steering in the context of PCE based path steering instantiation that already exists today.

This is purely a policy push concept using BGP large communities new path attribute container to accomplish the task.

So with that the idea is that this would accomplished by a centralized controller.

Looking at controller based instantiation you start thinking PCE and BGP LS for IGP path attributes propagation to the PCE, however in this particular case we are not doing any traffic steering.

So from thinking PCE and IP based steering got me thinking about this draft which I see a few authors are on this draft as well.

So bottom line is this new MP Reach AFI SAFI code point assigned for IP based routing control point only which can be managed with a centralized controller doing the policy push via the new AFI SAFI code point.

One complex design I had worked on years ago which I mentioned in the prior thread was based on standard community architecture where both sides are a control point  multi active routing based on communities set.  Imagine you have two MPLS core transports and have a edge CE that is connected as many different locations all around the world and you want you tag all CEs off each core with discrete communities and now you have a special perpending pattern let’s say it’s 3 ties to make it easy and it’s 0x 2x 3x and so now you match communities and set a prepend.  So now you duplicate that on both sides so you don’t backhaul across the other core so you geographically optimally route between each core over all the many tie points.  This does get extremely complex but back then it worked and was all accomplished via standard communities and to this day is still working, however of course management of the policy changes is still a very very complex task.

So now this use case given could use Roberts Large communities draft and apply this RPD  new routing policy AFI SAFI to make changes to a complex IP policy deployment now becomes very simple deploy and manage for day to day operations.

Based on what I have stated I support advancement of the draft with a caveat.  I would like to add my use case to the draft and I think that would help tremendously in explaining the gap and use case being addressed by this draft.

Kind Regards

Gyan

On Fri, Jul 24, 2020 at 5:24 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

In addition to points already mentioned let's examine what the draft actually defines ... not sure if this is just the tip of the iceberg or full set of match and set tools authors envision to have.

Match:

IPv4 prefix,
IPv6 prefix,
AS-PATH regex
Community

Set:

MED,
Arbitrary AS-PATH

- So first don't we see a need to match on Peer's ASN ?
- Don't we need to match on the peer ? (NLRI itself just matches on the ASBR making it p2p)
- How about to match on link bandwidth to the specific peer ?
- The draft talks about outbound traffic engineering from local AS  ... well that is done typically by setting local preference which is not even mentioned in the document
- The defined community sub-TLV merely covers RFC1997. How about Extended or Large Communities ? No use ? No need to match ?

Kind regards,
R.

On Fri, Jul 24, 2020 at 10:28 PM Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jakob.

From: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 11:23 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; idr@ietf..org
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Jakob,

Can you give some more details about "the route and the flowspec spray to the same places“

Regards,
Haibo

Regards,
Jakob.

Hi Jakob,

1.  Flowspec’s validation is used to check whether a device can learn the Flowspec routes from an EBGP peer, but the validation can be performed only for the component of the destination type.
    In practice, the centralized server or controller is often used to send FlowSpec routes to devices.
2.  RPD and SR-Policy also have their own validation. That is, route targets are used to check whether information is sent to the expected node.

Regards,
Haibo

From: Idr [mailto:[email-masked]<mailto:idr-bounces@ietf....org>] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 21, 2020 12:52 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

Hi Jakob,

Best Regards,
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]..org<mailto:jheitz=40cisco.com@dmarc..ietf.org>>

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 26 Jul 2020 12:51:21 +0800

Hi Everyone, 
     I support the WGLC of the draft.
    The rpd is very useful for us to deploy the bgp route policy dynamic.
 
    BR.

HUANAN CHEN（陈华南）
Data Communication Research Department
Research Institute of China Telecom Co.,Ltd.
Mail：[email-masked] 

 

 

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Mon, 27 Jul 2020 03:39:52 +0000

Hi Jakob,

 The RPD solution is now mainly used for optimize inbound traffic.
In the RPD solution, the attributes of advertised routes are modified to affect route selection on the peer end, optimizing inbound traffic.
Even if the RPD routes does not installed on some router, the traffic adjustment may not meet the expectation and does not produce unpleasant results.

Regards,
Haibo

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Saturday, July 25, 2020 4:28 AM
To: Wanghaibo (Rainsword) <[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Regards,
Jakob.

Hi Jakob,

Regards,
Haibo

Regards,
Jakob.

Hi Jakob,

Regards,
Haibo

Regards,
Jakob.

Hi Jakob,

Best Regards,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Mon, 27 Jul 2020 04:00:02 +0000

Hi All,
I support the WG LC of the drafts. My reply on the question list is as follows:
1) Do you feel this draft has an solution that is acceptable
   With the IPR as a WG RFC?
[Haibo] Yes
2) Do you feel this draft is ready to publish?
[Haibo] Yes
3) Do you know of implementations of this draft?
[Haibo] Yes.
4) Do you know of deployments of this draft?
If so, is this feature useful in the deployments.
[Haibo] Yes.
Traffic optimization, especially Internet traffic, is a widespread requirement.
In the traditional solution, use outbound route policy to achieve traffic optimization, whici is complex, error-prone, and difficult to maintain.
With the RPD solution, it's very simply to do the traffic optimization.
As I know, there are several deployments and very useful.
5) Do you feel that Wide Communities is ready for
Publication?
[Haibo] Yes.

Best Regards,
Haibo

Cheerily, Susan Hares

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 27 Jul 2020 20:57:22 +0000

Hi Ketan,

    Thanks much for your comments.
    My answers/explanations are inline below with prefix [HC].

[HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the route policy reaches the target router. When a BGP speaker as a controller sends a BGP UPDATE to a peer, there is no need for the ack from the peer about whether it is received, processed, and installed. The controller is monitoring the traffic of the network almost in real time, and adjusting the traffic dynamically almost in real time. The former gets the status of the network regarding to the traffic.

[HC]: For multiple policies advertised to a single peer/neighbor, they are processed one by one by the peer/neighbor.

[HC]: It seems that the current draft defines a small set of extensions (6 sub TLVs), which is enough to support adjusting the traffic dynamically in the live networks. If there are some new requirements in the future, the extensions would be small too.

[HC]: Yang model seems mainly used in relatively static or stable configurations. For frequently changing route policies, the solution proposed in the draft is more suitable. It makes the operations and maintenance on the network simpler. For example, in one metro area network without using the solution in the draft, planning and implementing an adjustment/redirection of a service traffic takes days. After the solution in the draft is deployed in the network with a controller NCE, this takes just minutes instead of days.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of Ketan Talaulikar (ketant) <ketant=[email-masked]>
Sent: Thursday, July 23, 2020 6:02 AM
To: Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

The draft got adopted in Nov 2019 and since then, there has hardly been any change for it (other than IANA allocations update) : https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-00&url2=draft-ietf-idr-rpd-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981956964&sdata=vUgOeTbdLbvoAWIi17vzORiS8UxREO4JoanDDuuGodM%3D&reserved=0>

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=te9utkoi5bJl%2BT167KdWJQ%2BHYXaOaogxnvPQZLvbbWI%3D&reserved=0>

Its WG LC.

Publication?

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=uA9je9D95WX4sCUMQXWMpxWkKPo%2FbZY%2F1OiVNQKeggM%3D&reserved=0>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 27 Jul 2020 14:46:34 -0700

I also strongly disagree with advancing this draft.
The name on the draft did not highlight sufficiently the impact it would
appear to have.
I concur with Robert's answers, as follows:

Ad 1) No.
Ad 2) No.
Ad 3) No..
Ad 4) No.
Ad 5) Yes.  (I'm actually on the fence on this one, but I think it may be
N/A or moot as a result of 1 through 4).

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jul 2020 00:02:50 +0200

> [HC]: Yang model seems mainly used in relatively static or stable
configurations.

Well that's a problem with the "user" or bad habits not with the YANG model
itself.

Nothing stops to use config push as dynamically as required to network
elements.

Best,
Robert.

On Mon, Jul 27, 2020 at 10:57 PM Huaimo Chen <[email-masked]>
wrote:

>    - How does the controller or provisioning entity know the status of
>       the Route Policy provisioning on the target router. Even that it was
>       successfully propagated to it and installed on it?
>
> [HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the
> route policy reaches the target router. When a BGP speaker as a controller
> sends a BGP UPDATE to a peer, there is no need for the ack from the peer
> about whether it is received, processed, and installed. The controller is
> monitoring the traffic of the network almost in real time, and adjusting
> the traffic dynamically almost in real time. The former gets the status of
> the network regarding to the traffic.
>
>
>    - Seems like one can have multiple policies advertised for a single
>       peer/neighbor? How would they be handled?
>
> [HC]: For multiple policies advertised to a single peer/neighbor, they are
> processed one by one by the peer/neighbor.
>
>
>    - The draft has support for IPv4 and IPv6 prefix list and AS regex.
>       What other route policy tools does the WG expect to extend in further
>       drafts? Perhaps we end up with yet another boatload of extension drafts for
>       BGP for RPD?
>
> [HC]: It seems that the current draft defines a small set of extensions (6
> sub TLVs), which is enough to support adjusting the traffic dynamically in
> the live networks. If there are some new requirements in the future, the
> extensions would be small too.
>
>
>
> We have Route Policy yang model defined at the IETF for provisioning of
> route policies that provide better and more comprehensive solution than the
> proposal in this document. That approach is also very robust from
> operational perspective. We don’t need to be putting this into BGP protocol.
>
> [HC]: Yang model seems mainly used in relatively static or stable
> configurations. For frequently changing route policies, the solution
> proposed in the draft is more suitable. It makes the operations and
> maintenance on the network simpler. For example, in one metro area network
> without using the solution in the draft, planning and implementing an
> adjustment/redirection of a service traffic takes days. After the solution
> in the draft is deployed in the network with a controller NCE, this takes
> just minutes instead of days.
>
>
> Best Regards,
> Huaimo
> *From:* Idr <[email-masked]> on behalf of Ketan Talaulikar (ketant)
> <ketant=[email-masked]>
> *Sent:* Thursday, July 23, 2020 6:02 AM
> *To:* Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> The individual version of this draft was called draft-li-idr-flowspec-rpd.
> When it came up for WG adoption, perhaps most people thought it was yet
> another Flowspec extension and did not have a close look at it.
>
>
>
> The draft got adopted in Nov 2019 and since then, there has hardly been
> any change for it (other than IANA allocations update) :
> https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-00&url2=draft-ietf-idr-rpd-05
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981956964&sdata=vUgOeTbdLbvoAWIi17vzORiS8UxREO4JoanDDuuGodM%3D&reserved=0>
>
>
>
> I am not sure if this document has received sufficient review and inputs
> from the WG over the recent 9 months of its life as a WG document. Those
> provided by Robert previously seem not to have been incorporated?
>
>
>
>    - How does the controller or provisioning entity know the status of
>    the Route Policy provisioning on the target router. Even that it was
>    successfully propagated to it and installed on it?
>    - Seems like one can have multiple policies advertised for a single
>    peer/neighbor? How would they be handled?
>    - The draft has support for IPv4 and IPv6 prefix list and AS regex.
>    What other route policy tools does the WG expect to extend in further
>    drafts? Perhaps we end up with yet another boatload of extension drafts for
>    BGP for RPD?
>
>
>
> We have Route Policy yang model defined at the IETF for provisioning of
> route policies that provide better and more comprehensive solution than the
> proposal in this document. That approach is also very robust from
> operational perspective. We don’t need to be putting this into BGP protocol.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* 17 July 2020 18:38
> *To:* Susan Hares <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=te9utkoi5bJl%2BT167KdWJQ%2BHYXaOaogxnvPQZLvbbWI%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C28cc9cc452284af4ab3508d82eef9d08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637310953981966953&sdata=uA9je9D95WX4sCUMQXWMpxWkKPo%2FbZY%2F1OiVNQKeggM%3D&reserved=0>
>
>

---

From: Brendon H <[email-masked]>
Date: Mon, 27 Jul 2020 23:42:13 +0000

sorry i've come in late on this "hot" topic, but after reviewing all the information.
i too agree with Roberts answer.

With regard to the questions posed by Susan.

Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

kind regards,

Brendon

Sent from Outlook<http://aka.ms/weboutlook>
________________________________
From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Sent: 28 July 2020 08:02
To: Huaimo Chen <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

> [HC]: Yang model seems mainly used in relatively static or stable configurations.

Well that's a problem with the "user" or bad habits not with the YANG model itself.

Nothing stops to use config push as dynamically as required to network elements.

Best,
Robert.

On Mon, Jul 27, 2020 at 10:57 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

[HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the route policy reaches the target router. When a BGP speaker as a controller sends a BGP UPDATE to a peer, there is no need for the ack from the peer about whether it is received, processed, and installed. The controller is monitoring the traffic of the network almost in real time, and adjusting the traffic dynamically almost in real time.. The former gets the status of the network regarding to the traffic.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 23, 2020 6:02 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Thanks,

Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 17 July 2020 18:38
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear IDR WG,

The prefix 0 which is in the draft is not the solution to the above problem..

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 28 Jul 2020 00:13:20 +0000

Hi all,

Thanks for your review and comments!

If we believe that wide community is an acceptable solution, then we will realize that RPD is a good use case to push the wide community forward.

RPD = New SAFI + wide community, and it is implemented in one administrator domain.
RPD can implement dynamic routing policy management per peer, per node, and per administrator domain.
And it can apply some optimization operations on the existing network. When the optimization operations are canceled, the network can return to the original running status.

Best regards,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Brendon H
Sent: Tuesday, July 28, 2020 7:42 AM
To: Robert Raszuk <[email-masked]>; Huaimo Chen <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

kind regards,

Brendon

Sent from Outlook<http://aka.ms/weboutlook>
________________________________
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 28 July 2020 08:02
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Best,
Robert.

     *   How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
[HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the route policy reaches the target router. When a BGP speaker as a controller sends a BGP UPDATE to a peer, there is no need for the ack from the peer about whether it is received, processed, and installed. The controller is monitoring the traffic of the network almost in real time, and adjusting the traffic dynamically almost in real time... The former gets the status of the network regarding to the traffic.

We have Route Policy yang model defined at the IETF for provisioning of route policies that provide better and more comprehensive solution than the proposal in this document. That approach is also very robust from operational perspective. We don't need to be putting this into BGP protocol.
[HC]: Yang model seems mainly used in relatively static or stable configurations. For frequently changing route policies, the solution proposed in the draft is more suitable. It makes the operations and maintenance on the network simpler. For example, in one metro area network without using the solution in the draft, planning and implementing an adjustment/redirection of a service traffic takes days. After the solution in the draft is deployed in the network with a controller NCE, this takes just minutes instead of days.

Best Regards,
Huaimo

+1 and I also agree on Jakob's comments/discussion on a parallel thread.

We have Route Policy yang model defined at the IETF for provisioning of route policies that provide better and more comprehensive solution than the proposal in this document. That approach is also very robust from operational perspective. We don't need to be putting this into BGP protocol.

Thanks,

Ketan

Dear IDR WG,

The prefix 0 which is in the draft is not the solution to the above problem...

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: "qinfengwei" <[email-masked]>
Date: Tue, 28 Jul 2020 09:56:05 +0800

Hi Sue,

 

Thanks,

Fengwei Qin

Its WG LC. 

Publication?  

Cheerily, Susan Hares

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Jul 2020 10:16:22 +0800

Hi all,

    IMO, it is a valuable exploration to enable more convenient negotiation in the network. 
    Perhaps, multiple solutions exist here, and the authors should clarify the difference. 
    I support of pushing it forward. 

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Zhuangshunwan
Date: 2020-07-28 08:13
To: Brendon H; Robert Raszuk; Huaimo Chen
CC: idr@ietf. org; Ketan Talaulikar \(ketant\); Susan Hares
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
Hi all,

 
 
Best regards,
Shunwan

 
 
Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

kind regards,
 
Brendon

Sent from Outlook

 

Best,
Robert.

On Mon, Jul 27, 2020 at 10:57 PM Huaimo Chen <[email-masked]> wrote:
Hi Ketan,

>Some more/other comments on why I believe this draft is not a good idea:
 
How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
[HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the route policy reaches the target router. When a BGP speaker as a controller sends a BGP UPDATE to a peer, there is no need for the ack from the peer about whether it is received, processed, and installed. The controller is monitoring the traffic of the network almost in real time, and adjusting the traffic dynamically almost in real time... The former gets the status of the network regarding to the traffic.
Seems like one can have multiple policies advertised for a single peer/neighbor? How would they be handled?
[HC]: For multiple policies advertised to a single peer/neighbor, they are processed one by one by the peer/neighbor..
The draft has support for IPv4 and IPv6 prefix list and AS regex. What other route policy tools does the WG expect to extend in further drafts? Perhaps we end up with yet another boatload of extension drafts for BGP for RPD?
[HC]: It seems that the current draft defines a small set of extensions (6 sub TLVs), which is enough to support adjusting the traffic dynamically in the live networks. If there are some new requirements in the future, the extensions would be small too. 

Best Regards,
Huaimo

 

 

How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
Seems like one can have multiple policies advertised for a single peer/neighbor? How would they be handled?
The draft has support for IPv4 and IPv6 prefix list and AS regex. What other route policy tools does the WG expect to extend in further drafts? Perhaps we end up with yet another boatload of extension drafts for BGP for RPD?

 
Thanks,
Ketan

Dear IDR WG, 

 

 
 
Ad 1) No. 
Ad 2) No.
Ad 3) No.. 
Ad 4) No. 
Ad 5) Yes.
 
Kind regards,
R.

 

 

 

Cheerily, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 28 Jul 2020 04:00:27 +0000

Hi Huaimo,

Please check inline below.

From: Huaimo Chen <[email-masked]>
Sent: 28 July 2020 02:27
To: Ketan Talaulikar (ketant) <[email-masked]>; Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Ketan,

     *   How does the controller or provisioning entity know the status of the Route Policy provisioning on the target router. Even that it was successfully propagated to it and installed on it?
[HC]:  It seems that BGP protocols guarantees the BGP UPDATE with the route policy reaches the target router. When a BGP speaker as a controller sends a BGP UPDATE to a peer, there is no need for the ack from the peer about whether it is received, processed, and installed. The controller is monitoring the traffic of the network almost in real time, and adjusting the traffic dynamically almost in real time.. The former gets the status of the network regarding to the traffic.
[KT] You/authors might have missed RFC7606 that talks about BGP error handling. I see that the draft does not even touch upon these aspects. So my concerns only gets compounded.

     *   Seems like one can have multiple policies advertised for a single peer/neighbor? How would they be handled?
[HC]: For multiple policies advertised to a single peer/neighbor, they are processed one by one by the peer/neighbor.
[KT] What is meant by "processed"? And I am not talking about BGP update processing but how potentially multiple Route Policies for the same peer are going to get handled and applied.

     *   The draft has support for IPv4 and IPv6 prefix list and AS regex. What other route policy tools does the WG expect to extend in further drafts? Perhaps we end up with yet another boatload of extension drafts for BGP for RPD?
[HC]: It seems that the current draft defines a small set of extensions (6 sub TLVs), which is enough to support adjusting the traffic dynamically in the live networks. If there are some new requirements in the future, the extensions would be small too.
[KT] Thanks for acknowledging that by picking up this work, the WG is going to open up floodgates for drafts related to Route Policies knobs down the line.

We have Route Policy yang model defined at the IETF for provisioning of route policies that provide better and more comprehensive solution than the proposal in this document. That approach is also very robust from operational perspective. We don't need to be putting this into BGP protocol.
[HC]: Yang model seems mainly used in relatively static or stable configurations. For frequently changing route policies, the solution proposed in the draft is more suitable. It makes the operations and maintenance on the network simpler. For example, in one metro area network without using the solution in the draft, planning and implementing an adjustment/redirection of a service traffic takes days. After the solution in the draft is deployed in the network with a controller NCE, this takes just minutes instead of days.
[KT] It seems at least some of us have a fundamental disconnect on this topic with the authors/proponents of this draft.

Thanks,
Ketan

Best Regards,
Huaimo
From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 28 Jul 2020 06:00:49 +0000

Inline.

This draft is nowhere near ready for publication. There are many unspecified items as below.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Huaimo Chen
Sent: Monday, July 27, 2020 1:57 PM
To: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Ketan,

[Jakob] Then the draft must discuss this. Unless the controller causes probe packets to be sent, it can only guess. The controller must monitor traffic at multiple locations. Which locations and how? Will it inject probe packets if there is no suitable traffic from users?

[Jakob] In what order? The draft simply introduces a "Distinguisher", but does not detail how it's used. Are the policies processed in distinguisher order? Other possibilities are to execute just one policy or to consider the case an error. The draft must discuss.

[Jakob] These are not enough to apply a different policy to each BGP neighbor of a speaker.
The draft states:
Users define a set of matching rules based on
       different attributes of routes, such as the destination address
       and the address of the router that advertises the routes.
However, there is no TLV to specify the router that advertises the route.
The router that advertises the route only makes sense for import policies. For export policies, it must be the router to which the route is advertised, but again, the draft makes no provision for that.

Best Regards,
Huaimo

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2020 08:20:11 +0200

Hi,

On Mon, Jul 27, 2020 at 08:57:22PM +0000, Huaimo Chen wrote:
> route policy reaches the target router. When a BGP speaker as a 
> controller sends a BGP UPDATE to a peer, there is no need for the ack 
> from the peer about whether it is received, processed, and installed. 

This sounds as if the controller would have / need to have a direct BGP 
session to each of the target routers.

Which makes the use of BGP as transport protocol even more a bad choice.

If you have point-to-point connections anyway, do not choose a transport
protocol that is built for "distribute information to devices many hops 
away".

Do not stuff BGP with more stuff that is not related to "transport of
routing information".  Vendors are having a hard time building robust and
interoperable BGP implementations already today.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jul 2020 10:58:52 +0200

Dear Shunwan,

On the point of wide communities they are indeed designed to automate
limited policy propagation within the AS and beyond.

But they travel along with the prefix from prefix originator or ingress to
a domain.

It was never the intention of wide community authors to use them as config
snippets containers to be sent p2p from controller to a router.

To summarize, if you implement wide communities you can use them along with
the prefixes to instruct the other side of the domain how to advertise your
routes. You do not need new SAFI for it.

Many thx,
R.

On Tue, Jul 28, 2020 at 2:13 AM Zhuangshunwan <[email-masked]>
wrote:

> If we believe that wide community is an acceptable solution, then we will
> realize that RPD is a good use case to push the wide community forward.
>
>
>
> And it can apply some optimization operations on the existing network.
> When the optimization operations are canceled, the network can return to
> the original running status.
>
>
>
> Best regards,
>
> Shunwan
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Brendon H
> *Sent:* Tuesday, July 28, 2020 7:42 AM
> *To:* Robert Raszuk <[email-masked]>; Huaimo Chen <
> [email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <ketant=
> [email-masked]>; Susan Hares <[email-masked]>
> Sent from Outlook <http://aka.ms/weboutlook>
> *From:* Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Sent:* 28 July 2020 08:02
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <
> ketant=[email-masked]>; Susan Hares <[email-masked]>
> the traffic dynamically almost in real time... The former gets the status
> of the network regarding to the traffic.
>
>
> processed one by one by the peer/neighbor..
>
>
> problem...

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 28 Jul 2020 10:05:53 +0000

Hi Robert,

Thank you for sharing the well-designed use cases of WideCommunity!  We have learned your excellent draft and have benefited greatly from it. https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

We believe that the use cases are not limited to the above. ISP' route policies can be classified into static policies and dynamic policies.  Especially, those ISPs who are managing IGWs and POPs often have to modify route policies on devices with great care. A suitable tool should be found for dynamic policies management.
Widecommunity is suitable for carrying route policies, so the RPD solution is proposed. In fact, the RPD solution is triggered by a large number of customer requirements.

I have one question for your per-prefix use cases: How do you set Widecommunity for prefixes?

Thanks,
Shunwan

From: Robert Raszuk [mailto:[email-masked]]
Sent: Tuesday, July 28, 2020 4:59 PM
To: Zhuangshunwan <[email-masked]>
Cc: Brendon H <[email-masked]>; Huaimo Chen <[email-masked]>; idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear Shunwan,

On the point of wide communities they are indeed designed to automate limited policy propagation within the AS and beyond.

But they travel along with the prefix from prefix originator or ingress to a domain.

It was never the intention of wide community authors to use them as config snippets containers to be sent p2p from controller to a router.

To summarize, if you implement wide communities you can use them along with the prefixes to instruct the other side of the domain how to advertise your routes. You do not need new SAFI for it.

Many thx,
R.

On Tue, Jul 28, 2020 at 2:13 AM Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Shunwan

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brendon H
Sent: Tuesday, July 28, 2020 7:42 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

kind regards,

Brendon

Best,
Robert.

Best Regards,
Huaimo

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jul 2020 12:18:46 +0200

Hello,

> I have one question for your per-prefix use cases: How do you set
Widecommunity for prefixes?

In pretty much exactly the same way today standard or extended or large
communities are being used.

Say on PE1 you are sourcing /24. However for some reasons you would like to
advertise it to your upstream ISP1 with AS-PATH X and to ISP2 with AS-PATH
X X X X as the origin ASN.

So you attach to the update advertised from PE1 the below wide community
which when parsed by the egress to ISP2 will do the actual prepend.

3 <https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02#section-3>.
Example

   Customer of the source AS number 100 requests to execute AS_PATH
   prepend 4 times when advertising the prefixes to AS number 2424.  We
   will use the following community assigned on ingress or at the prefix
   origination.

   PREPEND N TIMES TO AS
       Type: 0x0001                S = 0x00000064 (dec 100)
       F = 0x80                    C = 0x00000000
       H = 0x00                    T = 0x00000978 (dec 2424)
       L = 0x001D (dec 29 octets)  E = none
       R = IANA assigned           P = 0x04 (dec 4)

Thx,
R.

On Tue, Jul 28, 2020 at 12:06 PM Zhuangshunwan <[email-masked]>
wrote:

>
>
> Hi Robert,
>
>
>
> Thank you for sharing the well-designed use cases of WideCommunity!  We
> have learned your excellent draft and have benefited greatly from it.
> https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02
>
>
>
> We believe that the use cases are not limited to the above. ISP' route
> policies can be classified into static policies and dynamic policies.
> Especially, those ISPs who are managing IGWs and POPs often have to modify
> route policies on devices with great care. A suitable tool should be found
> for dynamic policies management.
>
> Widecommunity is suitable for carrying route policies, so the RPD solution
> is proposed. In fact, the RPD solution is triggered by a large number of
> customer requirements.
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Tuesday, July 28, 2020 4:59 PM
> *To:* Zhuangshunwan <[email-masked]>
> *Cc:* Brendon H <[email-masked]>; Huaimo Chen <
> [email-masked]>; idr@ietf. org <[email-masked]>; Ketan
> Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <
> [email-masked]>
> To summarize, if you implement wide communities you can use them along
> with the prefixes to instruct the other side of the domain how to advertise
> your routes. You do not need new SAFI for it.
>
>
>
> Many thx,
>
> R.
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Jul 2020 15:52:42 +0000

Hi Robert,

Thanks for your example of using wide community within normal BGP prefix updates. This could be one use case of wide community.

Since wide community provides the mechanism to carry matching criteria and the actions to be executed on the matched routes, this make it suitable for other scenarios, such as dynamic route policy provisioning at different granularity, such policy may be carried separately from the BGP prefix routes, so that it can be applied to a group of matched routes. Also the originator of the policy could be different from the originator of the routes.

The RPD draft proposes to introduce the route policy as a new address family, this is to separate the dynamic route policy for optimization (which may be temporary) from the base policy carried with the original routes, so that the effect of dynamic route policy can be controlled, which can also help to reduce the complexity in managing the policy interactions.

And I’d like to clarify about the possible misunderstanding of “P2P configuration”. Based on requirements, route policy may be applied on a group of BGP nodes for a set of peers, which also include the case of applying to one specific node or one specific peer. Maybe it could be clarified further in this document.

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 6:19 PM
To: Zhuangshunwan <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hello,

> I have one question for your per-prefix use cases: How do you set Widecommunity for prefixes?

In pretty much exactly the same way today standard or extended or large communities are being used.

Say on PE1 you are sourcing /24. However for some reasons you would like to advertise it to your upstream ISP1 with AS-PATH X and to ISP2 with AS-PATH X X X X as the origin ASN.

So you attach to the update advertised from PE1 the below wide community which when parsed by the egress to ISP2 will do the actual prepend.

3<https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02#section-3>.  Example

   origination.

   PREPEND N TIMES TO AS

       F = 0x80                    C = 0x00000000

Thx,

R.

On Tue, Jul 28, 2020 at 12:06 PM Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

Thanks,
Shunwan

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 28, 2020 4:59 PM
To: Zhuangshunwan <[email-masked]<mailto:[email-masked]>>
Cc: Brendon H <[email-masked]<mailto:[email-masked]>>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Dear Shunwan,

Many thx,
R.

Best regards,
Shunwan

Ad 1) No.
Ad 2) No.
Ad 3) No.
Ad 4) No.
Ad 5) Yes.

kind regards,

Brendon

Best,
Robert.

Best Regards,
Huaimo

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jul 2020 18:27:23 +0200

Hi,

> route policy may be applied on a group of BGP nodes for a set of peers

That is not how the NLRI format is defined. Today it is either single peer
or zero meaning all peers.

There is no provision for receiver groups.

But that's just the tip of the iceberg as indicated in this thread already.

Kind regards,
R.

On Tue, Jul 28, 2020 at 5:53 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> Thanks for your example of using wide community within normal BGP prefix
> updates. This could be one use case of wide community.
>
>
>
> Since wide community provides the mechanism to carry matching criteria and
> the actions to be executed on the matched routes, this make it suitable for
> other scenarios, such as dynamic route policy provisioning at different
> granularity, such policy may be carried separately from the BGP prefix
> routes, so that it can be applied to a group of matched routes. Also the
> originator of the policy could be different from the originator of the
> routes.
>
>
>
> The RPD draft proposes to introduce the route policy as a new address
> family, this is to separate the dynamic route policy for optimization
> (which may be temporary) from the base policy carried with the original
> routes, so that the effect of dynamic route policy can be controlled, which
> can also help to reduce the complexity in managing the policy interactions.
>
>
>
> And I’d like to clarify about the possible misunderstanding of “P2P
> configuration”. Based on requirements, route policy may be applied on a
> group of BGP nodes for a set of peers, which also include the case of
> applying to one specific node or one specific peer. Maybe it could be
> clarified further in this document.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, July 28, 2020 6:19 PM
> [email-masked]>; Huaimo Chen <[email-masked]>;
> Susan Hares <[email-masked]>
> Say on PE1 you are sourcing /24. However for some reasons you would like
> to advertise it to your upstream ISP1 with AS-PATH X and to ISP2 with
> AS-PATH X X X X as the origin ASN.
>
>
>
> 3
> <https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02#section-3>.
> Example
>
>
>
>
>

---

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 28 Jul 2020 21:13:52 +0100

Hi there,

This document seems to propose something that has a substantial disconnect
with operational aspects of practical networks. Routing policy is not an
unordered set of prefixes, attributes, and actions, it is strictly ordered,
and ordered nontrivially based on the intended outcome of that policy, and
not based on some standalone sorting property of separate policy elements.
It is not enough to advertise a policy entry to a node, it needs to be
inserted into a specific place in the policy. For the case of Flowspec it
works fine as filtering eventually is based on a longest prefix and that is
an implied sorting property, whereas routing policy in a general case is
not. BGP is unidirectional, and a fact that an update is received by a
remote node does not imply that the policy change is applied and it is not
known when it is applied. Without a feedback mechanism there is no way to
have a consistent policy within a node, and also no way to have a
consistent policy across a set of nodes. Routing policy information is not
necessarily a very public type of information, and an overall approach of
distributing it as wide as possible and then trying to limit and segregate
it for intended recipients is just not practical.

The fact that Flowspec can do something and it works does not mean that
functionality that has inherently different applicability and different
propagation properties should use that same model. Routing policy is a
configuration level construct, and there are no principal obstacles in the
field for dynamic policy modifications. For controlled policy adjustments
there are existing point to point BGP signalling mechanisms that could be
more suitable if a configuration based mechanism is not enough.

The major problem with progressing this document in the form it is now is a
message to the operations community that IDR is quite disconnected from the
problems and realities of the field. Vendors certainly can implement any
functionality they see fit and it is for the market to decide, RFCs are not
needed for that.

For specific answers to WGLC questions:

> 1) Do you feel this draft has an solution that is acceptable With the IPR
as a WG RFC?

No. It is not evident that the problem itself is clear, or exists at all in
a form as stated, it is not evident that the proposed mechanism was
socialized with the operations community for a feedback, and it is not
evident that the proposed solution fits into the operational practices as
seen in the field.

> 2) Do you feel this draft is ready to publish?

Not at all. There is little content in the document, it is underspecified
for being suitable for an interoperable implementation, and a larger part
of it is a compilation and a plain copy of fragments from other documents.

> 3) Do you know of implementations of this draft?

No.

> 4) Do you know of deployments of this draft? If so, is this feature
useful in the deployments.

Not aware of any deployments. Whether such functionality might be of use
for deployments is best to be queried in operational communities.

> 5) Do you feel that Wide Communities is ready for Publication?

Possibly, although wide communities is a completely separate document, and
the fact that -rpd- document uses wide communities as a transport container
does not imply that one or the other are ready because of that. Those
should be two separate WGLCs.

Ignas

---

From: [email-masked]
Date: Tue, 28 Jul 2020 15:14:49 -0700

Hi Sue,

1) No
2) No
3) No
4) No
5) Abstain

I object to this draft for the same reason that many others have already stated.  BGP is not a dump truck. BGP is not a configuration tool. Policy distribution should be done through Netconf/YANG, not via BGP. BGP is not a transport protocol, nor a peer-to-peer distribute database. Yes, you could do all of these things, but that doesn’t make it right.  You could also put things in DNS. That would also be wrong.

If you feel the need for a generic distributed database, please feel free to design one.  But not inside of BGP. That would be wrong.

Regards,
Tony Li, Ph.D.
Arista Networks
co-editor, RFC 4271

> On Jul 15, 2020, at 6:11 AM, Susan Hares <[email-masked]> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/ <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 29 Jul 2020 00:52:00 +0000

Hi Ketan,

    Thanks much for your further comments.
    My responses are inline below.

Best Regards,
Huaimo
________________________________
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Tuesday, July 28, 2020 12:00 AM
To: Huaimo Chen <[email-masked]>; Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi Huaimo,

Hi Ketan,

[HC2]: When Error occurs, there is a bug somewhere. The bug needs to be fixed. Even for the "strongest" action in Error-Handling approaches when Error occurs, "Session reset", it seems acceptable for the customers because the traffic adjusted/redirected may take its old path when the session is down and the route policies for adjusting the traffic are withdrawn.

[KT] What is meant by “processed”? And I am not talking about BGP update processing but how potentially multiple Route Policies for the same peer are going to get handled and applied.

[HC2]: It seems that there is no issue for multiple route policies for the same peer. The multiple route policies for adjusting the traffic are from the same controller, which will make sure they are not conflict.

[HC2]: This work seems similar to Flow Spec, which defines match conditions for flows/routes and actions. In Flow Spec, the actions redirect the traffic to a location for monitoring or drop. In the draft, the actions redirect the traffic to less congested path.

Thanks,

Ketan

Best Regards,

Huaimo

The draft got adopted in Nov 2019 and since then, there has hardly been any change for it (other than IANA allocations update) : https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-rpd-00&url2=draft-ietf-idr-rpd-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-idr-rpd-00%26url2%3Ddraft-ietf-idr-rpd-05&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486063048&sdata=0%2FRDHc2y4J%2BKw386bRPLqCfcgYAG%2B7rmA5Jpkpcq%2BiU%3D&reserved=0>

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486073042&sdata=6HatBziiSqWAMaFzuQaIyuC%2BboGKqbX0j5PeVkE1xMI%3D&reserved=0>

Its WG LC.

Publication?

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C9c1635db34c444dd2d5b08d832aaceff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315056486073042&sdata=7BXe4j%2BiGZ%2Fd6aKMhWBD5xgyU7jQzPZZ9X6xYqDrWCc%3D&reserved=0>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 Jul 2020 22:11:29 -0400

Hi,

I've read the draft and all the comments so far. See answers to the
questions below.

On Wed, Jul 15, 2020 at 9:11 AM Susan Hares <[email-masked]> wrote:
> start this WGLC to provide feedback to the author

Given the existing implementations/deployments and that it has a
separate AFI/SAFI, I am supportive of the idea.

> 2) Do you feel this draft is ready to publish?

I believe the draft needs some more work. It does not seem complete.
It also has some editorial problems. I am in the process of doing an
editorial review to send to the authors.

If this draft were progressed now, I think the directorate, shepherd,
etc., reviews would call for significant additions/changes.

> 4) Do you know of deployments of this draft?

I am not personally involved but there are implementations and
deployments as listed by others.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 29 Jul 2020 04:09:07 +0000

Hi Ketan,

> Not sure if I missed implementation reports or some operator feedback on this.

The implementation report:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations

Best Regards,
Huaimo

Thanks,

Ketan

Dear IDR WG,

Ad 1) No.

Ad 2) No.

Ad 3) No..

Ad 4) No.

Ad 5) Yes.

Kind regards,

R.

Its WG LC.

Publication?

Cheerily, Susan Hares

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 29 Jul 2020 04:29:20 +0000

Hi Robert,

Best Regards,
Huaimo
________________________________
From: Robert Raszuk <[email-masked]>
Sent: Friday, July 24, 2020 5:23 PM
To: Jakob Heitz (jheitz) <jheitz=[email-masked]>
Cc: Wanghaibo (Rainsword) <[email-masked]>; Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Match:

IPv4 prefix,
IPv6 prefix,
AS-PATH regex
Community

Set:

MED,
Arbitrary AS-PATH

[HC]: With the powerful wide community, the above small set of extensions seems enough to support for adjusting the traffic dynamically as required by the current customers.

[HC]: It seems that most of the above are not needed for now. If there are some new requirements, the extensions to the wide community should also be small.

Kind regards,
R.

Regards,

Jakob.

Hi Jakob,

Regards,

Haibo

Regards,

Jakob.

Hi Jakob,

Regards,

Haibo

From: Idr [mailto:[email-masked]<mailto:idr-bounces@ietf..org>] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 21, 2020 12:52 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

https://tools.ietf.org/html/rfc5575#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5575%23section-6&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C70731058275b420f1a4608d83017db3a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637312226385524258&sdata=Zr8BzKPugb%2BybRZx%2Bxf1NUEX5eRGyvcrgq9vSsPsYHk%3D&reserved=0>

states:

      determined in step a).

Regards,

Jakob.

Hi Jakob,

Best Regards,

- Atomic Transactions:

- Feedback:

  BGP is "spray and pray".

- Persistence:

Regards,

Jakob.

https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C70731058275b420f1a4608d83017db3a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637312226385524258&sdata=RpJFETDDVlv6pUu4%2BbOQ7ZnW%2Bkit3gHHVBvrd1p5vco%3D&reserved=0>

Its WG LC.

Publication?

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C70731058275b420f1a4608d83017db3a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637312226385534248&sdata=f7UuURBbwLsYbre%2B%2FgQnwsZ9zyDL9TcXVPfJtQSmVC0%3D&reserved=0>

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 29 Jul 2020 09:37:20 +0000

Hi Donald,

Thank you for your review and great help! Look forward to working with you and everyone in IETF community to improve this work.

Best Regards,
Shunwan

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Wednesday, July 29, 2020 10:11 AM
To: Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

Hi,

I've read the draft and all the comments so far. See answers to the questions below.

On Wed, Jul 15, 2020 at 9:11 AM Susan Hares <[email-masked]> wrote:
> This begins a 2 week WG LC on draft-ietf-idr-rpd from 7/15 to 
> 7/29/2020.  You can obtain this draft at:
> This draft defines a new AFI/SAFI and new atoms for the Wide 
> Communities.  This WG LC has been delayed as I waited for a 
> resubmission of the Wide Communities draft.
> I’ve not received the Wide Communities draft, but we will start this 
> WGLC to provide feedback to the author We may have to run a short 
> follow-up to this WG LC
>
> If there are changes to the Wide Communities draft during Its WG LC.
>

Given the existing implementations/deployments and that it has a separate AFI/SAFI, I am supportive of the idea.

I believe the draft needs some more work. It does not seem complete.
It also has some editorial problems. I am in the process of doing an editorial review to send to the authors.

If this draft were progressed now, I think the directorate, shepherd, etc., reviews would call for significant additions/changes.

> 4) Do you know of deployments of this draft?

I am not personally involved but there are implementations and deployments as listed by others.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA  [email-masked]