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

[Donald Eastlake <[e-mail]>]

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]


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

> Hi Donald,
>
> Copying Martin for the 802.1Q normative reference question.
>
> Please see inline.
>
> > -----Original Message-----
> > From: Donald Eastlake <[e-mail]>
> > Sent: 08 April 2021 22:08
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: 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,
> >
> > On Thu, Apr 8, 2021 at 9:36 AM Robert Wilton via Datatracker
> > <[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]
> >
> > > Regards,
> > > Rob
>