Hi Matthew, Stephane and Authors,
After reading through this draft, I think it's very useful and well-written, so
I support its publication.
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.
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.
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."
Section 3.1.2.1, there is a typo, s/to rest a representative path between
PEs/to test a representative path between PEs.
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
