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

[Aijun Wang <[e-mail]>]

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 15, 2021, at 18:53, Robert Raszuk <[e-mail]> wrote:
> 
> 
> Aijun,
> 
>>> > 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. 
> 
> 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. 
> 
> 
>>> > don’t know why it selected new SAFI NLRI approach.
>>> 
>>> 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?
> 
> 
> I am talking about control plane loop not data plane loop. 
>  
>>> 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.
> 
> 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. 

[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. 
> 
> 
>>> 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.
> 
> 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.
> 
> Thx,
> R.
>