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

Reply via email to