Hi, Greg, Thank you for the quick reply. However, your response is both a red herring and a false cause. Additionally, the conversation does feel like déjà vu...
Whichever way SFC NSH and Geneve choose to identify OAM is not relevant to my comments below. They can choose to use an O bit present in the encapsulation for active OAM, and the PID for different OAMs, or any other way that does not require two lookups. I doubt that there is a lot of intersection between BIER MPLS, GRE, and NSH for OAM. And if you further consider other overlay protocols, the intersection is null. But my point was to pose for the WG’s consideration a couple of questions I had asked in the past and not to engage in a rat-hole: 1. Why would anyone need an OOAM 2. What is the implementation status and plan. As such, I’ll close the thread from my end. Many Thanks, Carlos. On Mar 29, 2018, at 9:48 AM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Carlos, would you kindly point to the definition that explains how active OAM is identified in, for example, SFC NSH and Geneve. Thank you in advance. Regards, Greg On Thu, Mar 29, 2018 at 4:45 PM, Carlos Pignataro (cpignata) <[email protected]<mailto:[email protected]>> wrote: Greg, Thanks for the quick response. I fail to see how OOAM (targeting active OAM) and IOAM (hybrid in-situ OAM) relate to each other. Let’s not try to conflate different problem spaces into a spaghetti. As a separate topic, I also do not see the need for an extra OOAM overhead lookup and indirection — and considering your point of all encaps being different, seems not useful both in theory and practice. Thanks, Carlos. On Mar 29, 2018, at 9:37 AM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<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
