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]<mailto:[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]<mailto:[email protected]>> wrote: Hi Greg, Thank you for the quick response! On Mar 29, 2018, at 8:14 AM, Greg Mirsky <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
