[GROW] Re: Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

["Dikshit, Saumya" <[e-mail]>]

Hi Nan,

Please do let know, if you are review-done with below proposal.

Thanks,
Saumya.

________________________________
From: Dikshit, Saumya <saumya.dikshit=[e-mail]>
Sent: Thursday, August 13, 2026 1:54:18 am
To: gengnan <[e-mail]>; Zhuangshunwan <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: Srivastava, Mukul <[e-mail]>
Subject: [GROW] Re: Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

Hi Nan,

Here is the complete one added in the .md wherein I inserted the middle paragraph (italicized) mentioning RT-2
<>
Applicability to EVPN Type-5 / IRB Inter-VRF Route Leaking and RT-2 Derived Host Routes

The Remote VRF Information TLV defined in this section applies equally to EVPN Loc-RIB [RFC9069] reporting for EVPN Route Type 5 (IP Prefix Route) [RFC7432] [RFC9135] [RFC9136] routes that have been leaked between EVPN Instances (EVIs) via Integrated Routing and Bridging (IRB), by setting AFI=25 and SAFI=70 in the TLV. No change to the wire format defined in Figure 5 is required.

The TLV also applies to /32 or /128 host routes that are implicitly installed into the IP VRF as a result of MAC/IP binding advertisements received over EVPN Route Type 2 (MAC/IP Advertisement Route) [RFC7432]. These host routes are absorbed from the RT-2 binding and are functionally equivalent to leaked IP prefix routes from the perspective of the VRF Loc-RIB; their origin EVI is not otherwise observable in a standard IP prefix report. Setting AFI=25 and SAFI=70 with the Remote VRF Information TLV provides the missing source-EVI attribution for these implicitly absorbed host routes as well.

This addresses the dynamic inter-VRF route leaking (IVRL) gap noted in [I-D.saum-grow-bmp-afi-safi-evpn], which defines per-EVI counters that quantify how many routes were leaked into a given EVI, but does not itself identify which remote EVI each leaked route came from. The TLV defined in this document supplies that missing detail for both explicitly leaked Type-5 prefixes and implicitly absorbed Type-2 derived host routes. The two mechanisms are intended to be used together rather than as alternatives.

<>

Best Regards,
Saumya.


From: Dikshit, Saumya <[e-mail]>
Date: Tuesday, 11 August 2026 at 9:34 PM
To: gengnan <[e-mail]>; Zhuangshunwan <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: Changwang Lin <[e-mail]>; Srivastava, Mukul <[e-mail]>
Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

Hi Nan,


This should be good enough ?:

   The Remote VRF Information TLV is applicable to EVPN Route Type 5 IP Prefix
   routes and EVPN Route Type 2 MAC/IP Advertisement routes, when those routes
   are leaked between EVIs via IRB and reported with AFI=25 and SAFI=70.

If you are fine with that text, I will plumb in the md.

Thanks,
Saumya.

From: gengnan <[e-mail]>
Date: Tuesday, 11 August 2026 at 9:23 AM
To: Dikshit, Saumya <[e-mail]>; Zhuangshunwan <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: Changwang Lin <[e-mail]>; Srivastava, Mukul <[e-mail]>
Subject: RE: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

Hi Saumya,

How about including RT‑2 in this revision, as it is an update similar to RT-5. Then, we can submit this version and collect feedback from the WG.

Thanks,
Nan

From: Dikshit, Saumya <[e-mail]>
Sent: Tuesday, August 11, 2026 11:42 AM
To: gengnan <[e-mail]>; Zhuangshunwan <[e-mail]>; [e-mail]; [e-mail]
Cc: Changwang Lin <[e-mail]>; Srivastava, Mukul <[e-mail]>
Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

Hi Nan,

Thanks for the new version and accommodating the suggestion. The draft is looking good.

Shall I make the changes for RT-2 inclusion directly to this revision or in next revision.

Best Regards,
Saumya.

From: gengnan <[e-mail]<mailto:[e-mail]>>
Date: Monday, 10 August 2026 at 6:22 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Zhuangshunwan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Changwang Lin <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul Kumar <[e-mail]<mailto:[e-mail]>>
Subject: RE: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking
Hi Saumya,

I have merged your commit to the repo and made some updates to incorporate your comments below. Thanks a lot for your contribution and comments.

Please see my responses inline with [Nan].

Draft-v02: https://github.com/XiaoTianCan/BMP-docs/blob/main/draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-02.md?plain=1

Best,
Nan

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, August 8, 2026 11:58 AM
To: gengnan <[e-mail]<mailto:[e-mail]>>; Zhuangshunwan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Changwang Lin <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking

Hi @gengnan<mailto:[e-mail]>, @Zhuangshunwan<mailto:[e-mail]>, @[e-mail]<mailto:[e-mail]>

I did my bit on the updates via the PR.
It will be great to hear back form you and take this further.

Thanks,
Saumya.

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Monday, 3 August 2026 at 3:12 PM
To: gengnan <[e-mail]<mailto:[e-mail]>>; Zhuangshunwan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Changwang Lin <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking
Hi Nan, Shunwan,

The PR is committed  :  https://github.com/XiaoTianCan/BMP-docs/pull/1


Contents:
-------------

- A new subsection under Remote VRF Information TLV, stating that the
  TLV applies to EVPN Route Type 5 routes leaked between EVIs via IRB by setting AFI=25 and SAFI=70.
  No change to the wire format I. Figure 5 is required.
   That is the point of the contribution: the TLV you already defined generalizes without being touched.

- A worked EVI11/EVI21 example at the end of Operations, as Figure 10,
   following the annotation style you use in Figures 8 and 9.

- The `informative:` block in the markdown was empty. It now carries the three references the new text cites.
  I believe, that one is worth keeping irrespective of conclusion we close on EVPN text, since the reference will be corrected.


Notes and view on earlier call outs:
--------------------------------------

You said some points may need discussion, so calling them out with my comments here:

- Placement and numbering. I put the subsection at the end of Remote VRF Information TLV, before VPN Label TLV,
  because it is a applicability statement about that TLV and not a new one.
  If you would rather it sat in Operations next to the example, or in applicability section of its own, that is entirely yours to decide
  and I will move it.

[Nan] It looks ok as a sub-subsection, and I have retained your modification. Thanks.

- One correction to my own text.
  I cited [RFC7432] and [RFC9135] for Route Type 5. Route Type 5 is defined in RFC 9136, "IP Prefix
  Advertisement in Ethernet VPN (EVPN)". RFC 9135 is the right reference for IRB, and RFC 7432 for the base EVI construct,
 But neither defines the route type.

  The citation should read RFC 913 for the route type and RFC 9135 for the IRB behaviour, with RFC 9136
  added to the informative block.
 I can surely tpush that as a second commit on the same branch, or you can fold it into your editing pass, whichever works

[Nan] Have added rfc9136 as a reference.

- Scope: RT-5 only, or RT-2 as well. The text as filed covers Route Type 5.
  In symmetric IRB, a MAC/IP Advertisement route carrying a IP also installs a host route in the IP-VRF, and
   that host route is equally capable of being leaked between EVIs just like the prefixes.

  So the same “which” remote EVI did this come from" question arises for it.
  I scoped th first cut to RT-5 deliberately, to keep the change small, but I do not think we should leave RT-2 unaddressed (to cover both routing bridging in evpn).
  I would prefer to widen the sentence to cover both and let the example stay with RT-5 (prefix route).
 For the same, I would like your view before I change it.

[Nan] I think you can make modifications directly to cover RT-2.

- Applicability or normative language.
  The text is written as a plain applicability statement with no RFC 2119 keywords, on the basis that nothing new is being required of an implementation.
   If you would prefer a SHOULD on setting AFI=25/SAFI=70 when reporting leaked EVPN routes, say so and I will write it that way.

[Nan] Have added some texts to the draft regarding to the proposed TLVs. Thanks.

- The citation of .I-D.saum-grow-bmp-afi-safi-evpn
  because that is the document that names the IVRL gap,  and the passage is written so that your TLV is the subject and ours is what complements it.
  I believe that you also would want to  carry the reference, and  the gap can be described in place without citing anything, with the text stilli being  valid.

On how the two mechanisms Align/gel/fit"
----------------------------------------------------

The intent is that they are read together.
The per-EVI counters answer how many routes were leaked into an EVI.
Your TLV answers which remote EVI each one came from.
Neither is sufficient alone for a collector trying to reconstruct the leak graph, and
I think we agreed tat document should say that explicitly rather than leave a reader to infer it.

There is a registry consequence worth tracking while we are here:
I-D.dikshit-grow-bmp-rd-scoped-rib-stats reserves Family value 1 for L3VPN in its RD-Scoped Statistics Family registry.
 If the EVPN applicability lands here, an EVPN Family value should be allocated in the same registry so the counters and this TLV can be correlated
without a collector having to special-case the address family.

We cam write that allocation separately so it does not hold up this PR.

More than willing to take any of the above as review comments on the PR instead, if that is easier to track than mail.
Please have a look and provide comments.

Thanks,
Saumya.

Note: Please bear with my indentation