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

gengnan <gengnan@huawei.com> Tue, 11 August 2026 03:53 UTC

Return-Path: <gengnan@huawei.com>
X-Original-To: grow@mail2.ietf.org
Delivered-To: grow@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 23D401278ABC0; Mon, 10 Aug 2026 20:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786420409; bh=jg8N/iEOojr47i+r0fcCCtIINkB1Wgox+tA5GzvgXIs=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=Bog81p0M3FL6768CDtr97LCPUQ0EMV7504MKjoyypPgvBRBvatP3NZx4+YkR8kKRi OkUvPCAknV9cmd2Fbod62J7IqfvYZVH96g5mVqkY111zfW4QD5XNgz84l8a/8gmkMD dYdrDnv0bTsySbP0ZMo7se2CxZH0YuwhIyuZeFO8=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.393
X-Spam-Level:
X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=huawei.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdfmGiPXCHCE; Mon, 10 Aug 2026 20:53:26 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 578671278ABB2; Mon, 10 Aug 2026 20:53:26 -0700 (PDT)
dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=jg8N/iEOojr47i+r0fcCCtIINkB1Wgox+tA5GzvgXIs=; b=XVe5YBU0VhxJsoxtqgzW7fA5wf2hk+HuAYbt1o0Jp+XcAKqmfpdCu3PExDYusj3nYfKq+Ie49 mTQx0yEyvUQwJxfFKQyBjm1eAv5ZTTg8GuBy/oCN7dxyJ0juRAPYL4unnhAgGD32X4SDoIMknkT BmKCTbMC6G24KqkS930dGqw=
Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4hJyQS1TlHzHnGcV; Tue, 11 Aug 2026 11:53:20 +0800 (CST)
Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id 1415F40569; Tue, 11 Aug 2026 11:53:23 +0800 (CST)
Received: from kwepemh200006.china.huawei.com (7.202.181.113) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 11 Aug 2026 11:53:17 +0800
Received: from whupemo500006.china.huawei.com (7.152.184.110) by kwepemh200006.china.huawei.com (7.202.181.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 11 Aug 2026 11:53:16 +0800
Received: from whupemo500006.china.huawei.com ([7.152.184.110]) by whupemo500006.china.huawei.com ([7.152.184.110]) with mapi id 15.02.1544.011; Tue, 11 Aug 2026 11:53:16 +0800
From: gengnan <gengnan@huawei.com>
To: "Dikshit, Saumya" <saumya.dikshit@hpe.com>, Zhuangshunwan <zhuangshunwan@huawei.com>, "grow@ietf.org" <grow@ietf.org>, "draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org" <draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org>
Thread-Topic: [GROW] Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking
Thread-Index: AQHdHOsSkAuAmGa8fUeLhmiy2Sv1eraCUT3wgABzWeaABIxZkIABtWRfgAMUjkeAB38Qs4ADs5NggAD+fnmAAAIl0A==
Date: Tue, 11 Aug 2026 03:53:16 +0000
Message-ID: <adf8f813f96e450d9554d001c77f3ec4@huawei.com>
References: <SJ0PR84MB211003FD13ADE79116CF95A794CD2@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <17ac2aa7c36a4382bb16f5e3794ae0ba@huawei.com> <SJ0PR84MB2110D08B444B99E4BB9DBD5B94CB2@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <a0152674820b4b7f86f80193a7064b89@huawei.com> <SJ0PR84MB21105D7334EE7E2555C6BEA494D72@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB2110246FA538A8EACAA9A72994D52@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB21109ACD893B8D60F9CF3C6394D02@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <974f67a083a04010b0cb0b51f6a2f6b7@huawei.com> <SJ0PR84MB2110B32E4380EEC07C13FE8794DD2@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: <SJ0PR84MB2110B32E4380EEC07C13FE8794DD2@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.245]
Content-Type: multipart/alternative; boundary="_000_adf8f813f96e450d9554d001c77f3ec4huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: 6HEX4XHUXGFAGE7F5LB2GX7DT4EAO7TN
X-Message-ID-Hash: 6HEX4XHUXGFAGE7F5LB2GX7DT4EAO7TN
X-MailFrom: gengnan@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-grow.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Srivastava, Mukul" <mukul.srivastava@hpe.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [GROW] Re: Comments on draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01 : applicability to EVPN/IRB and inter-VRF leaking
List-Id: Grow Working Group Mailing List <grow.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/sMPbpAf--2kFNQ9yOkrnjN1C5es>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Owner: <mailto:grow-owner@ietf.org>
List-Post: <mailto:grow@ietf.org>
List-Subscribe: <mailto:grow-join@ietf.org>
List-Unsubscribe: <mailto:grow-leave@ietf.org>

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 <saumya.dikshit@hpe.com>
Sent: Tuesday, August 11, 2026 11:42 AM
To: gengnan <gengnan@huawei.com>; Zhuangshunwan <zhuangshunwan@huawei.com>; grow@ietf.org; draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org
Cc: Changwang Lin <linchangwang.04414@h3c.com>; Srivastava, Mukul <mukul.srivastava@hpe.com>
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 <gengnan@huawei.com<mailto:gengnan@huawei.com>>
Date: Monday, 10 August 2026 at 6:22 PM
To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>; Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>; draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org> <draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org>>
Cc: Changwang Lin <linchangwang.04414@h3c.com<mailto:linchangwang.04414@h3c.com>>; Srivastava, Mukul Kumar <mukul.srivastava@hpe.com<mailto:mukul.srivastava@hpe.com>>
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 <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>
Sent: Saturday, August 8, 2026 11:58 AM
To: gengnan <gengnan@huawei.com<mailto:gengnan@huawei.com>>; Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; grow@ietf.org<mailto:grow@ietf.org>; draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org>
Cc: Changwang Lin <linchangwang.04414@h3c.com<mailto:linchangwang.04414@h3c.com>>; Srivastava, Mukul <mukul.srivastava@hpe.com<mailto:mukul.srivastava@hpe.com>>
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:gengnan@huawei.com>, @Zhuangshunwan<mailto:zhuangshunwan@huawei.com>, @draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org>

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 <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>
Date: Monday, 3 August 2026 at 3:12 PM
To: gengnan <gengnan@huawei.com<mailto:gengnan@huawei.com>>; Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>>; grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>>
Cc: draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org> <draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org<mailto:draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib@ietf.org>>; Changwang Lin <linchangwang.04414@h3c.com<mailto:linchangwang.04414@h3c.com>>; Srivastava, Mukul <mukul.srivastava@hpe.com<mailto:mukul.srivastava@hpe.com>>
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