Hi Patrice,
A clarification on the "Tag ID" below. I meant the "Ethernet Tag ID" in the
EVPN routes. e.g.:
A MAC/IP Advertisement route type specific EVPN NLRI consists of the
following:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
Thanks.
Jeffrey
Juniper Business Use Only
From: Patrice Brissette (pbrisset) <[email protected]>
Sent: Monday, October 6, 2025 10:29 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected];
[email protected]
Subject: Re: [bess] draft-mackenzie-bess-evpn-l3mh-proto
[External Email. Be cautious of content]
Hi Jeffrey,
Thanks for spending time on this draft.
Please see my replies below.
Regards,
Patrice Brissette
Distinguished Engineer
Cisco Systems
From: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>
Date: Wednesday, October 1, 2025 at 22:42
To: Patrice Brissette (pbrisset)
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: RE: [bess] draft-mackenzie-bess-evpn-l3mh-proto
Hi Patrice,
I have some comments/questions for the draft.
When I first read it, I thought it was about using EVPN MH procedures along
with all the L2 props - EVIs, MAC-VRFs, BDs, BTs, IRBs, etc. - among the MH PEs
(and not involving other PEs at all) for the purpose of MH only. Everything
will just work - what would be the purpose of this draft?
Then I realized that, perhaps, while the EVPN MH-related routes are used,
there are no L2 EVIs, MAC-VRFs, BDs, BTs, IRBs - it's all L3. All the SYNC
routes will lead to appropriate l3 states in the VRFs. Is that understanding
correct?
<Patrice> That's correct.
If so, I think it needs to be explicitly called at the very beginning - even in
the abstraction.
<Patrice> I can certainly add some precision in the abstraction
Other comments:
* I don't think you need/should use/reference the procedures in the
ac-aware bundling. Since it is l3-only and there are no MAC-VRFs/BDs/BTs, there
is no need to involve the service models, but you can still use Tag ID in the
routes to distinguish between different VLANs. That's simpler than using the
Attachment Circuit IDs. In fact, I see section 2.8 mentioning not using the AC
ID - so why not just make the Tag ID the only way and not mention the ac-aware
bundling at all?
<Patrice> I'm not sure what tag-id you are referring to. Do you have a pointer
to some document?
* Initially, I was concerned about using the VRF RT by default for the
sync routes. That means all other PEs will get the sync routes - even those not
on the same MH ES. Then I realized that other PEs may not have negotiated the
EVPN SAFI, so they would not get the routes even though the routes carry the
VRF route target. It would be good to point that out.
<Patrice> Fair point. Route target can also be programmed statically.
* While writing the above bullet, I realized that there could be one set
of MH PEs and another set of MH PEs, all peering with the same RR. In that
case, they would get the sync routes unrelated to them, which is not ideal. I
would have preferred the alternative method in Section 2.1 to be the default.
Is there a reason for the current choice?
<Patrice> It is always the tricky part of a default versus other options. Since
it is a L3 solution, I believe using L3RT is appropriate.
* A nit question - why do you say "Customer Subnet Route" instead of just
"Customer Route"?
<Patrice> Generally speaking, RT-5 is used to exchange subnet routes and that
is the one learned from another protocol. It is different from the subnet of
an L3 interface for instance.
I don't get the following, though:
The synchronization over GRT is different. In that specific
situation, an EVPN instance may be assigned to support non-VPN
layer-3 services. The assignment is only serving the purpose of
providing route targets as requested by [RFC7432]; where RT(s) are
mandatory per EVPN route.
<Patrice> GRT does not have route targets by EVPN requires some....
It mentions that an EVI is used only for the purpose of providing route targets
in the case of GRT. But the sync routes will still have to be imported to or
associated with the GRT, right? If one is concerned that GRT does not use route
targets, I suppose it is more about the fact that route targets are not used to
associate/import routes with/to the GRT. Getting a route target from an EVI
will not solve that problem. If that is not a problem, then one can always just
configure a route target for the GRT, w/o having to create an EVI.
<Patrice> The required RT is for EVPN for the machinery to work... not for GRT
per say.... We can discuss f2f on the one if you have more questions.
Some nits about the following:
This extension to [RFC9135] and to [RFC9136] brings EVPN based MC-LAG
all-active multi-homing load-balancing to various services (L2 and
L3) delivered by EVPN. Although this solution is also applicable to
some L2 service use cases, (example Centralized Gateway) this
document focuses on the L3VPN [RFC4364] use case to provide examples.
"This extension" is not defined. Perhaps you meant "This document extends
[RFC9135] and [RFC9136] procedures". However, I don't think you're extending
those procedures - you're just using the 7432/9135/9136 procedures for this use
case.
<Patrice> Correct.
"... to various services (L2 and L3) delivered by EVPN" is also confusing.
We're only talking about L3 services, right? The L3 services may not be
delivered by EVPN either - it could be L3 VPN by rfc4364, or could be GRT using
IGP.
It's not clear to me about the applicability to some l2 service use cases, but
I notice that the title is "l3mh-proto".
<Patrice> I will address that in the next version. Thanks for pointing that out.
Perhaps the following?
This document adapts [RFC7432], [RFC9135] , and [RFC9136]'s all-active
multi-homing procedures to L3 services.
Thanks.
Jeffrey
Juniper Business Use Only
From: Patrice Brissette (pbrisset)
<[email protected]<mailto:[email protected]>>
Sent: Friday, September 5, 2025 4:55 PM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [bess] draft-mackenzie-bess-evpn-l3mh-proto
Hi,
We believe this draft is ready for WG adoption.
How can we move it forward?
Draft is here:
https://datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mackenzie-bess-evpn-l3mh-proto/__;!!NEt6yMaO-gk!BfvVfZFDk4oxtmGOQYBn1qNobMTBaxW94-xl7-8KDHzpz_UXM9TYwQKVd_PeFXyzqG_EfYPvooFVMQUv$>
Regards,
Patrice Brissette
Distinguished Engineer
Cisco Systems
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
