Hi,
On Sat, Jun 20, 2020 at 5:12 AM 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)
> 收件人：draft-ietf-bess-evpn-oam-req-fr...@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
