Hi Sasha, On Sun, Oct 6, 2024 at 5:47 AM Alexander Vainshtein <alexander.vainsht...@rbbn.com> wrote: > > Hi Donald, > > My apologies for a much-delayed response to your email.
No problem, I have not always been swift in responding... > I am now reading the -08 version of the draft, and I will send a detailed > response based on this document. > > At the same time, I would like to bring to your attention my detailed > comments on the -07 version of the draft which I have asked to consider as > any other LC comments on the draft. Thanks for reminding me of those comments. > I cannot yet say whether the -08 version addresses these comments or not. In general, I think it does not address all of those comments. On one particular item, I believe you suggest considering LSP Ping rather than BFD. When I was added as a co-author on this draft, it was already oriented to BFD and it has remained so. I believe you are the only one who has posted on the BESS list suggesting a change to LSP Ping. It would be nice if a few other people would chime in. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > Regards, > > Sasha > > > > From: Donald Eastlake <d3e...@gmail.com> > Sent: Monday, September 30, 2024 6:54 PM > To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org> > Cc: Mohamed Boucadair <mohamed.boucad...@orange.com>; bess@ietf.org; > draft-ietf-bess-evpn-bfd....@ietf.org; rtg-...@ietf.org > Subject: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of > draft-ietf-bess-evpn-bfd-07 > > > > Hi Sasha, > > 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. > > Yes, the draft does intend to refer to the network layer specified in > Section 2.1 of RFC 9062 and hopefully that is clearer in the latest > revision of the draft. > > > 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. > > Well, it seems to me that PEs exist and the paths between PEs that are > used by EVPN exist and it can be useful to monitor those paths. It is > convenient to have some name to use for the set of such paths. Is > there some name you would prefer to "network layer"? It also seems to > me that it can be monitored with BFD but it could be monitored in > other ways. > > > 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. > > An Errata should be filed against RFC 9062. Do you want to do this or should > I? > > > And this raises a question about the number of EVPN BFD sessions that could > > be required to monitor such EVPN Network layer. > > If there are a vast number of logically distinct paths used by EVPN > between PEs, then monitoring them all may be impractical. > > > Hope these notes will be useful. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com > > > 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
