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.
> 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.
> 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
