Hi, On Tue, Jun 23, 2020 at 4:11 AM <[email protected]> wrote: > Hi Donald, > > Thanks for your reply, please see my inline comments with <XM>. > > Best Regards, > > Xiao Min > > 原始邮件 > 发件人：DonaldEastlake <[email protected]> > 收件人：肖敏10093570; > 抄送人：Bocci, Matthew (Nokia - GB) > <[email protected]>;[email protected] > <[email protected]>;[email protected] <[email protected]>; > 日 期 ：2020年06月23日 05:33 > 主 题 ：Re: [bess] WG Last Call and IPR > Pollfordraft-ietf-bess-evpn-oam-req-frmwk-02 > Hi, > > On Sat, Jun 20, 2020 at 5:12 AM <[email protected]> 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. > > > <XM> I agree to your detailed analysis, nevetheless I lean to classifying UP > MEP functions at a pair of PEs into EVPN Network OAM, actually I think it's a > good candidate for the operator to choose to achieve EVPN PE-to-PE Network > OAM. My argument is that any EVPN Service OAM should have CE involved, which > will check the CE address mapping table but EVPN Network OAM won't. With > that, I suggest to clarify that when an UP MEP at PE interacts with an UP MEP > at remote PE, it's EVPN Network OAM, and when an UP MEP at PE interacts with > a Down MEP at remote CE, it's EVPN Service OAM.
<de> That seems reasonable. I'll think about how to re-word the relevant draft sections. > > 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). > > > <XM> I agree to your example that a Down MEP at local CE can interact with an > UP MEP at the remote PE, although I suspect that the operator would like to > deploy it. With that, no any changes needed here. <de> OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > > 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 > [email protected] > > > Best Regards, > > > > Xiao Min > > > > 原始邮件 > > 发件人：Bocci,Matthew(Nokia-GB) <[email protected]> > > 收件人：[email protected] > > <[email protected]>;[email protected] <[email protected]>; > > 日 期 ：2020年06月15日 18:56 > > 主 题 ：[bess] WG Last Call and IPR Poll > > fordraft-ietf-bess-evpn-oam-req-frmwk-02 > > _______________________________________________ > > BESS mailing list > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
