Skip to main content

Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)
draft-ietf-bess-evpn-oam-req-frmwk-10

Note: This ballot was opened for revision 05 and is now closed.

Erik Kline
No Objection
Comment (2021-04-05 for -07) Sent
[ section 2.4 ]

* Up to you if you want to include ICMPv6 [RFC4443] in the list of
  applicable mechanism.

  =)

[ section 3.1.1.2+ ]

* I can't tell what the mandatory to implement behaviour is.  3.1.1.2 says
  that implementations MUST support event-driven defect indication which
  can be categorized into two types.

  Both types say they SHOULD be supported.  If the overall behaviour is
  a MUST, shouldn't one of these be MTI?  Or is that not important and the
  point is that any implementation MUST choose at least one to support?
John Scudder
(was Discuss, No Objection) No Objection
Comment (2021-04-12 for -08) Sent
Here's the text of my previously-a-discuss for reference:

Section 2.3:

   EVPN Network OAM mechanisms MUST provide in-band monitoring
   capabilities. As such, OAM messages MUST be encoded so that they
   exhibit identical entropy characteristics to data traffic in order
   that they share the same fate.

It’s not obvious to me what you mean by “identical entropy characteristics to data traffic”. Surely, different flows may have different entropy characteristics, so, *which* data traffic? Similarly, with which data traffic are you saying the OAM messages must share fate?

Donald proposed:

How about something more like:
EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. OAM messages SHOULD be encoded so that they exhibit similar entropy characteristics to data traffic in order maximize the fate sharing between OAM and data.

That's fine. (s/in order maximize/in order to maximize/)

I'm switching to "no objection" in anticipation of the document being updated.

Previous comment:

Thanks for the clear and readable document. I have one nit and one question. 

1. Section 1, nit:

“EVPN is an Layer 2” s/an/a/
Murray Kucherawy
No Objection
Comment (2021-04-07 for -08) Sent
Might be helpful to expand C-MAC and B-MAC on first use.

"MD" appears in your Terminology section, but nowhere else in the document.
Roman Danyliw
No Objection
Comment (2021-04-07 for -08) Sent
Thank you to Melinda Shore for the SECDIR review.

Section 4.  Since Section 2.2 described a process where the “EVPN PE MUST learn the MAC address of locally attached CE MEPs by snooping on CFM frames ...”, is there is reason not to add the DoS caution from [RFC4762] of “Some means to limit the number of MAC addresses ... that a PE can learn SHOULD be implemented.”
Zaheduzzaman Sarker
No Objection
Comment (2021-04-07 for -08) Sent
Thanks for the document and thanks to David Black for TSVART review.

Nits/comments:
 
 * P-MAC and C-MAC are these defined somewhere else? References would be nice here.

 * Section 1.3,  Section 2.1 and Section 2.2 describes P nodes in different ways and that has created confusion to me. Can this be well defined in the terminology section once and just be used in other place?

 * Section 2.5 : "[802.3]" is this supposed to be a reference? it leads to nowhere.

 * Section 3.1.1.2.1 : first time encountered "network management station (NMS)", if this document is not introducing it then I would suggest to at this to section 1.3 and add some descriptive texts, otherwise define it.

 * Section 3.1.2.1 : would be nice to expand MTU.

 * Section 3.2.1: I  can't really parse - "EVPN Network OAM SHOULD provide mechanisms for measuring packet loss for a given service [RFC7680] [RFC6673]." are these IPPM mechanisms recommended to be used for EVPN networks? or are those merely examples?
Éric Vyncke
No Objection
Comment (2021-04-07 for -08) Sent
Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Minor regret for a doc shepherd write-up, which is dated 9 months ago...

-- Section 1 --
Introducing C-MAC and B-MAC could be useful for the reader.

-- Section 1.3 --
Slighlty puzzled by MA/MEP/MIP as those are only about the M of OAM. Should those be OAMA, OAMEP, OAMIP ? Or at least should there be some explanations ?

-- Section 2.2 --
I must confess my lack of knowledge about CFM frames but I am puzzled by "snooping on CFM frames and advertising them to remote PEs as a MAC/IP"
1) if the CFM frame are not IP, then how can it be advertised in a MAC/IP ? (i.e., the CE may not use IP at all)
2) if the CFM frame are IP, then which version of IP ? and how to recognize them ?
Or did I miss something obvious ?

-- Section 3.1.2.1 --
Does this section cover OAM designed by other WG ? E.g., draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark 

-- Section 3.2.1 --
Mostly the same comment as for 3.1.2.1, this section is only about synthetic traffic injection.
Martin Vigoureux Former IESG member
Yes
Yes (for -05) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2021-04-06 for -07) Sent
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

The following URLs in the document failed to return content:
 * http://www.ietf.org/1id-abstracts
Martin Duke Former IESG member
No Objection
No Objection (2021-03-26 for -06) Sent
Thanks to David Black for the tsvart review, and for the authors addressing his comments.

Sec 2.2 It would help to define "up" and "down" connections.

Sec 3.2.1 & 3.2.2. I am not sure of the extent which IPPM metrics and methods can apply to these layers. But there are some references that can guide loss, delay, and jitter measurements:

Loss: RFC 7680, RFC 6673

Delay: RFC 7679, RFC 2681

Jitter: RFC 3393

I encourage the authors to peruse IPPM's published RFCs on datatracker to see if other documents would be similarly useful.
Robert Wilton Former IESG member
No Objection
No Objection (2021-04-08 for -08) Sent
Hi,

Thanks for this document.

It's a bit unclear to me whether the descriptions/definitions of MIP/MEP/MA/MD are coming from CFM or RFC 6136.  Section 1.1 suggests that they are coming from CFM (but without a normative reference to 802.1Q), but the terminology implies that they are being taken from RFC 6136. 
 Certainly, there seem to be places in this document where more meaning of these terms seems to be expected than what is provided in the terminology section.   Section 2.6 refers to CCMs, but I think that a reader would only understand what these are if they have read CFM.  Hence, I think that this document would probably benefit from having a normative reference to 802.1Q rather than informative. 

Minor comments:

    2.1 OAM Layering

    "and shows which devices have visibility into what OAM layer(s)."

Perhaps indicate by the 'o' symbol. Otherwise the fact that the Link OAM is the end point of the physical links, whereas the other OAM endpoints are may cause confusion.

Figure 2:
 - Would it be helpful to move the 'o' marks to the end of the PE devices, to line up with the Link OAM end points?

 - Is "Service CFM" the right term here?  Does this mean "Service OAM - CFM"?

 - Probably helpful to add an informative reference to 802.3 Link OAM, which is in figure 2.

2.2 EVPN Service OAM

- I'm not sure how clear "towards the device" is when the point is already within the device.

- The up and down arrows for the MEPS ("^" and "V") seem to potentially make Figure 3 more confusing.  Also "down" should be changed to "Down" in the last CE.

Nits:

I'm not sure why the PE nodes are numbered by CE nodes are not.

Regards,
Rob