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) < [email protected]> 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 <[email protected]> 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) < > [email protected]> 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 <[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]> 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]> 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]> 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
