Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Jeffrey Haas <[e-mail]>]

> On Aug 24, 2022, at 4:51 PM, Robert Raszuk <[e-mail]> wrote:
> 
> I am quite puzzled as to what more specifics are needed. RD rewrite on local import is the basic premise of L3VPN (and L2VPNs for that matter) architecture. 

While you likely have something very specific in mind by your phrasing, I don't know that the relevant details are necessarily problematic in actual implementations.

Your likely point is that once VRF import is done, the RD doesn't "exist".  I agree with that bit of thinking.

Implementations that I am familiar with don't "lose" the source LxVPN route as part of the import process.  In general, the leaked routes in the VRF maintain a relationship with their parent LxVPN route.

1. In implementations where that relationship still exists, it's possible to aggregate the necessary counters in a VRF context per-RD.
2. In implementations where the state is decoupled, it's likely that the per-VRF per-RD accounting would need to be accommodated at the route leak operation.

For this to be a real problem, the implication would be that there are implementations that could not keep this accounting.  Did you have any such implementations in mind?

For the record, Juniper's implementation is type 1, but could be implemented as type 2 as well. 

However, once you get additional sub-sorting criteria, counters may get expensive.  That is likely to encourage the solution to avoid too many extra granular counting steps.

-- Jeff