Hi Donald,
Copying Martin for the 802.1Q normative reference question.
Please see inline.
> -----Original Message-----
> From: Donald Eastlake <d3e...@gmail.com>
> Sent: 08 April 2021 22:08
> To: Rob Wilton (rwilton) <rwil...@cisco.com>
> Cc: The IESG <i...@ietf.org>; draft-ietf-bess-evpn-oam-req-fr...@ietf.org;
> bess-cha...@ietf.org; BESS <bess@ietf.org>; Matthew Bocci
> <matthew.bo...@nokia.com>
> 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
> <nore...@ietf.org> 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 +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> d3e...@gmail.com
>
> > Regards,
> > Rob
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
