Hi, On Sat, Jun 20, 2020 at 5:12 AM <xiao.m...@zte.com.cn> wrote: > Hi Matthew, Stephane and Authors, > > After reading through this draft, I think it's very useful and > well-written, so I support its publication.
Thanks for your support and comments. > I also have several specific comments as follows. > > In section 2.2, it says > > " > The EVPN PE SHOULD support MEP > functions in the applicable service OAM protocol. This includes both > Up and Down MEP functions. > " > > In my opinion it's reasonable to include Down MEP functions, which > means sending OAM messages between EVPN PE and CE, but UP MEP > functions should be excluded, because that means sending OAM > messages between EVPN PEs, which I think doesn't belong to EVPN > Service OAM. My understanding is that for any kind of EVPN Service > OAM it must include CE, if an OAM mechanism runs between EVPN PEs, > then this OAM mechanism belongs to EVPN Network OAM or EVPN > Transport OAM. Replying just for myself, I believe MEPs are logically in ports. What we are talking about here is the MEP logically located in the CE-facing port of the PE. Certainly down MEP functions from there go to the CE. I think UP MEP functions would go to the UP MEP logically located in the CE facing port of a remote PE. So, this is PE-to-PE and similar to EVPN Network OAM, which runs from the brain of one PE to the brain of another, but not identical. So I do not see any reason why both should not be available. Perhaps these distinctions should be clarified in the text. > In section 2.2, it says > > " > The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP > Advertisement route. Since these are not subject to mobility, they > SHOULD be advertised with the static (sticky) bit set (see Section > 15.2 of [RFC7432]). > " > > In my opinion "MEP/MIP" should be substituted by "MIP", because as I > said above, the MEP at the EVPN PE should be a Down MEP, it's peer > MEP is at locally attached CE, there is no need to advertise it to > remote PEs. See my response above. By the way, I think if there is a MIP at PE1 then an UP MEP at a remote PE can run through the MIP to a CE local to PE1 (actually, to be precise, to the PE facing port of that CE). > In section 3.1.2.2, it says > > "EVPN Service OAM mechanisms only have visibility to the PEs but not > the MPLS/IP P nodes. As such, they can be used to deduce whether the > fault is in the customer's own network, the local CE-PE segment or > remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms > can be used for fault isolation between the PEs and P nodes." > > Considering in section 2.3 the first sentence reads "EVPN Network > OAM is visible to the PE nodes only", I suggest to rephrase this > paragraph possibly as below: > > "EVPN Service OAM and EVPN Network OAM mechanisms only have > visibility to the PEs but not the MPLS/IP P nodes. As such, they can > be used to deduce whether the fault is in the customer's own > network, the local CE-PE segment, the PE-PE segment or the remote > CE-PE segment(s). EVPN Transport OAM mechanisms can be used for > fault isolation between the PEs and P nodes." Your suggested change looks OK to me. > Section 3.1.2.1, there is a typo, s/to rest a representative path > between PEs/to test a representative path between PEs. OK, we'll fix that. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > Best Regards, > > Xiao Min > > 原始邮件 > 发件人:Bocci,Matthew(Nokia-GB) <matthew.bo...@nokia.com> > 收件人:draft-ietf-bess-evpn-oam-req-fr...@ietf.org > <draft-ietf-bess-evpn-oam-req-fr...@ietf.org>;bess@ietf.org <bess@ietf.org>; > 日 期 :2020年06月15日 18:56 > 主 题 :[bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > This email starts a two-week working group last call > fordraft-ietf-bess-evpn-oam-req-frmwk-02 > > > > Please review the draft and send any comments to the BESS list. Also, please > indicate if you support publishing the draft as a standards track RFC. > > > > This poll runs until Monday 29th June 2020. > > > > We are also polling for knowledge of any undisclosed IPR that applies to this > Document, to ensure that IPR has been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as an Author or a Contributor of this document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers from > all the Authors and Contributors. > > There is currently no IPR disclosed. > > Thank you, > > Matthew & Stephane _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess