Subject: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Mon, 15 Jun 2020 10:55:34 +0000

This email starts a two-week working group last call for draft-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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 18 Jun 2020 22:11:19 -0400

I support this draft as an author.

I am not aware of any undisclosed IPR in this draft.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Mon, Jun 15, 2020 at 6:55 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Sat, 20 Jun 2020 17:12:46 +0800 (CST)

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) <[email-masked]>
收件人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年06月15日 18:56
主 题 ：[bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02

_______________________________________________
BESS mailing list
[email-masked]
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

 

 

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. 

Thank you,

Matthew & Stephane

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 22 Jun 2020 17:32:27 -0400

Hi,

On Sat, Jun 20, 2020 at 5:12 AM <[email-masked]> wrote:
> 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.

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

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

> 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

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 22 Jun 2020 15:33:00 -0700

Support this as co-author.
Not aware of any IPR which was not disclosed pertaining to this draft

Sam

---

From: <[email-masked]>
Date: Tue, 23 Jun 2020 16:11:34 +0800 (CST)

Hi Donald,

Thanks for your reply, please see my inline comments with <XM>.

Best Regards,

Xiao Min

原始邮件

发件人：DonaldEastlake <[email-masked]>
收件人：肖敏10093570;
抄送人：Bocci, Matthew (Nokia - GB) <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年06月23日 05:33
主 题 ：Re: [bess] WG Last Call and IPR Pollfordraft-ietf-bess-evpn-oam-req-frmwk-02

Hi,

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

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

OK, we'll fix that.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 24 Jun 2020 00:45:15 -0400

Hi,

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

<de> That seems reasonable. I'll think about how to re-word the
relevant draft sections.

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

<de> OK.

Thanks,
Donald

---

From: <[email-masked]>
Date: Wed, 24 Jun 2020 15:52:29 +0800 (CST)

Hi Donald,

Thanks for considering my comments.

Best Regards,

Xiao Min

原始邮件

发件人：DonaldEastlake <[email-masked]>
收件人：肖敏10093570;
抄送人：Bocci, Matthew (Nokia - GB) <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年06月24日 12:46
主 题 ：Re: [bess] WG Last Call and IPRPollfordraft-ietf-bess-evpn-oam-req-frmwk-02

Hi,

<de> OK.

Thanks,
Donald

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Jun 2020 20:11:28 +0000

Support the WGLC.  I think the draft is ready to  move to IESG. 

Linda Dunbar

---------- Forwarded message ---------
From: Bocci, Matthew (Nokia - GB) <[email-masked]>
Date: Mon, Jun 15, 2020 at 6:55 AM
Subject: WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02
To: [email-masked]
<[email-masked]>, [email-masked] <[email-masked]>

This email starts a two-week working group last call for
draft-ietf-bess-evpn-oam-req-frmwk-02

Thank you,

Matthew & Stephane

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 30 Jun 2020 22:08:01 +0000

Support as a co-author. Not aware of any undisclosed IPRs related to this draft.

Cheers,
Ali

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Monday, June 15, 2020 at 3:55 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Cisco Employee <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Monday, June 15, 2020 at 3:55 AM

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 30 Jun 2020 23:37:35 +0000

I support the draft for standards track.

Regards,
Jakob.

From: BESS <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Monday, June 15, 2020 3:56 AM
To: [email-masked]; [email-masked]
Subject: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02