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. - 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 - 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. - 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. - 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 From: Dikshit, Saumya <[email protected]> Date: Saturday, 1 August 2026 at 3:57 PM To: gengnan <[email protected]>; Zhuangshunwan <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Changwang Lin <[email protected]>; Srivastava, Mukul <[email protected]> Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking Thank you Nan, I will do that by early next week. Looking forward to a fruitful collab. Best Regards, Saumya. ________________________________ From: gengnan <[email protected]> Sent: Friday, July 31, 2026 2:04:06 pm To: Dikshit, Saumya <[email protected]>; Zhuangshunwan <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Changwang Lin <[email protected]>; Srivastava, Mukul <[email protected]> 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, Thank you for your proposal. We can work together to figure out how to integrate your contributed content, and some points may need discussion during this process. Could you please create a PR to the repo (https://github.com/XiaoTianCan/BMP-docs)? Once merged, we can bring the discussion outcomes back to the WG. Thanks. Contributions and comments from other WG members are also welcome. Best, Nan From: Dikshit, Saumya <[email protected]> Sent: Tuesday, July 28, 2026 7:03 PM To: Zhuangshunwan <[email protected]>; [email protected] Cc: [email protected]; Changwang Lin <[email protected]>; Srivastava, Mukul <[email protected]> Subject: Re: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking Hi Shunwan, Nan, Haibo, Thanks for the quick and positive turnaround. I am glad the Remote VRF Information TLV generalization is useful. Below is a concrete proposal for the EVPN/IRB text and worked example we'd like to contribute to -02. 1. Proposed addition: New subsection under Section 2.1 (Remote VRF Information TLV), e.g., "2.1.4. Applicability to EVPN Type-5/IRB Inter-VRF Route Leaking”. The TLV as defined (Information Type/Length, Index, AFI, SAFI, Remote BGP ID, Remote Route Distinguisher) already generalizes cleanly to EVPN (AFI=25, SAFI=70) without any wire-format change, only an applicability statement and example are needed. Proposed text: “" The Remote VRF Information TLV defined in Section 2.1 applies equally to EVPN Loc-RIB [RFC9069] reporting for EVPN Route Type 5 (IP Prefix Route) [RFC7432] [RFC9135] routes that have been leaked between EVPN Instances (EVIs) via Integrated Routing and Bridging (IRB), by setting AFI=25, SAFI=70 in the TLV. 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 (Stats Type=1) that quantify how many routes were leaked into a given EVI, but does not itself identify which remote EVI each leaked route came from. This document's TLV supplies that missing "from which remote EVI" detail; the two mechanisms are intended to be used together, not as alternatives. “" 2. Proposed worked example (parallel to Figures 1-4/8-9, EVPN/IRB case): PE1 hosts EVI11 (RD11, import RT1) with a symmetric-IRB L3VNI. PE2 hosts EVI21 (RD21, export RT1), whose locally attached CE advertises IP Prefix P1 as an EVPN Route Type 5. PE1 imports P1 into EVI11 via IRB. Today, PE1 reporting the Loc-RIB routing information in EVI11 to the BMP server only shows: Prefix: P1 Nexthop: <PE2 address> Peer Distinguisher: RD11 --> The RD of EVI11 on PE1 Peer Address: 0.0.0.0 Peer BGP ID: <PE1 router-id> --> The router-id of EVI11 And, with no way for the collector to tell that P1 was leaked in from EVI21 on PE2 specifically (as opposed to being locally originate in EVI11, or leaked from some other EVI sharing RT1). Using the Remote VRF Information TLV (AFI=25, SAFI=70): Prefix: P1 Nexthop: <PE2 address> Peer Distinguisher: RD11 --> The RD of EVI11 on PE1 Peer Address: 0.0.0.0 Peer BGP ID: <PE1 router-id> --> The router-id of EVI11 Remote BGP ID: <PE2 address> Remote Route Distinguisher: RD21 --> The RD of the remote EVI A collector correlating this with the per-EVI leaked-route gauge ([I-D.saum-grow-bmp-afi-safi-evpn] Section 2.2, Stats Type=1, Subtype=5 for Route Type 5) can now attribute both "how many routes were leaked into EVI11" (the gauge) and "specifically which remote EVI they came from" (this TLV) from a single, correlated BMP feed. 3. Registry note: our companion draft [I-D.dikshit-grow-bmp-rd-scoped-rib-stats] already reserves Family value 1 ("L3VPN (VPN-IPv4/VPN-IPv6 Loc-RIB)") in its RD-Scoped Statistics Family registry as an offer for this document (or a companion) to adopt as a statistics-side complement to the Remote VRF Information TLV, should you want a gauge (e.g. "leaked routes from remote RD X") alongside the TLV rather than only per-route TLV attachment. No action needed on your side unless useful ; flagging it since it's directly relevant to the EVPN/IRB text above. Would you prefer we send the above as a literal text diff against your -01 .txt/.xml source, or is a prose description like the above enough for you to fold in yourselves for -02? Thanks again. Looking forward to working on this together. Best regards, Saumya (on behalf of Mukul Srivastava and Changwang Lin, co-authors of [I-D.saum-grow-bmp-afi-safi-evpn] and [I-D.dikshit-grow-bmp-rd-scoped-rib-stats]) From: Zhuangshunwan <[email protected]<mailto:[email protected]>> Date: Tuesday, 28 July 2026 at 11:59 AM To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Changwang Lin <[email protected]<mailto:[email protected]>>; Srivastava, Mukul <[email protected]<mailto:[email protected]>> 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, Greatly appreciate your positive feedback on the Remote VRF Information TLV approach. Please feel free to integrate your team's ideas and proposals into the -02 version. Let's collaborate to shape a comprehensive new version together. Best regards, Shunwan (on behalf of the co-authors of draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib) From: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Sent: Sunday, July 26, 2026 6:50 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Changwang Lin <[email protected]<mailto:[email protected]>>; Srivastava, Mukul <[email protected]<mailto:[email protected]>> Subject: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking Hi Shunwan, Nan, Haibo, The Remote VRF Information TLV nicely closes the "which remote VPN instance did this best-path come from" gap in RFC 9069 Loc-RIB reporting. I believe there's a directly analogous problem on the EVPN side that this draft's mechanism could cover with minor generalization: * draft-saum-grow-bmp-afi-safi-evpn defines per-EVI EVPN RIB stats keyed by RD (Section 2.2), and separately calls out "dynamic inter-VRF route leaking (IVRL)" for EVPN Type-5/IRB routes as an area needing counters. * Today your draft scopes the Remote VRF Information TLV to VPNv4/VPNv6 Loc-RIB only (Figure 1 example). * Would you be open to extending the applicability statement to the EVPN AFI/SAFI (25/70). * Thus, single Remote VRF Information TLV mechanism covers both L3VPN and EVPN-IRB inter-VRF leak visibility? * If that's in scope for a -02, we'd like to contribute the EVPN-side text and an example (analogous to your Figure 1) showing an EVPN Type-5 (prefix) route leaked across VRFs with the Remote VRF Information TLV attached. (Hi Nan, a separate topic from your rel-enhancement/filtering thread which I was trying keep pace with. Just flagging in case both land in your inbox close together.) Let us know if a joint revision makes sense, happy to send a draft diff. @Srivastava, Mukul<mailto:[email protected]> and @Changwang Lin<mailto:[email protected]> are also co-author to draft-saum-grow-bmp-afi-safi-evpn Thanks , Saumya
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
