Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

From: "Susan Hares" <[email-masked]>
Date: Fri, 4 Feb 2022 07:39:17 -0500

Resending the adoption call - with the appropriate header 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 7:33 AM
To: [email-masked]
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to
2/18/2022)

This begins a 2 week WG adoption call  for 

draft-wang-idr-vpn-prefix-orf-00.txt 

https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf. 

In your discussion on adoption, please consider the following questions: 

1) Does this draft describe problems existing in networks today? 

2) Does the solution describe address these problems? 

The solution has both a general solution and BGP encodings. 

3) Would the solution be useful in networks today? 

Thank you, Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 7 Feb 2022 08:40:01 +0800

Hi, Susan and all:

I support the adoption of this draft.

The responses for your questions are inline below.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 8:39 PM
To: [email-masked]
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022
to 2/18/2022)

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 7:33 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to
2/18/2022)

[WAJ]   Yes. Section 4.1 of this draft describe briefly the
scenarios/problems existing in networks today. 

[WAJ] Yes. The solution proposed in this draft can address the VPN prefixes
control within one AS. 

[WAJ] Yes. It can accomplish the fine control for the VPN prefixes on one
shared BGP session(between PE/RR).

Thank you, Susan Hares

---

From: "Wei Wang" <[email-masked]>
Date: Mon, 7 Feb 2022 11:02:06 +0800

Hi Susan and WG,

&nbsp; &nbsp; We found some editorial errors during review the draft, so we updated it with -v01. Please review base on this version:&nbsp;https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01
&nbsp; &nbsp; As the co-author, I support the adoption of this draft.&nbsp; &nbsp;&nbsp;

Best Regards,
Wei

------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Susan Hares"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Fri, Feb 4, 2022 08:39 PM
To:&nbsp;"idr"<[email-masked]&gt;;

Subject:&nbsp;[Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Resending the adoption call – with the appropriate header 

&nbsp;

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 7:33 AM
To: [email-masked]
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)

&nbsp;

This begins a 2 week WG adoption call &nbsp;for 

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

Thank you, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Feb 2022 00:20:41 -0500

Hi Susan and WG

As co-author I support WG adoption.

 Yes.  This is an issue that exists today in operator networks which does
not have a solution.

Yes.  The solution provides the ability to filter routes based on offending
PE flooding routes either L2 or L3 VPN and can be used for both intra-as
and inter-as.

 Yes.  The solution would be very useful in todays networks providing the
granularity to filter on offending PE.

Gyan

On Fri, Feb 4, 2022 at 7:41 AM Susan Hares <[email-masked]> wrote:

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Friday, February 4, 2022 7:33 AM
> *To:* [email-masked]
> *Subject:* [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to
> 2/18/2022)
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 7 Feb 2022 11:52:56 +0000

Do not support

Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Monday, February 7, 2022 12:21 AM
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Hi Susan and WG

1) Does this draft describe problems existing in networks today?
 Yes.  This is an issue that exists today in operator networks which does not have a solution.
2) Does the solution describe address these problems?
Yes.  The solution provides the ability to filter routes based on offending PE flooding routes either L2 or L3 VPN and can be used for both intra-as and inter-as.
The solution has both a general solution and BGP encodings.

3) Would the solution be useful in networks today?
 Yes.  The solution would be very useful in todays networks providing the granularity to filter on offending PE.

Gyan

On Fri, Feb 4, 2022 at 7:41 AM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Resending the adoption call – with the appropriate header

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 7:33 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)

This begins a 2 week WG adoption call  for
draft-wang-idr-vpn-prefix-orf-00.txt
https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf__;!!BhdT!wLrKr5p_hac8y70cbmuUqq_ZNN27bTD34hpS-ru-LcK4LDCTnsquCrq61Ls$>.

Thank you, Susan Hares
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!wLrKr5p_hac8y70cbmuUqq_ZNN27bTD34hpS-ru-LcK4LDCTnsqu0KTXdMg$>
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!BhdT!wLrKr5p_hac8y70cbmuUqq_ZNN27bTD34hpS-ru-LcK4LDCTnsquJmr0_fw$>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Feb 2022 13:27:36 +0100

Dear WG,

I do not support this draft to be adopted as a WG doc.

The problem of resource starvation in L3VPN deployments has been known
since day one. There is number of tools available to address it today. That
is not to say that the toolkit is closed. We welcome new solutions, but the
solution proposed in the draft does not pass basic BGP proof test.

> The solution has both a general solution and BGP encodings.

No. It's a big hammer potentially affecting other VPNs subject to extra
logic on the RRs. And if propagated further (which is against no
transitiveness of ORF msg) it will break other VPNs easily.

The draft does a lot of hand waving and extra logic being pushed on the
implementation on RRs to mitigate those issues. This is not something we
can adopt in the current form.

No.

- - -

I can think of number of other solutions if existing ones do not suffice.

For example one may want to define per VPN list of acceptable prefixes per
PE. One could define a way to propagate RT+ prefix limit which could be
much more useful then just RD block rock. Prefix ORF is another one which
could be used. Last inbound drop on the weak PEs is a very cheap operation
and such drop can be based on any field RD included locally on affected
PEs. Lot's of alternatives exist and is used daily in pretty large
production networks.

Paramount to all of this is that RD's role is to make prefixes unique. No
more and no less.

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Mon, 7 Feb 2022 23:22:02 +0800

Hi, Robert:

Aijun Wang
China Telecom

> 在 2022年2月7日，20:28，Robert Raszuk <[email-masked]> 写道：
> 
> 
> Dear WG, 
> 
> The problem of resource starvation in L3VPN deployments has been known since day one. There is number of tools available to address it today. That is not to say that the toolkit is closed. We welcome new solutions, but the solution proposed in the draft does not pass basic BGP proof test. 
[WAJ] How to let you get such conclusions? Please explain more.
> No. It's a big hammer potentially affecting other VPNs subject to extra logic on the RRs. And if propagated further (which is against no transitiveness of ORF msg) it will break other VPNs easily. 

[WAJ] Have you read the updated version of this draft? There is no extra logic on the RR except the normal ORF mechanism.

> 
> The draft does a lot of hand waving and extra logic being pushed on the implementation on RRs to mitigate those issues. This is not something we can adopt in the current form. 

[WAJ] RR just accomplish the normal ORF filter action. Where is the logic that you worried?

> For example one may want to define per VPN list of acceptable prefixes per PE.

[WAJ] List the acceptable prefixes explicitly?

> One could define a way to propagate RT+ prefix limit which could be much more useful then just RD block rock. 

[WAJ] Please read again the updated draft. It is not JUST RD block.

> Prefix ORF is another one which could be used.
[WAJ] We have discussed intensively for this approaches. Would you like to discuss it again? 

> Last inbound drop on the weak PEs is a very cheap operation and such drop can be based on any field RD included locally on affected PEs. 

[WAJ] Inbound drop doesn’t relieve the weak PE from such offending VPN prefixes. The weak PE is still busying to receive and parse such offending VPN prefixes.

> Lot's of alternatives exist and is used daily in pretty large production networks. 
> 
> Paramount to all of this is that RD's role is to make prefixes unique. No more and no less. 
[WAJ] The updated draft doesn’t focus on RD only now.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 7 Feb 2022 15:36:08 +0000

I agree with Robert.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, February 7, 2022 at 7:28 AM
To: Susan Hares <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Dear WG,

No.

- - -

For example one may want to define per VPN list of acceptable prefixes per PE. One could define a way to propagate RT+ prefix limit which could be much more useful then just RD block rock. Prefix ORF is another one which could be used. Last inbound drop on the weak PEs is a very cheap operation and such drop can be based on any field RD included locally on affected PEs. Lot's of alternatives exist and is used daily in pretty large production networks.

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Mon, 7 Feb 2022 23:42:16 +0800

Hi, Jim:

Do you still worry the scenarios? Or is there any other concerns?
Would like to hear more information from you and we will try to explain in detail to solve your concerns.

Aijun Wang
China Telecom

> 在 2022年2月7日，19:54，UTTARO, JAMES <[email-masked]> 写道：
> 
> 
> Do not support
>  
> Jim Uttaro
>  
> Email [email-masked]
> M 301 502-1347
> 
>

---

From: John E Drake <[email-masked]>
Date: Mon, 7 Feb 2022 15:52:39 +0000

As do I

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, February 7, 2022 10:36 AM
To: Robert Raszuk <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

[External Email. Be cautious of content]

I agree with Robert.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 7, 2022 at 7:28 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Dear WG,

No.

- - -

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Tue, 8 Feb 2022 00:00:40 +0800

Hi, John and Acee:
Glad to hear more from your own points. If not, please see my replies to Robert, or follow the following discussions.

Aijun Wang
China Telecom

> 在 2022年2月7日，23:58，John E Drake <jdrake=[email-masked]> 写道：
> 
> 
> As do I
>  
> Yours Irrespectively,
>  
> John
>  
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Feb 2022 17:28:29 +0100

Aijun,

> [WAJ] The updated draft doesn’t focus on RD only now.

Yes it is extended to filter on RD + new objects for example on RT .. by
defining a new TLV in section 7.2 to be stuffed to new ORF message.

So this is now even worse then before.

It would only work if given VPN prefix would be sent by sourcing PE with
single RT per message.

But it is never the case as per basic BGP rules given prefix can be sent
only once so it contains all RTs attached on export. Subsequent sent would
be an implicit withdraw. So filtering both on RD and RT makes no sense at
all.

Kind regards,
Robert.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 8 Feb 2022 07:48:27 +0800

Hi, Robert:
I think you miss the point again.

https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.2 states clearly the scenarios and solutions when multiple RTs are associated with the offending VPN prefixes.

Aijun Wang
China Telecom

> 在 2022年2月8日，00:28，Robert Raszuk <[email-masked]> 写道：
> 
> Aijun,
> Yes it is extended to filter on RD + new objects for example on RT .. by defining a new TLV in section 7.2 to be stuffed to new ORF message. 
> 
> It would only work if given VPN prefix would be sent by sourcing PE with single RT per message. 
> 
> But it is never the case as per basic BGP rules given prefix can be sent only once so it contains all RTs attached on export. Subsequent sent would be an implicit withdraw. So filtering both on RD and RT makes no sense at all. 
> 
> Kind regards,
> Robert.
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Feb 2022 00:55:16 +0100

Aijun,

>  In this scenario, RD is allocated per VPN or per PE.

That is a broken deployment model. Building any solution

to address such deployment model in 2022 should be highly

discouraged if not denied.

Thx,
R.

On Tue, Feb 8, 2022 at 12:48 AM Aijun Wang <[email-masked]>
wrote:

> https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.2 states
> clearly the scenarios and solutions when multiple RTs are associated with
> the offending VPN prefixes.
>
> Aijun Wang
> China Telecom
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 8 Feb 2022 08:55:19 +0800

Hi, Robert:
The RD is allocated per VPN or per PE. 
What your strategy to allocate the RD in year 2022?

Aijun Wang
China Telecom

> 在 2022年2月8日，07:55，Robert Raszuk <[email-masked]> 写道：
> 
> 
> Aijun,
> 
>> On Tue, Feb 8, 2022 at 12:48 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Feb 2022 01:57:35 +0100

> The RD is allocated per VPN or per PE.

Whow !

> What your strategy to allocate the RD in year 2022?

Since around 2003 the strategy and recommendation (for multiple reasons) is
to allocate RD per VRF.

Kind regards,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 8 Feb 2022 09:08:20 +0800

Hi, Robert:
Here there may be some misunderstanding or we didn’t describe it clearly.
You can see from the figure 2, the RD is actually  allocated per VRF(Actually the description should be per VPN per PE=per VRF)

If this addresses your concerns, we can update the description later to reflect this more clearly.

Aijun Wang
China Telecom

> 在 2022年2月8日，08:57，Robert Raszuk <[email-masked]> 写道：
> 
> 
> Since around 2003 the strategy and recommendation (for multiple reasons) is to allocate RD per VRF. 
> 
> Kind regards,
> R.
>

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 8 Feb 2022 01:17:22 +0000

Hi Sue and WG,

I support WG adoption.
1) Does this draft describe problems existing in networks today?
 Yes.  Currently, a solution is needed to solve the problems existing in VPN deployment.
2) Does the solution describe address these problems?
Yes.  The current draft has been actively discussed by the WG in the past months, now it is a result of the joint efforts of the WG, and it is worth continuing to optimize it as a WG draft.
3) Would the solution be useful in networks today?
 Yes.  The solution would help to quickly isolate a faulty VPN and avoid further deterioration of the network operation status.
Best Regards,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 8:39 PM
To: [email-masked]
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Thank you, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Feb 2022 23:24:56 -0500

Hi Robert

Scenario 1 and 2, figure 1 and 2 are unique RD per PE  means per PE unique
RD and Scenario 3 Universal RD means per VPN RD meaning all PEs for the VPN
have the same RD.

Kind Regards

Gyan

On Mon, Feb 7, 2022 at 8:09 PM Aijun Wang <[email-masked]> wrote:

> You can see from the figure 2, the RD is actually  allocated per
> VRF(Actually the description should be per VPN per PE=per VRF)
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Feb 2022 23:28:16 -0500

We will clean up the confusing verbiage which says per VPN or per PE which
is  stating two opposites both unique and global RD at the same time.

Kind Regards

Gyan
On Mon, Feb 7, 2022 at 11:24 PM Gyan Mishra <[email-masked]> wrote:

>>>> Yes it is extended to filter on RD + new objects for example on RT ..
>>>> by defining a new TLV in section 7.2 to be stuffed to new ORF message.
>>>>
>>>> But it is never the case as per basic BGP rules given prefix can be
>>>> sent only once so it contains all RTs attached on export. Subsequent sent
>>>> would be an implicit withdraw. So filtering both on RD and RT makes no
>>>> sense at all.
>>>>
>>>> Kind regards,
>>>> Robert.
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 16 Feb 2022 02:12:41 +0000

Hi Everyone,

    I read through the draft and support its adoption.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Friday, February 4, 2022 7:39 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-idr-vpn-prefix-orf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C8f171b0aa9104211f25008d9e7db9c93%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637795752683936501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qEOqYN0htdBM7aVFNkF5RZ8TsWxPFD39%2FQG95y3ohAk%3D&reserved=0>.

Thank you, Susan Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 16 Feb 2022 09:00:05 +0000

I support the adoption of this document.

It is possible the excessive VPN routes received could be identified with common RD or source PE attributes, in this case it provides a mechanism to selectively filter those suspicious routes on the sender side and keep the normal VPN routes and service unimpacted.

The document illustrates the possible scenarios where this mechanism can be applied, its applicability in other scenarios could be discussed further.

Best regards,
Jie

Thank you, Susan Hares

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 16 Feb 2022 14:19:53 +0000

I support the adoption of this document.
I think the draft does describe a problem in some operators' networks even though other operators might not experience the similar problem. The solution described in the draft address the problem. Therefore, the solution is useful.

Best regards,
Linda

This begins a 2 week WG adoption call  for
draft-wang-idr-vpn-prefix-orf-00.txt
https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-idr-vpn-prefix-orf&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C800d0cfd36de4b2a369608d9f12acb0b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637805988389602621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SbJHux0wryccmceOWU1nu%2BJS6UmTnZXKSHJtp%2B0v2ng%3D&reserved=0>.

Thank you, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 18 Feb 2022 11:44:28 +0000

Hi All,
       I support this adoption.
      This document proposes a solution to optimize VPN route exceed the prefix limit, which can solve some of these scenarios.
       Therefore, the solution is useful.

Regards,
Haibo

Thank you, Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Feb 2022 10:52:33 -0500

[Speaking as an individual contributor.]

Sue,

I do not support adoption of this draft.

After various discussions about the scope of the feature the authors seem to intend that:
- It address exhaustion by a Provider Edge device of RIB (and subsequently FIB) resources.
- Part of the concern is BGP messaging load on the receiving PE.
- This can be mitigated by causing remote drop of some portion of impactful routes.

The proposal has the issues that it:
- Will require additional per-route per-VRF counter state (potentially useful, somewhat expensive to implement)
- Does not provide an algorithm to determine drop, meaning no consistent local implementation of the feature.
- Does not address edge conditions wherein multiple classes of routes may be eligible for drop
- Will impose additional load on upstream BGP devices such as route reflectors to implement the filters
- Cannot guarantee prompt mitigation of the issues of concern.  Local filtering will be required as a mitigation during ORF installation at the upstream device.
- Installation of the ORF will generate additional messages for the withdraw messaging.

Much of the conversation about local PE behaviors amounts to, "I'll know it when I see it".  Implementation choice may be reasonable, but is too vague for the local end of a standard.

Discussion of this feature has resulted in the specification improving its clarity, but I don't foresee the above points converging across the disagreeing parties.

My recommendation is that if the authors wish to progress this proposal that they make it Experimental, request a First Come, First Served ORF code point from IANA, and take the draft to the Independent Submissions Editor track.

-- Jeff

> On Feb 4, 2022, at 7:39 AM, Susan Hares <[email-masked]> wrote:
> 
> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Susan Hares
> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf <https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf>. 
>  
> <Untitled attachment 00214.txt>_______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 22 Feb 2022 07:01:30 +0800

Hi,Jeffrey:
All your concerns are the detail implementation considerations, I don’t think the protocols standards should focus mainly how to implement.
And, can you give some examples that there is no cost or influences to the devices but beneficial to the devices at the same times within BGP protocol?
According to the rules of IDR WG, there should be two independent implementations to forward the draft after its adoption. I think your concerns will be addressed during the implementation process and we can give you the final answer to your questions.
If you obstacles or raise the bar for the adoption call of this draft in such way, I think every document in IDR WG should also answer such kind questions and take the same procedures.
If you can’t give the example that there is such example to free to answer your questions, I object your proposal/bar to this document.

Aijun Wang
China Telecom

> 在 2022年2月21日，23:53，Jeffrey Haas <[email-masked]> 写道：
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 21 Feb 2022 23:46:01 +0000

+1

Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Monday, February 21, 2022 10:53 AM
To: Sue Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Sue,

-- Jeff

On Feb 4, 2022, at 7:39 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

This begins a 2 week WG adoption call  for
draft-wang-idr-vpn-prefix-orf-00.txt
https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf__;!!BhdT!nm_2jZVYnj-Ymk-R-do6xtYAhW1Mcvon0MQEyihUvEqlaTkdiGSO9bPhs3ynpkGjtLV8bfY$>.

Thank you, Susan Hares
<Untitled attachment 00214.txt>_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!nm_2jZVYnj-Ymk-R-do6xtYAhW1Mcvon0MQEyihUvEqlaTkdiGSO9bPhs3ynpkGjwjYX0u8$>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 22 Feb 2022 08:57:10 +0800

Hi, Jim:

If you understand Jeff’s points, please give your opinions upon my responses to his concerns.

If you don’t’ understand Jeff’s points, please raise your own analysis, we will try to address your concerns.

If you have no your own analysis, please just to keep follow the discussion.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of UTTARO, JAMES
Sent: Tuesday, February 22, 2022 7:46 AM
To: Jeffrey Haas <[email-masked]>; Sue Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

+1 

Jim Uttaro

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Jeffrey Haas
Sent: Monday, February 21, 2022 10:53 AM
To: Sue Hares <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Sue,

-- Jeff

On Feb 4, 2022, at 7:39 AM, Susan Hares <[email-masked] <mailto:[email-masked]> > wrote:

From: Idr [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, February 4, 2022 7:33 AM
To:  <mailto:[email-masked]> [email-masked]
Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)

 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf__;!!BhdT!nm_2jZVYnj-Ymk-R-do6xtYAhW1Mcvon0MQEyihUvEqlaTkdiGSO9bPhs3ynpkGjtLV8bfY$> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf. 

Thank you, Susan Hares 

<Untitled attachment 00214.txt>_______________________________________________
Idr mailing list
 <mailto:[email-masked]> [email-masked]
 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!nm_2jZVYnj-Ymk-R-do6xtYAhW1Mcvon0MQEyihUvEqlaTkdiGSO9bPhs3ynpkGjwjYX0u8$> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Feb 2022 08:44:26 -0500

Aijun,

> If you obstacles or raise the bar for the adoption call of this draft in such way, I think every document in IDR WG should also answer such kind questions and take the same procedures.

I consistenly do the same analysis for BGP extensions and have been doing so
for my entire career.

Is the proposed feature implementable? [1]
Does the proposed feature solve the problem it claims to solve?
- If not, does it serve other positive uses?
Does the feature scale?
Can the feature be incrementally deployed?

I invite everyone to apply these criteria to every piece of IETF work as
responsible contributors to IETF process.

> If you can’t give the example that there is such example to free to answer your questions, I object your proposal/bar to this document.

You are free to object to my lack of support.  Sue is the Chair that will be
making the consensus calls regarding this document.

Your vendors are also free to request a first-come, first-serve code point
for this ORF and begin coding TODAY.

-- Jeff

[1] https://www.rfc-editor.org/rfc/rfc1925.html, §2.(1)
    Other sections also apply.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 22 Feb 2022 23:15:57 +0800

Hi, Jeffrey:
I think the current draft meet all your criteria of adoption that are listed below. Isn’t it?
I know your concerns for the detail implementation and we have discussed offline with our co-authors. The contents in current draft are our initial considerations for various situations.
There certainly will be tuned/updated for some contents/considerations in the document along the implementation experiences. I think this is also the normal procedures of IDR WG document.
We are planning to implement this feature after its adoption , do some simulation for the radical scenarios that you(also Robert, and other experts) concerned.
The simulation results will be shared to the community to give the guidelines for future widespread deployment.
We are also eager to invite more vendors join us to accomplish this feature.
The network should evolved to heal itself.

And there are enough efforts/discussions and interests for this feature to be adopted. Adopt this document  just the start point of this feature to be realized.

Aijun Wang
China Telecom

> 在 2022年2月22日，21:44，Jeffrey Haas <[email-masked]> 写道：
> 
> Aijun,
>

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Feb 2022 00:21:19 +0000

The outcome of this draft will result in non-deterministic sets of 
prefixes ending up on PEs, e.g.

>     PEs and RR should have some mechanisms to identify and control the
>     advertisement of excessive VPN routes.

>     The operation of VPN Prefix ORF mechanism on each device is
>     independent, each of them makes a local judgement to determine
>     whether it needs to send VPN Prefix ORF to its peers.

It seems likely that there are scenarios where this would result in 
unexpected blackholing of traffic due to breakage in forward or return 
paths.  This is not desirable from an operational point of view.  It 
would be unwise for the WG to adopt this draft without clarifying how 
this policy is created and can be applied consistently across all 
devices in a vpn domain.

Nick

Aijun Wang wrote on 21/02/2022 23:01:
> Hi,Jeffrey:
> All your concerns are the detail implementation considerations, I 
> don’t think the protocols standards should focus mainly how to implement.
> And, can you give some examples that there is no cost or influences to 
> the devices but beneficial to the devices at the same times within BGP 
> protocol?
> According to the rules of IDR WG, there should be two independent 
> implementations to forward the draft after its adoption. I think your 
> concerns will be addressed during the implementation process and we 
> can give you the final answer to your questions.
> If you obstacles or raise the bar for the adoption call of this draft 
> in such way, I think every document in IDR WG should also answer such 
> kind questions and take the same procedures.
> If you can’t give the example that there is such example to free to 
> answer your questions, I object your proposal/bar to this document.
>
> Aijun Wang
> China Telecom
>
>> - Will require additional per-route per-VRF counter state 
>> (potentially useful, somewhat expensive to implement)
>> - Does not provide an algorithm to determine drop, meaning no 
>> consistent local implementation of the feature.
>> - Cannot guarantee prompt mitigation of the issues of concern.  Local 
>> filtering will be required as a mitigation during ORF installation at 
>> the upstream device.
>> Much of the conversation about local PE behaviors amounts to, "I'll 
>> know it when I see it".  Implementation choice may be reasonable, but 
>> is too vague for the local end of a standard.
>>
>> Discussion of this feature has resulted in the specification 
>> improving its clarity, but I don't foresee the above points 
>> converging across the disagreeing parties.
>>
>> My recommendation is that if the authors wish to progress this 
>> proposal that they make it Experimental, request a First Come, First 
>> Served ORF code point from IANA, and take the draft to the 
>> Independent Submissions Editor track.
>>
>> -- Jeff
>>
>>
>>> *From:*Idr [mailto:[email-masked]]*On Behalf Of*Susan Hares
>>> *Sent:*Friday, February 4, 2022 7:33 AM
>>> *To:[email-masked] <mailto:[email-masked]>
>>> *Subject:*[Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 
>>> 2/18/2022)
>>> <Untitled attachment 
>>> 00214.txt>_______________________________________________
>>> Idr mailing list

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 23 Feb 2022 09:11:16 +0800

Hi, Nick:

This draft described the behavior of the PE and RR, have you reviewed the draft in detail?

The ORF filter is applied independently to each PE that originated such message.  It does not prevent other PEs in the same VPN acts also in same manner.

Would you like to give the example that you worried about “result in unexpected blackholing of traffic due to breakage in forward or return paths.” ?

And one thing you should know that if we don’t have such mechanism, what we can do is to drop the excessive routes locally.

The VPN Prefix ORF mechanism just optimize such actions.

Best Regards

Aijun Wang

China Telecom

From: Nick Hilliard <[email-masked]> 
Sent: Wednesday, February 23, 2022 8:21 AM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

The outcome of this draft will result in non-deterministic sets of prefixes ending up on PEs, e.g.

It seems likely that there are scenarios where this would result in unexpected blackholing of traffic due to breakage in forward or return paths.  This is not desirable from an operational point of view.  It would be unwise for the WG to adopt this draft without clarifying how this policy is created and can be applied consistently across all devices in a vpn domain.

Nick

Hi,Jeffrey: 

Aijun Wang

China Telecom

在 2022年2月21日，23:53，Jeffrey Haas  <mailto:[email-masked]> <[email-masked]> 写道：

Sue,

-- Jeff

 <https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf. 

Thank you, Susan Hares 

<Untitled attachment 00214.txt>_______________________________________________
Idr mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/idr> https://www.ietf.org/mailman/listinfo/idr

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Feb 2022 09:25:17 +0000

Aijun,

can you describe how devices on the network select which prefixes go 
into the ORF list?

Nick

Aijun Wang wrote on 23/02/2022 01:11:
> The ORF filter is applied independently to each PE that originated 
> such message.  It does not prevent other PEs in the same VPN acts also 
> in same manner.
>
> Would you like to give the example that you worried about “result in 
> paths.” ?
> And one thing you should know that if we don’t have such mechanism, 
> what we can do is to drop the excessive routes locally.
>
> *From:*Nick Hilliard <[email-masked]>
> *Sent:* Wednesday, February 23, 2022 8:21 AM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption 
> call (2/4/2022 to 2/18/2022)
>
>     And, can you give some examples that there is no cost or
>     influences to the devices but beneficial to the devices at the
>     same times within BGP protocol?
>
>     implementations to forward the draft after its adoption. I think
>     your concerns will be addressed during the implementation process
>     and we can give you the final answer to your questions.
>
>     If you obstacles or raise the bar for the adoption call of this
>     draft in such way, I think every document in IDR WG should also
>     answer such kind questions and take the same procedures.
>
>     If you can’t give the example that there is such example to free
>     to answer your questions, I object your proposal/bar to this document.
>
>     Aijun Wang
>
>     China Telecom
>
>
>
>         在2022年2月21日，23:53，Jeffrey Haas <[email-masked]>
>         <mailto:[email-masked]> 写道：
>
>         - Will impose additional load on upstream BGP devices such as
>         route reflectors to implement the filters
>
>         - Cannot guarantee prompt mitigation of the issues of concern.
>          Local filtering will be required as a mitigation during ORF
>         installation at the upstream device.
>
>         Much of the conversation about local PE behaviors amounts to,
>         "I'll know it when I see it".  Implementation choice may be
>         reasonable, but is too vague for the local end of a standard.
>
>         proposal that they make it Experimental, request a First Come,
>         First Served ORF code point from IANA, and take the draft to
>         the Independent Submissions Editor track.
>
>         -- Jeff
>
>
>
>             *Subject:*[Idr] draft-wang-idr-vpn-prefix-orf-00.txt :
>             (2/4/2022 to 2/18/2022)
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Feb 2022 13:23:00 +0100

Aijun,

> what we can do is to drop the excessive routes locally.

In well managed network you do not have "excessive routes".

It is your operations failure which you are trying to mask by randomly
dropping routes. This is a symptom of a very unhealthy network condition
and putting such a bandage is not a proper cure.

Rgs,
R.

On Wed, Feb 23, 2022 at 2:11 AM Aijun Wang <[email-masked]>
wrote:

> The ORF filter is applied independently to each PE that originated such
> message.  It does not prevent other PEs in the same VPN acts also in same
> manner.
>
> And one thing you should know that if we don’t have such mechanism, what
> we can do is to drop the excessive routes locally.
>
> *From:* Nick Hilliard <[email-masked]>
> *Subject:* Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call
> (2/4/2022 to 2/18/2022)
>
>
>
> paths.  This is not desirable from an operational point of view.  It would
> be unwise for the WG to adopt this draft without clarifying how this policy
> is created and can be applied consistently across all devices in a vpn
> domain.
>
> Nick
>
> All your concerns are the detail implementation considerations, I don’t
> think the protocols standards should focus mainly how to implement.
>
> And, can you give some examples that there is no cost or influences to the
> devices but beneficial to the devices at the same times within BGP protocol?
>
> concerns will be addressed during the implementation process and we can
> give you the final answer to your questions.
>
> If you obstacles or raise the bar for the adoption call of this draft in
> such way, I think every document in IDR WG should also answer such kind
> questions and take the same procedures.
>
> If you can’t give the example that there is such example to free to answer
> your questions, I object your proposal/bar to this document.
>
> Aijun Wang
>
> China Telecom
>
>
>
> 在 2022年2月21日，23:53，Jeffrey Haas <[email-masked]> <[email-masked]> 写道：
>
> filtering will be required as a mitigation during ORF installation at the
> upstream device.
>
> Much of the conversation about local PE behaviors amounts to, "I'll know
> it when I see it".  Implementation choice may be reasonable, but is too
> vague for the local end of a standard.
>
>
>
> Discussion of this feature has resulted in the specification improving its
> clarity, but I don't foresee the above points converging across the
> disagreeing parties.
>
>
>
> My recommendation is that if the authors wish to progress this proposal
> that they make it Experimental, request a First Come, First Served ORF code
> point from IANA, and take the draft to the Independent Submissions Editor
> track.
>
>
>
> -- Jeff
>
>
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> <Untitled attachment 00214.txt>