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

["Rob Wilton (rwilton)" <[e-mail]>]

Thanks for accommodating.

Rob


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

Hi Rob,

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

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]<mailto:[e-mail]>


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

Copying Martin for the 802.1Q normative reference question.

Please see inline.

> -----Original Message-----
> From: Donald Eastlake <[e-mail]<mailto:[e-mail]>>
> Sent: 08 April 2021 22:08
> To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
> Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; BESS <[e-mail]<mailto:[e-mail]>>; Matthew Bocci
> <[e-mail]<mailto:[e-mail]>>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-bess-evpn-oam-req-
> frmwk-08: (with COMMENT)
>
> Hi Rob,
>
> On Thu, Apr 8, 2021 at 9:36 AM Robert Wilton via Datatracker
> <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> >
> >...
> >
> > ----------------------------------------------------------------------
> > 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.
>
> 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.
[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.


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



>
> > 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.
>
> 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.
[RW]

> 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?
[RW]

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


>
> > 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.
[RW]

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




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


>
> >  - Probably helpful to add an informative reference to 802.3 Link OAM,
> which is
> >  in figure 2.
>
> OK, that can be made into a reference.
>
> > 2.2 EVPN Service OAM
> >
> > - I'm not sure how clear "towards the device" is when the point is
> already
> > within the device.
>
> 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.
[RW]

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



>
> 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.)
[RW]

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


>
> > - 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.
>
> OK on the case change. So, on the ASCII art arrow heads, you think I
> should just delete them?
[RW]

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


>
> > Nits:
> >
> > 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.
[RW]

Thanks,
Rob


>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]<mailto:[e-mail]>
>
> > Regards,
> > Rob