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

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Feb 2021 12:19:47 -0500

Greetings: 

The following in this discussion we do not have consensus on: 

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".  

Cheers, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Feb 2021 12:32:05 -0500

Typo error.   Resending for clarity to the authors. 

Greetings: 

In this discussion we do not have consensus on the following things: 

Cheers, Sue

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 12 Feb 2021 18:01:38 +0000

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)

Greetings:

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Feb 2021 13:08:32 -0500

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, 

Greetings: 

Thanks,

Acee

Cheers, Sue

---

From: Aijun Wang <[email-masked]>
Date: Sat, 13 Feb 2021 10:31:45 +0800

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:
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Sat, 13 Feb 2021 13:09:24 +0100

Hi,

On Fri, Feb 12, 2021 at 01:08:32PM -0500, Susan Hares wrote:
> 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.    
> 

Operator here.

I see no need for such a feature, and I am wary of everything that loads
BGP with more special cases, inevitably leading to bugs and network
instability.

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: Aijun Wang <[email-masked]>
Date: Sat, 13 Feb 2021 21:15:42 +0800

Hi, Gert:
 
Do you or your company have experiences to provide the inter-AS option B/C services to customers? If so, how do you prevent the overwhelming VPN routes sent to you via ASBR(Option B) or RR(Option C) accidentally ? Just using BGP max-prefix features? Or other mechanism?

Wish to hear your solution.
Additional replies inline[WAJ]

Aijun Wang
China Telecom

> On Feb 13, 2021, at 20:10, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

[WAJ] We are also keep in mind this wary when designing new features for BGP. Would you like to point out clearly if RD-ORF mechanism violates this?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Feb 2021 00:37:47 +0100

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:

> 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
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 15 Feb 2021 19:32:29 +0000

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]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hello Aijun,

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.

Kind regards,
Robert

On Sat, Feb 13, 2021 at 3:32 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Susan:

Aijun Wang
China Telecom

---

From: Aijun Wang <[email-masked]>
Date: Tue, 16 Feb 2021 07:42:08 +0800

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:
> 
> 
> On Sat, Feb 13, 2021 at 3:32 AM Aijun Wang <[email-masked]> wrote:
> Hi, Susan:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 16 Feb 2021 01:43:12 +0000

My comment was not about removal of RD-ORF after the source is fixed.

First, one PE sends RD_ORF:
[An Ink Drawing]

Then all PE's send RD-ORF:
[An Ink Drawing]

Now RR can send RD-ORF towards the source:
[An Ink Drawing]

The source sends 1 Million Withdraws
[An Ink Drawing]

Now a new PE comes up. It has not yet sent RD-ORF:
[An Ink Drawing]

RR must remove the RD-orf from the source, because not all PEs have sent it the RD-ORF.
[An Ink Drawing]

The source sends 1 Million VPN routes:
[An Ink Drawing]

PE3 sends an RD-orf:
[An Ink Drawing]

RR can send RD-orf to the source, because all PEs have sent RD-orf
[An Ink Drawing]

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]>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hi, Jakob:

Aijun Wang
China Telecom

On Feb 16, 2021, at 03:32, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

What's the difference?

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Sunday, February 14, 2021 3:38 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Hello Aijun,

Kind regards,
Robert

Aijun Wang
China Telecom