Hi Donald,
Thanks for considering my comments.
Best Regards,
Xiao Min
原始邮件
发件人：DonaldEastlake <d3e...@gmail.com>
收件人：肖敏10093570;
抄送人：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月24日 12:46
主 题 ：Re: [bess] WG Last Call and IPRPollfordraft-ietf-bess-evpn-oam-req-frmwk-02
Hi,
On Tue, Jun 23, 2020 at 4:11 AM <xiao.m...@zte.com.cn> wrote:
> Hi Donald,
>
> Thanks for your reply, please see my inline comments with <XM>.
>
> Best Regards,
>
> Xiao Min
>
> 原始邮件
> 发件人：DonaldEastlake <d3e...@gmail.com>
> 收件人：肖敏10093570;
> 抄送人：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月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 <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.
>
>
> <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
d3e...@gmail.com
> > 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
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
