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

From: Aijun Wang <[email-masked]>
Date: Mon, 15 Feb 2021 10:09:35 +0800

Hi, Robert:

Thanks for your suggestions!
But it seems adding RT information can’t still solve the situation described in https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1(Figure 3). The overwhelmed PE need still the local determined behavior(which we will add more clear description for this part later) to trigger the RD-ORF.
And, defining one new SAFI to enhance the RTC mechanism, won’t it confuse the deployment of both? Actually, I think the RTC solution(RFC4684) should be implemented also on ORF mechanism, don’t know why it selected new SAFI NLRI approach.
Regarding to your worry for the regeneration of RD-ORF on RR/ASBR, I think we can consider it in another viewpoint: Treating RR/ASBR as the leader/proxy of its clients/neighbors, it should know the responsibilities/risks when it trigger the RD-ORF message to upstream neighbors (we need also describe more later on the determined behaviors of these devices later).

And, using ORF mechanism can achieve the granular control effects( it is hop-by-hop action), contrary to the new SAFI solution, which will be advertised immediately to network wide?
Anyway, we will try to incorporate your finer control suggestions in later design, for example, adding RT information to solve the situation that you mentioned before?
Looking forward to more suggestions/consideration on the solution.

Aijun Wang
China Telecom

> On Feb 15, 2021, at 07:38, Robert Raszuk <[email-masked]> wrote:
> 
> 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:
>> 
>> 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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Feb 2021 09:58:50 +0100

> But it seems adding RT information can’t still solve the situation
described in
https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1(Figure
3).

I am not sure what is yr definition of "solve" - but sending RD3_RT3 tuple
will be no worse then sending RD3 alone. And in many situations as I
illustrated before (hub and spoke case) will actually prevent
unreachability across VRFs.

> don’t know why it selected new SAFI NLRI approach.

Because ORF is NOT transitive. ORF has no concept of loop prevention. It
*only* works p2p. Propagation of received ORF entries is something we
should explicitly forbid in ORF spec. Maybe time for a -bis.
And the objective of RTC is to build a controlled distribution graph of
information across ASNs. That is why this draft
https://tools.ietf.org/html/draft-chen-bgp-ext-community-orf-02 did not
progress.

Thx,
R

On Mon, Feb 15, 2021 at 3:09 AM Aijun Wang <[email-masked]>
wrote:

> But it seems adding RT information can’t still solve the situation
> described in
> https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1(Figure
> 3). The overwhelmed PE need still the local determined behavior(which we
> will add more clear description for this part later) to trigger the RD-ORF.
> And, defining one new SAFI to enhance the RTC mechanism, won’t it confuse
> the deployment of both? Actually, I think the RTC solution(RFC4684) should
> be implemented also on ORF mechanism, don’t know why it selected new SAFI
> NLRI approach.
> Regarding to your worry for the regeneration of RD-ORF on RR/ASBR, I think
> we can consider it in another viewpoint: Treating RR/ASBR as the
> leader/proxy of its clients/neighbors, it should know the
> responsibilities/risks when it trigger the RD-ORF message to upstream
> neighbors (we need also describe more later on the determined behaviors of
> these devices later).
>
> And, using ORF mechanism can achieve the granular control effects( it is
> hop-by-hop action), contrary to the new SAFI solution, which will be
> advertised immediately to network wide?
> Anyway, we will try to incorporate your finer control suggestions in later
> design, for example, adding RT information to solve the situation that you
> mentioned before?
> 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.
>
>> 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: Aijun Wang <[email-masked]>
Date: Mon, 15 Feb 2021 18:27:30 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 15, 2021, at 16:59, Robert Raszuk <[email-masked]> wrote:
> 
> 
> 
> > But it seems adding RT information can’t still solve the situation described in https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1(Figure 3). 
> 
> I am not sure what is yr definition of "solve" - but sending RD3_RT3 tuple will be no worse then sending RD3 alone. And in many situations as I illustrated before (hub and spoke case) will actually prevent unreachability across VRFs. 

[WAJ] Yes, adding RT information within the current RD-ORF encoding can certainly increase the accuracy of the offending VPN routes. 
But in situations described in Figure 3, RD3/RT3 is same for VRF1/2/3. If only one of VRF reach the VPN prefixes limit, it should not influence otherVRF. In such situation, the RD-ORF message should still not be triggered by the PE device, even we use the RD/RT tuple.
> Because ORF is NOT transitive. ORF has no concept of loop prevention.

[WAJ] ORF is route policy to BGP neighbors. It should not be transitive. It does not announce the reachable information, nor the nexthop change, why to consider loop prevention?

> It *only* works p2p. Propagation of received ORF entries is something we should explicitly forbid in ORF spec.
[WAJ] Yes. The p2p mode is fine for ORF message. No need to propagation. Every node should determine based on its own condition.

> Maybe time for a -bis. 
> And the objective of RTC is to build a controlled distribution graph of information across ASNs. That is why this draft https://tools.ietf.org/html/draft-chen-bgp-ext-community-orf-02 did not progress. 

[WAJ] RTC is used to announce “what I want”, it has no mechanism to express “What I don’t want”, which the ORF mechanism jump in.

Then, considering your suggestions, I think adding RT information to current RD-ORF encoding is the appropriate approach, instead of changing the concept/procedures of RTC.

> 
> Thx,
> R
> 
>> On Mon, Feb 15, 2021 at 3:09 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Feb 2021 11:53:09 +0100

Aijun,

> [WAJ] Yes, adding RT information within the current RD-ORF encoding can
> certainly increase the accuracy of the offending VPN routes.
>

Agreed.

> But in situations described in Figure 3, RD3/RT3 is same for VRF1/2/3. If
> only one of VRF reach the VPN prefixes limit, it should not influence
> otherVRF. In such situation, the RD-ORF message should still not be
> triggered by the PE device, even we use the RD/RT tuple.
>

Well this is first time I hear you saying that - but sure triggering
sending RD-RT filter would be a local decision anyway.

> [WAJ] ORF is route policy to BGP neighbors. It should not be transitive.
> It does not announce the reachable information, nor the nexthop change, why
> to consider loop prevention?
>

I am talking about control plane loop not data plane loop.

> [WAJ] Yes. The p2p mode is fine for ORF message. No need to propagation.
> Every node should determine based on its own condition.
>

See you are again trying to propagate ORF.

This spec should make it as a MUST that such filter should be triggered
only upon import "overflow". That way RRs will not be by the spec able to
send such filters if you insist to put in ORF msg. See RRs do not know what
routes PEs are importing in terms of RD. So it would be bad to assume so
here as well. And for RT they know only if RTC is in use across 100%
of PE-RR sessions.

Maybe time for a -bis.
> [WAJ] RTC is used to announce “what I want”, it has no mechanism to
> express “What I don’t want”, which the ORF mechanism jump in.
>
> Then, considering your suggestions, I think adding RT information to
> current RD-ORF encoding is the appropriate approach, instead of changing
> the concept/procedures of RTC.
>

No one is suggesting touching RTC SAFI 132. We are talking about new SAFI
which can just provide finer filtering in addition to RTC. It can be used
alone or with RTC - no issue either way.

But again this is all applicable only when there is a serious problem. So
far I have not seen much support in terms of operators outside of China
asking for this filtering regardless if this is in ORF or in new SAFI.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Mon, 15 Feb 2021 20:01:40 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 15, 2021, at 18:53, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> Well this is first time I hear you saying that - but sure triggering sending RD-RT filter would be a local decision anyway. 
> 
> 
> This spec should make it as a MUST that such filter should be triggered only upon import "overflow". That way RRs will not be by the spec able to send such filters if you insist to put in ORF msg. See RRs do not know what routes PEs are importing in terms of RD. So it would be bad to assume so here as well. And for RT they know only if RTC is in use across 100% of PE-RR sessions. 

[WAJ] RR can deduce RT information from the RD-ORF message of its clients. There maybe other ways to get, we will try to find later if the RT information is associated. 
> No one is suggesting touching RTC SAFI 132. We are talking about new SAFI which can just provide finer filtering in addition to RTC. It can be used alone or with RTC - no issue either way. 
> 
> But again this is all applicable only when there is a serious problem. So far I have not seen much support in terms of operators outside of China asking for this filtering regardless if this is in ORF or in new SAFI. 

[WAJ] As I mentioned before, we are aiming at the inter-AS VPN services deployment which only be emerged when one operator has wide-spreads inter-AS network topology.

---

From: Aijun Wang <[email-masked]>
Date: Mon, 15 Feb 2021 20:04:08 +0800

And Gyan from Verizon has also explained in previous mail the necessary for such mechanism.

Aijun Wang
China Telecom

> On Feb 15, 2021, at 20:02, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Robert:
> 
> Aijun Wang
> China Telecom
>