Hi Sasha, Thanks for your comments. I'll try to respond within a few days.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Tue, Sep 17, 2024 at 8:27 AM Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org> wrote: > > Mohammed, > > Lots of thanks for the review. > > > > I have posted my concerns about the draft in question some time ago, and they > are mainly orthogonal to the issues you raise. > > > > However, there is one important point that you are raising and that overlaps, > to some extent, with some of my comments. > > > > You have written that you have failed finding “EVPN network layer” in 7432 or > 7432bis, and your guess is that the authors may refer to the definition in > Section 2.1 of RFC 9062. > > > > But I think that the real question here should be whether EVPN network layer > exists at all, and, if yes, whether it could be monitored using BFD. > > > > Quoting from Section 9.2.1 of RFC 7432 (the relevant text is highlighted): > > > > A PE may advertise the same single EVPN label for all MAC addresses > > in a given MAC-VRF. This label assignment is referred to as a per > > MAC-VRF label assignment. Alternatively, a PE may advertise a unique > > EVPN label per <MAC-VRF, Ethernet tag> combination. This label > > assignment is referred to as a per <MAC-VRF, Ethernet tag> label > > assignment. As a third option, a PE may advertise a unique EVPN > > label per <ESI, Ethernet tag> combination. This label assignment is > > referred to as a per <ESI, Ethernet tag> label assignment. As a > > fourth option, a PE may advertise a unique EVPN label per MAC > > address. This label assignment is referred to as a per MAC label > > assignment. All of these label assignment methods have their > > trade-offs. The choice of a particular label assignment methodology > > is purely local to the PE that originates the route. > > > > This is definition is re-phrased (without any change in the semantics) in > Section 9.2.1 of 7432bis as following: > > > > The choice of a particular label assignment methodology is purely local to > the PE that originates the route :¶ > > · A PE may advertise the same single EVPN label for all MAC addresses > in a given MAC-VRF. This label assignment is referred to as a per MAC-VRF > label assignment. > > · Alternatively, a PE may advertise a unique EVPN label per <MAC-VRF, > Ethernet tag> combination. This label assignment is referred to as a per > <MAC-VRF, Ethernet tag> label assignment. > > · As a third option, a PE may advertise a unique EVPN label per <ESI, > Ethernet tag> combination. This label assignment is referred to as a per > <ESI, Ethernet tag> label assignment. > > · As a fourth option, a PE may advertise a unique EVPN label per MAC > address. This label assignment is referred to as a per MAC label assignment. > > All of these label assignment methods have their trade‑offs. An assignment > per MAC-VRF label requires the least number of EVPN labels but requires a MAC > lookup in addition to an MPLS lookup on an egress PE for forwarding. On the > other hand, a unique label per <ESI, Ethernet tag> or a unique label per MAC > allows an egress PE to forward a packet that it receives from another PE to > the connected CE, after looking up only the MPLS labels without having to > perform a MAC lookup. This includes the capability to perform appropriate > VLAN ID translation on egress to the CE. > > > > In both cases 4 (four) different options for allocating labels carried in the > Label1 field of the NLRI of EVPN Type 2 routes are listed, and 7432bis > explains that each of these options has its own trade-offs. > > > > At the same time, Section 2.3 EVPN Network Layer OAM” of RFC 9062 says: > > EVPN Network OAM is visible to the PE nodes only. This OAM layer is analogous > to Virtual Circuit Connectivity Verification (VCCV) [RFC5085] in the case of > VPLS/VPWS. It provides mechanisms to check the correct operation of the data > plane as well as a mechanism to verify the data plane against the control > plane. This includes the ability to perform fault detection and diagnostics > on:¶ > > · the MP2P tunnels used for the transport of unicast traffic between > PEs. EVPN allows for three different models of unicast label assignment: > label per EVI, label per <ESI, Ethernet Tag>, and label per MAC address. In > all three models, the label is bound to an EVPN Unicast Forwarding > Equivalence Class (FEC). EVPN Network OAM MUST provide mechanisms to check > the operation of the data plane and verify that operation against the control > plane view. > > > > This text is slightly inconsistent with the text in 7432/7432bis (one of the > four options of the latter is missing in the former). But in any case, the > “EVPN network layer” in the specific PE may be associated not just with a > specific MAC-VRF (or with a specific BD within a MAC-VRF) but with a specific > NAC-VRF, locally attached Ethernet Segment} pair or even with a specific > <MAC-VRF, locally learned MAC address> pair. > > > > And this raises a question about the number of EVPN BFD sessions that could > be required to monitor such EVPN Network layer. > > > > Hope these notes will be useful. > > > > Regards, > > Sasha > > > > From: Mohamed Boucadair via Datatracker <nore...@ietf.org> > Sent: Monday, September 16, 2024 5:56 PM > To: rtg-...@ietf.org > Cc: bess@ietf.org; draft-ietf-bess-evpn-bfd....@ietf.org > Subject: [EXTERNAL] [RTG-DIR]Rtgdir early review of > draft-ietf-bess-evpn-bfd-07 > > > > Reviewer: Mohamed Boucadair > Review result: Has Issues > > Hi authors, > > Thanks for the effort put into this document. > > Overall, the document reads well. The specification leverages existing > specifications with exceptions called out it in the document. This approach > seems reasonable, but there are some issues that need to be fixed. These are > highlighted in the detailed review (see below). A subset of them are > highlighted hereafter: > > # Better position the document: For example, I failed to find this "network > layer" defined in RFC7432 or 7432bis. I think that you are referring to the > layering in 2.1 of 9062. For example, you can consider adding a sentence in > the > introduction about 2.1 of 9062 to position the layer you are considering. > > # 7432 or 7432bis: Any reason why the bis is cited explicitly here? Are there > parts of the spec that are not applicable to 7432? I don't think so, but it is > better clarify this in the doc rather than leaving the readers guess. > > # "future versions of this document" vs "other documents": The document says > in > several places that "It is intended to address this in future versions of this > document.". The intended scope should be clarified. > > # Internal inconsistency: > > ## The document refers to TBD3 and cites Section 8, but there is no such > definition in the IANA section ## The document cites "dedicated unicast MAC" > and "dedicated multicast MAC" but these are not defined in the document. > > ## RFC 9026 > > Previous sections state that 9026 is not mandatory and other mechanisms can be > used. However, Section This text seems to assume that it is always used: > > "It also contains a BFD Discriminator > Attribute [RFC9026] with BFD Mode TDB4 giving the BFD discriminator > that will be used by the tail. > " > > (note that s/TDB4/TBD2) > > # Redundant requirements: For example, the document says > > " The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] and > BFD for VXLAN [RFC8971] are, except as otherwise provided herein, > applied to test loss of continuity for unicast EVPN traffic. > " > but then > > " Once the BFD session is UP, the ends of the BFD session MUST NOT > change the local discriminator values of the BFD Control packets they > generate, unless they first bring down the session as specified in > [RFC5884]. > " > > the intended behavior vs "local discriminator values" here is redundant with > this part in Section 7 of 5884: > > "Note that once the BFD session for the MPLS LSP is UP, either end of the BFD > session MUST NOT change the source IP address and the local discriminator > values of the BFD Control packets it generates, unless it first brings down > the > session." > > No? > > # Detailed review can be found here, fwiw: > > * pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf > * doc: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc > > Feel free to grab whatever you think useful. > > Hope this helps. > > Cheers, > Med > > > > Disclaimer > > This e-mail together with any attachments may contain information of Ribbon > Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments. _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
