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

[Donald Eastlake <[e-mail]>]

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]
>