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. Regards -éric -----Original Message----- From: Donald Eastlake <[email protected]> Date: Thursday, 8 April 2021 at 00:05 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, BESS <[email protected]>, Matthew Bocci <[email protected]> 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 <[email protected]> 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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
