Hi Carlos, as pointed in draft-wang-sfc-multi-layer-oam direct use of Net Protocol field in encapsulation requires the code point for each OAM function, e.g. BFD, Echo Request/Reply, PM, and etc.
Regards, Greg On Thu, Mar 29, 2018 at 3:21 PM, Carlos Pignataro (cpignata) < [email protected]> wrote: > Hi Greg, > > Thank you for the quick response! > > On Mar 29, 2018, at 8:14 AM, Greg Mirsky <[email protected]> wrote: > > Hi Carlos, > I believe that introduction of the OAM Header with demultiplexing OAM > functions through use of Msg Type will enable use of non-IP encapsulation, > including for BFD and Echo Request/Reply (more on options to demultiplex > active OAM functions could be found in draft-wang-sfc-multi-layer-oam > <https://datatracker.ietf.org/doc/draft-wang-sfc-multi-layer-oam/>). > > > non-IP BFD works well already without this additional overhead. Each > tunneling/encap has appropriate demos capabilities already. > > Still, a header for demultiplexing (a protocol ID) for encapsulations that > already have a protocol ID seems unnecessary. Further, it carries > timestamps and flags for “capabilities”. So it is an OAM in its own to > carry OAM. > > The complete proposition sounds triply duplicative. > > And I see ability to use non-IP encapsulation as more significant > improvement even with relative cost of introducing OAM Header. > Thank you for your reference to RFC 7942. I will discuss your suggestion > with co-authors and we'll consider adding such section. > > > Thank you. Look forward to seeing the Implementation Status. > > Carlos. > > Regards, > Greg > > On Thu, Mar 29, 2018 at 2:56 PM, Carlos Pignataro (cpignata) < > [email protected]> wrote: > >> Hi, Greg, >> >> I was not in London, but if you do not mind, I will piggy back on this >> email to ask a couple of key questions that I still cannot figure out: >> >> 1. What is the objective of an OOAM, or what is purpose for adding an >> indirection, a shim, a nested header and additional lookup, to a bunch of >> encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header says >> “to ensure that OOAM control packets are in-band with user traffic and >> de-multiplex OOAM protocols.” But frankly I cannot make sense of that >> sentence. The same holds equally true without OOAM and this will not >> change >> the behavior of active OAM methods. Imagine the performance of BFD buried >> under redundant fields to parse. >> 2. Could you add an Implementation Status section [RFC 7942] to this >> document? >> >> >> Thanks, >> >> Carlos. >> >> On Mar 29, 2018, at 1:32 AM, Greg Mirsky <[email protected]> wrote: >> >> Hi Ignas, >> another well-captured discussion, thank you. Few notes: >> >> - I believe that in discussion of OOAM Header "?/Cisco" should be >> Frank Brockners >> - would you consider splitting comments and responses with <CR><LF> >> to ease readability? >> >> Kind regards, >> Greg >> >> On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <[email protected]> >> wrote: >> >>> Working group, >>> >>> Draft minutes for IETF101 NVO3 WG meeting have been posted at the >>> meeting materials page. >>> >>> https://datatracker.ietf.org/doc/minutes-101-nvo3/ >>> >>> Please take a look and provide any corrections if needed. >>> >>> Thank you. >>> >>> Ignas >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
