Hi, Greg, Not surprised. But for the record, and my last email on this thread:
You kept dodging the questions and chose to NOT answer either of them. This was intended as a quick and painless Echo/Reply email exchange, single round-trip, and the evasiveness and avoiding-the-issue non-answers turned it into a TCP interaction! RST! Enjoy your weekend, Carlos. On Mar 30, 2018, at 5:52 PM, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Hi Carlos, you may be surprised to check BIER OAM, section 3.1 of draft-ietf-bier-ping<https://tools.ietf.org/html/draft-ietf-bier-ping-03> to be precise, as it defines the header for active BIER OAM. Regards, Greg PS. You're co-authored BIER ping draft. On Sat, Mar 31, 2018 at 12:19 AM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Hi, Greg — I agree with all of that, none of which talks about, points to, or explains why OOAM! :-) I asked a specific focused question. No answer about what problem OOAM solves... You will have a hard time finding disagreement with rah-rah and generic statements. Yes, let’s dramatically improve the visibility, operations, and automation of networks and architectures. No reason, however, to add extra overhead headers to BIER, Geneve, SFC, what else? Reminds me of… https://xkcd.com/927/ — Carlos. On Mar 30, 2018, at 5:07 PM, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Hi Carlos, you've asked 1. Why would anyone need an Overlay OAM, [i.e. Why need for OAM in NVO3, SFC and etc.] I'd refer to comment Alia made at the NVO3 WG meeting during the discussion of this proposal: Alia: I would like to reiterate - I am very happy to see the discussion happening, this is something that WG was working for 3-4 years. We need this. VXLAN has been deployed for a very long time, and Geneve is coming. Let’s get this done. So, my answer Because it's about time we do better job by developing networks accompanied with the toolset to run, diagnose and troubleshoot them. And that, IMHO, requires comprehensive OAM tools, including active and hybrid. Regards, Greg On Thu, Mar 29, 2018 at 6:19 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: 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 <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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) <cpign...@cisco.com<mailto:cpign...@cisco.com>> 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 <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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) <cpign...@cisco.com<mailto:cpign...@cisco.com>> 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 <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: Hi Greg, Thank you for the quick response! On Mar 29, 2018, at 8:14 AM, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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) <cpign...@cisco.com<mailto:cpign...@cisco.com>> 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 <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 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 <ibagdona.i...@gmail.com<mailto:ibagdona.i...@gmail.com>> 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 nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
