Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

From: "Wei Wang" <[email-masked]>
Date: Tue, 9 Feb 2021 11:47:03 +0800

Hi, Susan and All:

&nbsp; &nbsp; As co-author of this draft, I support the adoption.
&nbsp; &nbsp; My consider about this draft is as follows:

1)&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;Will this new ORF filter reduce routing information at key points?

[Wei] Yes, this mechanism can filter the overwhelming VPN routes based on RD, to protect the existing services.

2)&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;Should the WG consider this draft given it has an IPR claim or

&nbsp; &nbsp; [Wei] Yes.

&nbsp; Would the IDR WG prefer another approach?

&nbsp;[Wei] We welcome IDR experts give more comments to improve the solution&nbsp;

3)&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;Is this draft ready to be adopted and refined as WG draft?

[Wei] Yes.

Best Regards,

Wei Wang

China Telecom

From: [email-masked] <[email-masked]&gt; On Behalf Of Susan Hares
Sent: Thursday, February 4, 2021 11:38 PM
To: [email-masked]
Subject: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

&nbsp;

This begins a 2 week WG adoption call for draft-wang-idr-rd-orf-05.txt (from 2/4/2021 to 2/18/2021) 

&nbsp;

This draft defines a new Outbound Route Filter (ORF) type, called the

Route Distinguisher ORF (RD-ORF).&nbsp; RD-ORF is applicable when the

routers do not exchange VPN routing information directly (e.g.

routers in single-domain connect via Route Reflector, or routers in

Option B/Option AB/Option C cross-domain scenario).

&nbsp;

Please be aware that this draft has one IPR statement attached. 
https://datatracker.ietf.org/ipr/4579/..
&nbsp;

Please consider the following questions in your review and comments: 

&nbsp;

1)&nbsp;&nbsp;&nbsp; &nbsp; Will this new ORF filter reduce routing information at key points? 

&nbsp;

2)&nbsp;&nbsp;&nbsp; &nbsp; Should the WG consider this draft given it has an IPR claim or 

Would the IDR WG prefer another approach? 

&nbsp;

3)&nbsp;&nbsp;&nbsp; &nbsp; Is this draft ready to be adopted and refined as WG draft? 

&nbsp;

&nbsp;

Cheerily, Susan Hares 

&nbsp;

&nbsp;

---

From: wangzitao <[email-masked]>
Date: Wed, 10 Feb 2021 07:29:48 +0000

Suppor.

B.R.
Michael

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2021年2月4日 23:38
收件人: [email-masked]
主题: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the

1) Will this new ORF filter reduce routing information at key points?
2) Should the WG consider this draft given it has an IPR claim or
    Would the IDR WG prefer another approach?
3) Is this draft ready to be adopted and refined as WG draft?

Cheerily, Susan Hares

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 13 Feb 2021 14:41:20 +0800

Hi, folks,
I have reviewed the document the approach proposed in it is useful for inter-AS VPN deployment and service provisioning, so I support its adoption.
Best regards
Chongfeng

Hi, Susan:

Thanks for your suggestions. More responses from the operators are welcome!
We think this mechanism can let the network cope with dynamically the extraordinary scenarios for VPN routes advertisement, especially the inter-AS Option B/C scenarios. 
This can certainly encourage the widespread deployment of inter-AS option B/C solution(especially for EVPN/VXLAN, EVPN/SRv6) increase the VPN services coverage and revenue of the operators.

There may be some details procedures and device behaviors need to be clarified further, but this is not unsolvable, considering there are so many experts within IDR WG.

Thanks Robert, Jakob, Jim and Acee for the technical challenges to let us/IDRer understand the solution more clearly.

Aijun Wang
China Telecom

> On Feb 13, 2021, at 02:09, Susan Hares <[email-masked]> wrote:
> 
> 
> Acee:
>  
> Yes.  I noticed that fact about operator feedback as well.    As co-chair/shepherd, I welcome all operator input (DC, IXP, carrier, … ) regarding this draft  - both positive and negative.    
>  
> Cheers,  Sue
>  
> From: Acee Lindem (acee) [mailto:[email-masked]] 
> Sent: Friday, February 12, 2021 1:02 PM
> To: Susan Hares; [email-masked]
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> HI Sue,
>  
> From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
> Date: Friday, February 12, 2021 at 12:32 PM
> To: IDR List <[email-masked]>
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Typo error.   Resending for clarity to the authors.
>  
> Greetings:
>  
> In this discussion we do not have consensus on the following things:
>  
> a) the problem this draft is drafting to solve relating to BGP routes,
> b) the need for additional mechanisms to solve the problem,
> c) a clear description of the technology to solve the problem.
>  
> It is difficult to do (b) and (c) without a consensus on the problem.  Since this is the 2nd time this draft has gone up for adoption, the co-chairs are considering the input from the list and will provide some suggestions to the authors.   
>  
> The authors and those who are making comments on this draft are welcome to continue discussing the topic on-list.   
>  
> A big thanks to the operators who have shared their view of the need for the technology and to all IDR members who have recalled that “clear speech and kindness can go together”. 
>  
> I don’t see a lot of support from operators other than the co-authors.
>  
> Thanks,
> Acee
>  
>  
> Cheers, Sue
>  
>   
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

[email-masked]

---

From: Aijun Wang <[email-masked]>
Date: Tue, 16 Feb 2021 09:16:57 +0800

Hi, Robert:

Don’t you think Jim’s last comments is contradicted?
After replying this mail to you, I will focus on the discussion on Jeff’s thread. 

Aijun Wang
China Telecom

> On Feb 16, 2021, at 05:31, Robert Raszuk <[email-masked]> wrote:
> 
> Jim, 
> 
> And quite frankly I think you nailed it. 
> 
> If one is to provide a service he better purchase the right gear for it. 
> 
> Not some weak PEs which balance on the cliff of falling under light wind ... 

[WAJ] There are lots of devices within the network, in different locations, from different vendors, bought/upgrade in different time. It is natural that they have different capabilities of wind resistance.

> 
> - - - 
> 
> Mitigations which are deployed in many networks have been suggested. Protect from issue not allow it to happen then try to patch it. 
> 
> Alternative deployment models have been proposed too. 
> 
> Sorry I do not buy the reason stated that mistaken redistribution of the Internet to the VPN will crash the network. Right gear carries Internet in a VRF just fine. And if it crashes ... so be it. Next time folks touching PEs will be more careful. 

[WAJ] The network should have the capability to prevent such thing happen. Is there any operator want to wait for it, do nothing and just give/educate the folks lessons in final?

> 
> I also do not accept as a reason Inter-AS option B or C. If you do not trust your AS peer do A+B or A. 

[WAJ] Trust is one side, protecting oneself is another side. 

> 
> For me this topic is considered closed. 
> 
> Thx,
> Robert.
> 
> 
> On Mon, Feb 15, 2021 at 10:15 PM UTTARO, JAMES <[email-masked]> wrote:
>> Here is another fact..
>> 
>>  
>> 
>> It is more like 10+ Million without an issue.
>> 
>>  
>> 
>> Thanks,
>> 
>>               Jim Uttaro
>>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 16 Feb 2021 10:28:47 +0800

Hi, Jakob:
In this situation, the RR will not removal the RD-ORF filter automatically. The consequences is that the new added PE3 will not receive the 1 million VPN routes until the operator find the real reason, for example, build the filter policy at the source, then removal the RD-ORF message manual.
After the above process, all PEs will receive the normal VPN routes.
Such mechanism just want to get more time for operator to responses before the churn disruption occurs.

Aijun Wang
China Telecom

> On Feb 16, 2021, at 09:43, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> My comment was not about removal of RD-ORF after the source is fixed.
>  
> First, one PE sends RD_ORF:
>  
> Then all PE's send RD-ORF:
>  
> Now RR can send RD-ORF towards the source:
>  
> The source sends 1 Million Withdraws
>  
> Now a new PE comes up. It has not yet sent RD-ORF:
>  
> RR must remove the RD-orf from the source, because not all PEs have sent it the RD-ORF.
>  
> The source sends 1 Million VPN routes:
>  
> PE3 sends an RD-orf:
>  
> RR can send RD-orf to the source, because all PEs have sent RD-orf
>  
> This represents churn between RR and the route source.
> With Inter-AS, there will be multiple layers of this.
>  
> Regards,
> Jakob.
>  
> From: Aijun Wang <[email-masked]> 
> Sent: Monday, February 15, 2021 3:42 PM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Robert Raszuk <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
> Hi, Jakob:
> I think you have get the key difference between RD-ORF and RTC, but as described in https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.2, the removal of RD-ORF need the intervention of the operators.  It will not roll back automatically.
>  
> As said before, you can consider RD-ORF as the mechanism of “Spray System” to extinguish the fire. After their action, the house holder find the reason of fire and return normal by manual.
>  
> Using RT-Constraint, all of the “Spray Systems” will reaction but there maybe only the temperature of one house is high.
>  
> Aijun Wang
> China Telecom
> 
> 
> On Feb 16, 2021, at 03:32, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> 
> There's an important difference between rd-orf and RT constraint.
> RT-constraint is a POSITIVE filter.
> Rd-orf is a NEGATIVE filter.
> RT-constraint says :give me X.
> Rd-orf says: withhold X.
>  
> What's the difference?
> Suppose you are an RR and getting the same rd-orf from all your clients.
> Then you can propagate the rd-orf back to the source of the routes.
> Consider what happens when a new client comes up,
> The new client has not (yet) sent the rd-orf.
> Therefore you have to retract the rd-orf from the route source to which you propagated it.
> The next router on the way to the source may be an ASBR.
> It also has to retract the rd-orf it propagated.
> And so on.
> Then the new client sends the rd-orf.
> Now you have to propagate it again.
> and so on.
> That's a lot of churn.
> This churn does not happen with RT-constraint.
>  
> Regards,
> Jakob.
>  
> From: Idr <[email-masked]> On Behalf Of Robert Raszuk
> Sent: Sunday, February 14, 2021 3:38 PM
> To: Aijun Wang <[email-masked]>
> Cc: idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
> Hello Aijun,
> I have been re-thinking over a weekend this entire discussion. 
>  
> I think I have a suggestion for you which addresses my concerns and I believe also addresses yours (and your co-authors) requirements. 
>  
> As I said number of times I still suggest we do not send RD to filter. Instead we send tuple RD+RTs and only filter VPN routes on logical AND of all (all as there can be more then one RT importing given route therefore we need to include intersection of local import RTs and RTs carried with "offending" routes). 
>  
> And to make this easily transitive I recommend we just define a new SAFI for it. We can call it RTC+ or Enhanced RTC as examples. Syntax would be identical to RTC, semantics opposite. Today RTC defines RTs which PEs need. Here we would signal description of subset of those which are "excessive" to be dropped on the peer. 
>  
> Sending it with ORF say RDRT-ORD (while works p2p)  I do not buy this implicit regeneration hack say at RRs, RRs doing option C or ASBRs performing option B. So sending it in new SAFI IMHO would be much cleaner. 
>  
> Just a thought how we could perhaps move forward here. 
>  
> Kind regards,
> Robert
>  
>  
> On Sat, Feb 13, 2021 at 3:32 AM Aijun Wang <[email-masked]> wrote:
> Hi, Susan:
>