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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Thu, Apr 8, 2021 at 8:53 PM Donald Eastlake <[email protected]> wrote: > Hi Eric, > > On Thu, Apr 8, 2021 at 2:36 AM Eric Vyncke (evyncke) <[email protected]> > 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 +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > > > 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
