Re: [bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02

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.bocci@nokia.com>
收件人：draft-ietf-bess-evpn-oam-req-frmwk@ietf.org <draft-ietf-bess-evpn-oam-req-frmwk@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