Hi Carlos, indeed, parts of the draft are specific to SFC but discussion on options for supporting active OAM, I believe, is applicable to overlays (encaps/tnneling) in general. Applicability or suitability of the OAM Header to particular encapsulation, in my view, depedns not whether the encapsulation uses OAM bit but how it defines identification of active OAM packet. After the London meeting we have iOAM proposals for several encapsulations, including SFC NSH and Geneve, that propose use iOAM as value of Next Protocol field of the encapsulation and transparent to O-bit value.
Regards, Greg On Thu, Mar 29, 2018 at 3:39 PM, Carlos Pignataro (cpignata) < [email protected]> wrote: > Greg, > > Scanning through it, that draft concerns itself with SFC only. > > But regardless, it emphasizes the point of when this OOAM idea breaks: > each encapsulation has different allocation strategy. Some encaps have > already an OAM bit, which when set, can open the whole range of PIDs for > OAM types. > > Other encaps much rather *have* different code points for BFD and for > others. Because there is space, and much rather NOT do a double lookup to > figure out what OAM it actually is. > > I still do not see the problem attempted to be solved. > > Thanks, > > Carlos. > > > On Mar 29, 2018, at 8:30 AM, Greg Mirsky <[email protected]> wrote: > > 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
