Subject: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 08 Apr 2021 06:36:07 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 8 Apr 2021 17:08:21 -0400

Hi Rob,

On Thu, Apr 8, 2021 at 9:36 AM Robert Wilton via Datatracker
<[email-masked]> wrote:
>...

Although I have tweaked them a bit, the descriptions/definitions were
in the draft when I took up the pen along with the reference to RFC
6136. So I don't know where they came from. Surely the important thing
is their accuracy.

>  document would probably benefit from having a normative reference to 802.1Q

I have no problem with adding more references to 802.1Q but would
moving 802.1Q from Informational to Normative require a new Last Call
since it is not an IETF Standards Track document?

> end point of the physical links, whereas the other OAM endpoints are may cause

I'm not sure exactly what you are saying. The ends of the Link OAM
correspond to the ports. The other types of OAM generally run between
the central control planes of the nodes. Do you want me to add
something to the text about the 'o' symbols? ("and, as indicated by
where the "o"s line up, shows which devices have visibility into what
OAM layer(s).") Or what?

> Figure 2:

While I tried to give some hints in the details of this Figure, in
some of your comments below I think you are trying to read way too
much into fine details of this very high level diagram.

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

Probably should be "CFM (Service OAM)" and the PE "o" marks for it
should be moved to line up with the CE facing edge of the PE since
those ports are what are involved. Network OAM, such as BFD, logically
runs between central control planes of the PEs so having the "o"
centrally under the PE seems best to me.

>  - Probably helpful to add an informative reference to 802.3 Link OAM, which is

OK, that can be made into a reference.

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

How about "towards the core of the device"? A port is one the edge of
a device so I think that saying it is "within the device" has a
slightly wrong connotation.

If you have two devices with 4 ports as follows:
  P1-Dev1-P2----------P3-Dev2-P4
CFM permits you to run tests between P1 and P2 or between P3 and P4
that test the continuity through and switching fabric of the devices
without using a link. Of course, you can also run tests from P1 to P3
or P2 to P3 or P1 to P4 or whatever. (Not all implementations of CFM
actually do all this. Some implement the MEPs/MIPs as virtual MEPs/MPs
in the ports that are actually implemented in the central control
plane of the device.)

> Figure 3 more confusing.  Also "down" should be changed to "Down" in the last

OK on the case change. So, on the ASCII art arrow heads, you think I
should just delete them?

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

Since these numbers are never used in the text, I'm inclined to eliminate them.

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Sat, 10 Apr 2021 10:58:00 +0000

Hi Donald,

Copying Martin for the 802.1Q normative reference question.

Please see inline.

> -----Original Message-----
> From: Donald Eastlake <[email-masked]>
> Sent: 08 April 2021 22:08
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; BESS <[email-masked]>; Matthew Bocci
> <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-
> frmwk-08: (with COMMENT)
> 
> Hi Rob,
> 
[RW] 

I guess I feel that subsequent parts of the document assume a more detailed understanding of what MIPS/MEPS are than is described in the terminology.  This is fine, and I don't think that further text in the terminology is required, but it was unclear to me, that if a reader wanted to better understand what is meant by these terms whether they should be looking at RFC 6136 or 802.1Q, and I was hoping that the document could clarify/choose a definitive source reference.

My impression, given how they are used, is that a reference to 802.1Q for CFM is probably most useful.

> since it is not an IETF Standards Track document?
[RW] 
Yes, I think that would be required.  But I've not raised this as a discuss level concern so will defer to the responsible AD here.

> the central control planes of the nodes.
[RW] 

> Do you want me to add
[RW]

Yes, this is what I was suggesting, but it is at the authors' discretion.

> much into fine details of this very high level diagram.
[RW] 

Perhaps.  I'm happy to leave it to the authors' discretion as to whether to change this but have given further comments below.

> centrally under the PE seems best to me.
[RW] 

The reason that I suggested moving these (for figure 2 only, not figure 1) is because I interpret figure 2 as specifically talking about Ethernet EVPNs, using CFM and Link OAM.

Figure 3 and the associated text also gives a description of the appropriate demarcation point for CE facing MIPS and MEPS and describes is as being much more closely aligned to ports (i.e., towards the PE forwarding mechanism) then a single central control plane location.

Hence, I think that if I was drawing this diagram, with symbols to indicate the demarcation points, then I would probably have drawn it slightly differently, with the o symbols in slightly different places.  Probably along with a short explanation on why it is different to figure 1, tying it to section 2.2.

But as above, I'm happy to leave it to the authors to decide whether what I propose would make the document clearer.

> slightly wrong connotation.
[RW] 

I agree that "towards the core of the devices" is clearer.

> in the ports that are actually implemented in the central control
[RW] 

Yes. Hence why I was suggesting that moving the 'o' symbols on figure 2 may be clearer.

> OK on the case change. So, on the ASCII art arrow heads, you think I
[RW] 

That would be my recommendation, but happy to leave it to the authors' discretion.

> Since these numbers are never used in the text, I'm inclined to eliminate
[RW] 

Thanks,
Rob

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2021 21:11:43 -0400

Hi Rob,

I have posted a -09 revision which should resolve your COMMENTs.

Thanks,
Donald

On Sat, Apr 10, 2021 at 6:58 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> > Cc: The IESG <[email-masked]>;
> [email-masked];
> I guess I feel that subsequent parts of the document assume a more
> detailed understanding of what MIPS/MEPS are than is described in the
> terminology.  This is fine, and I don't think that further text in the
> terminology is required, but it was unclear to me, that if a reader wanted
> to better understand what is meant by these terms whether they should be
> looking at RFC 6136 or 802.1Q, and I was hoping that the document could
> clarify/choose a definitive source reference.
>
> Yes, I think that would be required.  But I've not raised this as a
> discuss level concern so will defer to the responsible AD here.
>
>
>
> >
> > > Minor comments:
> > >
> > >     2.1 OAM Layering
> > >
> > > 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.
> >
> Perhaps.  I'm happy to leave it to the authors' discretion as to whether
> to change this but have given further comments below.
>
>
>
>
> >
> The reason that I suggested moving these (for figure 2 only, not figure 1)
> is because I interpret figure 2 as specifically talking about Ethernet
> EVPNs, using CFM and Link OAM.
>
> Figure 3 and the associated text also gives a description of the
> appropriate demarcation point for CE facing MIPS and MEPS and describes is
> as being much more closely aligned to ports (i.e., towards the PE
> forwarding mechanism) then a single central control plane location.
>
> Hence, I think that if I was drawing this diagram, with symbols to
> indicate the demarcation points, then I would probably have drawn it
> slightly differently, with the o symbols in slightly different places.
> Probably along with a short explanation on why it is different to figure 1,
> tying it to section 2.2.
>
> But as above, I'm happy to leave it to the authors to decide whether what
> I propose would make the document clearer.
>
>
> >
> > > Figure 3 more confusing.  Also "down" should be changed to "Down" in
> the
> > last
> > > CE.
> >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 13 Apr 2021 11:19:07 +0000

Thanks for accommodating.

Rob

From: Donald Eastlake <[email-masked]>
Sent: 13 April 2021 02:12
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Vigoureux <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; BESS <[email-masked]>; Matthew Bocci <[email-masked]>
Subject: Re: Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)

Hi Rob,

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

On Sat, Apr 10, 2021 at 6:58 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Donald,

Please see inline.

> From: Donald Eastlake <[email-masked]<mailto:[email-masked]>>
> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
> Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; BESS <[email-masked]<mailto:[email-masked]>>; Matthew Bocci
> <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
[RW]

[RW]

[RW]

[RW]

[RW]

[RW]

[RW]

[RW]

[RW]

[RW]

Thanks,
Rob

>  [email-masked]<mailto:[email-masked]>
>
> > Regards,
> > Rob