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

[Robert Raszuk <[e-mail]>]

Jeff,

Linkage MUST exist if for no other reason then for withdrawals.

But such linkage can be a simple pointer or big bag of stats. I was rather
trying to point out the difference between those two rather than dive into
import implementation details.

Thx,
R.


On Wed, Aug 24, 2022 at 11:01 PM Jeffrey Haas <[e-mail]> wrote:

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