David responded to this, though I’d like to add a couple thoughts, inline.
> On Apr 5, 2017, at 3:43 PM, Greg Mirsky <[email protected]> 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 <[email protected]> wrote: > Hi Greg , > > PSB > > > > From: Greg Mirsky [mailto:[email protected]] > Sent: Wednesday, April 05, 2017 2:23 AM > To: David Mozes <[email protected]> > Cc: Fioccola Giuseppe <[email protected]>; Bocci, Matthew > (Nokia - GB) <[email protected]>; NVO3 <[email protected]>; > [email protected] > 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 <[email protected]> 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:[email protected]] On Behalf Of Fioccola Giuseppe > Sent: Monday, April 03, 2017 5:40 PM > To: Bocci, Matthew (Nokia - GB) <[email protected]>; NVO3 > <[email protected]>; [email protected] > 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:[email protected]] Per conto di Bocci, Matthew (Nokia - > GB) > Inviato: venerdì 31 marzo 2017 17:35 > A: NVO3; [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
