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

[Robert Raszuk <[e-mail]>]

> 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 <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]>
> 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
>>
>