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 <[email protected]> Date: Monday, 10 August 2026 at 6:22 PM To: Dikshit, Saumya <[email protected]>; Zhuangshunwan <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: Changwang Lin <[email protected]>; Srivastava, Mukul Kumar <[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, 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 <[email protected]> Sent: Saturday, August 8, 2026 11:58 AM To: gengnan <[email protected]>; Zhuangshunwan <[email protected]>; [email protected]; [email protected] Cc: 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 @gengnan<mailto:[email protected]>, @Zhuangshunwan<mailto:[email protected]>, @[email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Date: Monday, 3 August 2026 at 3:12 PM To: gengnan <[email protected]<mailto:[email protected]>>; Zhuangshunwan <[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 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
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
