Re: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

[Greg Mirsky <[e-mail]>]

Hi Carlos,
as you've noted, this is WG adoption call, not WG last call.
I'll let others to decide whether the proposed Overlay Associated Channel
which, borrowing from RFC 7212, "provides an auxiliary logical data channel
associated with" an instance of the overlay network "over which a variety
of protocols may flow" enables design and development of Overlay OAM
protocols to be re-useable among Overlay networks.

Regards,
Greg

On Tue, Apr 11, 2017 at 7:16 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Greg,
>
> I am providing some follow-ups below, but I will top-post note that you
> completely missed responding to the key issues raised: what problem is this
> really attempting to solve? what is gained by this extra overhead and
> indirection? what is overlay-specific in this header?
>
> After this email, since I believe I made my points already, I will let
> others comment.
>
> Please see inline…
>
> > On Apr 9, 2017, at 10:07 PM, Greg Mirsky <[e-mail]> wrote:
> >
> > Hi Carlos,
> > if we had the OAM requirements that WGs, i.e. NVO3, SFC, and BIER,
> agreed on
>
> This shows a fundamental misunderstanding of WG operations by you, if I
> follow your logic correctly.
>
> An existing Internet-Draft under a WG control means that at some point the
> WG thought it useful to work on that problem, and the WG charter allowed
> for that scope. It does *not* mean that every word and every sentence is
> agreed by the WG, or that they even make sense. [RFC 2418], [RFC 7221]
> Agreement is via consensus.
>
> With that context in mind...
>
> > , then, I believe, we only had to check if the proposed solution
> addresses one of the requirements. I strongly believe that having OAM
> requirements as working document, not necessarily to be published, is very
> helpful.
> > But I'm surprised that you suggest that defect indication, in peer and
> multi-layer OAM interworking in not required. You're co-author of OAM
> requirements draft in SPRING WG that has the following requirement:
>
> Interestingly, after a dialogue with one of the spring chairs in Chicago,
> I emailed the spring chairs (Cc’ed on this note) and draft contributors
> alias stating that there’s really no value on that document. On that email
> thread, you were the only dissenting voice trying to hold on to that
> document.
>
> Now, is SPRING also an overlay for which you suggest
> draft-ooamdt-rtgwg-ooam-header has a solution? The MPLS, IPv6 encap, or
> both? I’d love to know, since you had previously said “NVO3, SFC, BIER” (a
> rather capricious choice, apparently)
>
> You seem to have missed the main point I was making here though: since
> operators said in IETF95’s rtgwg meeting they want more traceroute-like and
> less traditional-like tools, are you ignoring operational needs?
>
> >    REQ#11:  When SR OAM is initialized from centralized controller, it
> >             MUST have the ability to alert any edge node in SR domain
> >             about the corresponding path or service failure.  The node
> >             on receiving the alert MAY take a local protection action or
> >             pop an informational message.
> >
>
> I’ve rarely seen solutions evaluated against requirements, unless
> hand-picked requirements were reverse-engineered from solutions.
>
> > Isn't that the functionality that is exactly supported by RDI and AIS?
>
> As it is the case here it seems to me.
>
> > Then in BIER WG adopted OAM Requirements, that you are co-author ed, I
> find this:
>
> Similarly, it is funny to see the (lack of) differences and progress
> between 2015’s draft-mirsky-bier-oam-requirements-00 and
> draft-ietf-bier-oam-requirements-03:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bier-
> oam-requirements-03.txt&url1=draft-mirsky-bier-oam-requirements-00.txt
>
> Content differences are effectively null. Do you really insist in calling
> that WG agreement?
>
>
> >    10.  BIER OAM MUST support Reverse Defect Indication (RDI)
> >         notification of the source of continuity checking BFR by Bit-
> >         Forwarding Egress Routers (BFERs), e.g. by using Diag in p2mp
> >         BFD with active tail support.
> >
> > and this
> >    13.  BIER OAM MUST support defect notification mechanism, like Alarm
> >         Indication Signal.  Any BFR in the given BIER domain MAY
> >         originate a defect notification addressed to any subset of BFRs
> >         within the domain.
> >
> > You don't agree with these requirements?
> >
>
> It’s odd, those requirements read to me like “I require this solution”…
> not real requirements…
>
> And these are not the things I hear operators need. No.
>
> Best,
>
> — Carlos.
>
> > Regards,
> > Greg
> >
> > On Thu, Apr 6, 2017 at 7:55 PM, Carlos Pignataro (cpignata) <
> [e-mail]> wrote:
> > David responded to this, though I’d like to add a couple thoughts,
> inline.
> >
> > > On Apr 5, 2017, at 3:43 PM, Greg Mirsky <[e-mail]> wrote:
> > >
> > > Hi David,
> > > thank you for your detailed follow-up comments. Please find my notes
> in-line and tagged GIM>>.
> > >
> > > Regards,
> > > Greg
> > >
> > > On Wed, Apr 5, 2017 at 10:54 AM, David Mozes <[e-mail]>
> wrote:
> > > Hi Greg  ,
> > >
> > > PSB
> > >
> > >
> > >
> > > From: Greg Mirsky [mailto:[e-mail]]
> > > Sent: Wednesday, April 05, 2017 2:23 AM
> > > To: David Mozes <[e-mail]>
> > > Cc: Fioccola Giuseppe <[e-mail]>; Bocci,
> Matthew (Nokia - GB) <[e-mail]>; NVO3 <[e-mail]>;
> [e-mail]
> > > Subject: Re: Poll for NVO3 WG adoption and IPR call for
> draft-ooamdt-rtgwg-ooam-header-03
> > >
> > >
> > >
> > > Hi David,
> > >
> > > thank you for sharing your opinion.
> > >
> > > Could you please clarify your position. You propose to use
> extensions/options for end-to-end active OAM?
> > >
> > > David> yes
> > >
> > >  Let us look at proactive continuity check between NVEs. Why you think
> a middlebox needs to be aware of the OAM payload?
> > >
> > > I believe that a transient NVO3 node should not look into payload if
> it is not addressed to it at all.
> > >
> > > David> Are you limit the header just for proactive OAM ?  so change
> the draft to include just that . On the current  draft I see all kinds of
> OAM
> > >
> > > GIM>> I want to point that the draft introduces Associated Channel for
> an overlay network. Associated Channel may be used for signalling or OAM.
> >
> > Whoa… what problem are we solving? Inline signaling of OAM, on a covert
> channel? As if we do not have enough ways already to address the
> requirements?
> >
> > > OAM methods enable operators to perform Fault Management and
> Performance Monitoring. Among functions required to perform comprehensive
> Fault Management are:
> > >       • failure detection, usually detection of Loss of Continuity but
> may include Mis-connection defect as well for connection-oriented network;
> > >       • defect localization;
> > >       • Alarm Indication Signal;
> > >       • Remote Defect Indication.
> >
> > I thought one strong point made quite a few times by operators is to
> move into less-ATM-like OAMs and more into traceroute-like tools. Less AIS
> / RDIs and more treetrace and udp singers.
> >
> > > Depending on the requirements towards resiliency and restoration,
> Protection Switchover Coordination protocol may be required.
> > > Performance Measurement usually supports the following:
> > >       • one-way and two-way Packet Loss measurement;
> > >       • one-way and two-way Packet Delay measurement;
> > >       • Synthetic Loss Measurement.
> > > Service Activation Protocol, as part of active OAM toolset, usually
> combines OAM functions from FM and PM operations.
> > > The goal of Overlay OAM work, as I understand, is to create common set
> of OAM protocols that supports all of listed above FM and PM operations. I
> see such set as combination of active, hybrid and passive OAM methods. I
> believe that the draft states that clearly. The proactive OAM is usually
> used to perform monitor network for defects and performance degradation.
> On-demand OAM tools may be used to localize the defects.
> > >
> >
> > The temperature of the ocean does not seem to change...
> >
> > >
> > > > While  I agree with you regarding  Middle box and proactive OAM .The
> same can be achieve with the protocol extensions
> > >
> > > Thus I don't agree that the requirement you refer to is applicable to
> use of active OAM.
> > >
> > > David> I think if the WG decide on NVO3 encap protocol that include
> extension (Like GUE and Geneve) we have to use the build in extensions for
> such protocol and not innovate  extra header  that use for protocols
> without extensions.
> > >
> > > GIM>> I question your assumption that use of variable length header
> mandates how OAM, active OAM, must be implemented. And since some networks
> choose to use fixed size header, using Overlay Associated Channel header
> with multiplexed Overlay OAM functionality appears, in my opinion, as
> common solution for either type of overlay encapsulation.
> > >
> > >
> >
> > I still do not see how an overlay layer benefits from this unnecessary
> overhead.
> >
> > Support--
> >
> > Carlos.
> >
> > >
> > > David
> > >
> > > Greg
> > >
> > >
> > >
> > > On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <[e-mail]>
> wrote:
> > >
> > > Hi ,
> > >
> > > I am not supporting the adoption
> > >
> > > I think while the working group decided on Geneve as the encap protocol
> > >
> > >
> > >
> > > This OAM need to be via one of the extensions/options  the protocol
>  is supporting!
> > >
> > >
> > >
> > > This header also violate the number 1 requirements from the
> extensions/options
> > >
> > > That node/middlbox  don not  need to be part of the extensions/ option
> can jump directly  to the overlay by reading the base header length only
> > >
> > >
> > >
> > > Thx
> > >
> > > David
> > >
> > >
> > >
> > > From: nvo3 [mailto:[e-mail]] On Behalf Of Fioccola
> Giuseppe
> > > Sent: Monday, April 03, 2017 5:40 PM
> > > To: Bocci, Matthew (Nokia - GB) <[e-mail]>; NVO3 <
> [e-mail]>; [e-mail]
> > > Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for
> draft-ooamdt-rtgwg-ooam-header-03
> > >
> > >
> > >
> > > Hi All,
> > >
> > > I have read the draft and support its adoption.
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > Giuseppe
> > >
> > >
> > >
> > > Da: nvo3 [mailto:[e-mail]] Per conto di Bocci, Matthew
> (Nokia - GB)
> > > Inviato: venerdì 31 marzo 2017 17:35
> > > A: NVO3; [e-mail]
> > > Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for
> draft-ooamdt-rtgwg-ooam-header-03
> > >
> > >
> > >
> > > This email begins a two week poll for adoption of
> draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group.
> > >
> > >
> > >
> > > Please review the draft and send any comments to the NVO3 list.
> > >
> > > Please also indicate whether you support adoption of the draft as an
> NVO3 working group document.
> > >
> > >
> > >
> > > Simultaneously, we are also poling for any IPR that may apply to the
> draft.
> > >
> > >
> > >
> > > Authors and contributors, are you aware of any IPR that applies to
> this draft?
> > >
> > >
> > >
> > > If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> > >
> > >
> > >
> > > If you are listed as a document author or contributor, please respond
> to
> > >
> > > this email stating of whether or not you are aware of any relevant
> > >
> > > IPR. The response needs to be sent to the NVO3 WG mailing list. The
> > >
> > > document will not advance to the next stage until a response
> > >
> > > has been received from each author and each contributor.
> > >
> > >
> > >
> > > This poll closes on Friday 14th April 2017.
> > >
> > >
> > >
> > > Regards
> > >
> > >
> > >
> > > Matthew and Sam
> > >
> > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
> > >
> > > This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
> > >
> > > <image001.gif>Rispetta l'ambiente. Non stampare questa mail se non è
> necessario.
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > nvo3 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/nvo3
> >
> >
>
>