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

[Donald Eastlake <[e-mail]>]

Hi Eric,

I have posted revision -09 which should resolve your COMMENTs except
possible that I decided not to include a statement that EVPN OAM MAY use
IOAM or the like. As I say, there are lots of things it MAY use...

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


On Thu, Apr 8, 2021 at 8:53 PM Donald Eastlake <[e-mail]> wrote:

> Hi Eric,
>
> On Thu, Apr 8, 2021 at 2:36 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
> > Donald,
> >
> > Thank you for your reply as well as for answering all the questions. I
> like your suggestion about MA/MEP/MIP.
> >
> > About the last point (synthetic traffic or iOAM), while I understand the
> point that OAM should work in the absence of actual traffic (pretty obvious
> indeed), I am still ambivalent whether this document should only be about
> synthetic traffic without being open to other OAM techniques.
>
> Well, I don't think there is anything in the document prohibiting or
> recommending against using, for example, IOAM. I suppose a statement
> could be added saying that it MAY be used, but then there are a lot of
> things that may be used...
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
> > Regards
> >
> > -éric
> >
> > -----Original Message-----
> > From: Donald Eastlake <[e-mail]>
> > Date: Thursday, 8 April 2021 at 00:05
> > To: Eric Vyncke <[e-mail]>
> > Cc: The IESG <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, BESS <[e-mail]>, Matthew Bocci <
> [e-mail]>
> > Subject: Re: Éric Vyncke's No Objection on
> draft-ietf-bess-evpn-oam-req-frmwk-08: (with COMMENT)
> >
> >     Hi Éric,
> >
> >     On Wed, Apr 7, 2021 at 4:14 AM Éric Vyncke via Datatracker
> >     <[e-mail]> wrote:
> >     >
> >     > Éric Vyncke has entered the following ballot position for
> >     > draft-ietf-bess-evpn-oam-req-frmwk-08: No Objection
> >     >
> >     > ...
> >     >
> >     >
> ----------------------------------------------------------------------
> >     > COMMENT:
> >     >
> ----------------------------------------------------------------------
> >     >
> >     > 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.
> >
> >     C-MAC is Customer/Client MAC address and B-MAC is Backbone MAC
> address
> >     as further specified in RFC 7623. These can be spelled out and a
> >     reference to RFC 7623 (which is already listed in the References for
> >     this draft) added.
> >
> >     > -- 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 ?
> >
> >     MA/MEP/MIP are all terms used in CFM (Connectivity Fault Management)
> >     which is specified in 802.1Q. There could be some wording adjustment
> >     to clarify this. For example, saying that they are "part of" Service
> >     OAM rather than implying they might be all of it.
> >
> >     > -- 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 ?
> >
> >     CFM frames are not IP. However, the EVPN MAC/IP Advertisement route
> is
> >     quite flexible and includes a length for the IP address. As stated in
> >     RFC 7432 "By default, the IP Address Length field is set to 0, and
> the
> >     IP Address field is omitted from the route." If you do know an IP
> >     address and want to advertise it, then the length is 32 or 128, as
> >     appropriate, and the IP address is included.
> >
> >     > -- 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.
> >
> >     EVPN Network OAM could include OAM designed by other WGs including
> >     ioam. However, in my opinion the mandatory capabilities should be
> >     available even in the absence of real traffic.
> >
> >     Thanks,
> >     Donald
> >     ===============================
> >      Donald E. Eastlake 3rd   [phone] (cell)
> >      2386 Panoramic Circle, Apopka, FL 32703 USA
> >      [e-mail]
> >
>