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

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 3 Apr 2017 14:40:27 +0000

Hi All,
I have read the draft and support its adoption.

Regards,

Giuseppe

Da: nvo3 [mailto:[email-masked]] Per conto di Bocci, Matthew (Nokia - GB)
Inviato: venerdì 31 marzo 2017 17:35
A: NVO3; [email-masked]<mailto:[email-masked]>
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.

[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: David Mozes <[email-masked]>
Date: Mon, 3 Apr 2017 18:19:52 +0000

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-masked]] On Behalf Of Fioccola Giuseppe
Sent: Monday, April 03, 2017 5:40 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>; [email-masked]
Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

Hi All,

Regards,

Giuseppe

Regards

Matthew and Sam

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 4 Apr 2017 18:48:29 +0000

I do not support adoption of this document.

At its net, this document seems to define an extra header to be used by (all? some?) overlay (def? what’s in scope?) protocols, but said header adds no value other than extra overhead. This seems problematic on a number of levels, adding just an indirection, and a bit flag with a flag define for a timestamp, which creates an OAM in itself conflicting potentially with the proposed OAM carried (and its timestamp). There is no definition for protocols to carry this extra shim, so it is basically floating, and no specifics of what OAMs are carried (and what the benefit is on this indirection instead of carrying natively the OAM). The draft points to BIER MPLS but not to MPLS, which makes me question the scope once again. Perhaps an “Implementation Status” section [RFC 7942] will help.

Thanks,

— Carlos.

On Mar 31, 2017, at 11:34 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Regards

Matthew and Sam
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Apr 2017 16:01:42 -0700

Hi Matthew and Sam,
as this work meant to address active OAM for the newer overlay networks,
would you kindly invite SFC and BIER WGs to review and comment on NVO3 list?

Regards,
Greg

On Fri, Mar 31, 2017 at 8:34 AM, Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details)?
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Apr 2017 16:22:52 -0700

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? 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. Thus I don't agree that
the requirement you refer to is applicable to use of active OAM.

Regards,
Greg

On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <[email-masked]> wrote:

> 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-masked]] *On Behalf Of *Fioccola
> Giuseppe
> *Sent:* Monday, April 03, 2017 5:40 PM
> *To:* Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <
> [email-masked]>; [email-masked]
> *Subject:* [nvo3] R: Poll for NVO3 WG adoption and IPR call for
> draft-ooamdt-rtgwg-ooam-header-03
>
>
>
> Hi All,
>
> *Da:* nvo3 [mailto:[email-masked] <[email-masked]>] *Per
> conto di *Bocci, Matthew (Nokia - GB)
> *Inviato:* venerdì 31 marzo 2017 17:35
> *A:* NVO3; [email-masked]
> *Oggetto:* [nvo3] Poll for NVO3 WG adoption and IPR call for
> draft-ooamdt-rtgwg-ooam-header-03
>
>
>
> 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.*
>
> *Rispetta l'ambiente. Non stampare questa mail
> se non è necessario.*
>
>
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 5 Apr 2017 16:05:36 +0000

Support (as author)

From: Bocci, Matthew (Nokia - GB) [mailto:[email-masked]]
Sent: Friday, March 31, 2017 11:35 AM
To: NVO3; [email-masked]
Subject: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

Regards

Matthew and Sam

---

From: David Mozes <[email-masked]>
Date: Wed, 5 Apr 2017 17:54:12 +0000

Hi Greg  ,
PSB

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 05, 2017 2:23 AM
To: David Mozes <[email-masked]>
Cc: Fioccola Giuseppe <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>; [email-masked]
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
> 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.

David
Greg

On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <[email-masked]<mailto:[email-masked]>> wrote:
Hi ,
I am not supporting the adoption
I think while the working group decided on Geneve as the encap protocol

Thx
David

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Fioccola Giuseppe
Sent: Monday, April 03, 2017 5:40 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; NVO3 <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

Hi All,

Regards,

Giuseppe

Regards

Matthew and Sam

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Apr 2017 12:43:44 -0700

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-masked]> wrote:

> Hi Greg  ,
>
> PSB
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, April 05, 2017 2:23 AM
> *To:* David Mozes <[email-masked]>
> *Cc:* Fioccola Giuseppe <[email-masked]>; Bocci,
> Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>;
> [email-masked]
> *Subject:* Re: Poll for NVO3 WG adoption and IPR call for
> 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?
>
> 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. 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.

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.

> While  I agree with you regarding  Middle box and proactive OAM .The same
> can be achieve with the protocol extensions
>
> 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.

> *This e-mail and any attachments is confidential and may contain

---

From: David Mozes <[email-masked]>
Date: Thu, 6 Apr 2017 07:32:16 +0000

Greg ,
I have a lot to say on what you write below , but let put the discussion in the right content.
The main thing is:
I think yours work and the OAM design team should be focus to define the OAM related data and  the OAM mechanism and there is a lot to do on this area .and try to make it uniform on all the diffenet encapsulations (NVO3,BEIR,SFC) and not dealing with the encapsulation itself. By this you mixed all things up and we will achieve nothing .

Specifically:
1)The extension header (container) concept was discussed on the encap design team . the content was to make VXLN-GPE extendable (While it is not by adding NSH  header to it and was rejected because of the bytes overhead (less bytes than your proposal). Now you like to take encap protocol with build  in extension and add to it extension header ?  what we will do with other extensions like security add extension header as well  ? This doesn’t make sense and not needed in all the cases
2) the total header length on the base header is important and help for parsing in all the cases especially when you don’t like to deal with the extensions .
3) 8 bytes overhead is important
4)and adding ether type to the parsing graph is costly and can complicate things especially if you need to parse options(TLV)  before

Thx
David

Sent: Wednesday, April 05, 2017 10:44 PM

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-masked]<mailto:[email-masked]>> wrote:
Hi Greg  ,
PSB

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, April 05, 2017 2:23 AM
To: David Mozes <[email-masked]<mailto:[email-masked]>>
Cc: Fioccola Giuseppe <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; NVO3 <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

Hi David,
GIM>> I want to point that the draft introduces Associated Channel for an overlay network. Associated Channel may be used for signalling or OAM. 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.
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.

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.

David
Greg

Thx
David

Hi All,

Regards,

Giuseppe

Regards

Matthew and Sam

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Apr 2017 02:55:00 +0000

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-masked]> wrote:
> 
> Hi David,
> 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.

> 	• one-way and two-way Packet Loss measurement;
> 	• one-way and two-way Packet Delay measurement;
> 	• Synthetic Loss Measurement.

The temperature of the ocean does not seem to change...

> 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 Associa…

I still do not see how an overlay layer benefits from this unnecessary overhead.

Support--

Carlos.

> A: NVO3; [email-masked]
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
>  
> 
>  
> 
> 
> [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 7 Apr 2017 13:56:52 -0700

Hi David,
please find my notes in-line tagged GIM2>>.

Regards,
Greg

On Thu, Apr 6, 2017 at 12:32 AM, David Mozes <[email-masked]> wrote:

> I think yours work and the OAM design team should be focus to define the
> OAM related data and  the OAM mechanism and there is a lot to do on this
> area .and try to make it uniform on all the diffenet encapsulations
> (NVO3,BEIR,SFC) and not dealing with the encapsulation itself. By this you
> mixed all things up and we will achieve nothing .
>
GIM2>>  I feel that you assume that the proposed solution is for NVO3 only
and thus had not thought about SFC and BIER. Dave Dolson had pointed out
that the proposed solution is beneficial for SFC.

>
>
>
>
> Specifically:
>
> 1)The extension header (container) concept was discussed on the encap
> design team . the content was to make VXLN-GPE extendable (While it is not
> by adding NSH  header to it and was rejected because of the bytes overhead
> (less bytes than your proposal).
>
Now you like to take encap protocol with build  in extension and add to it
> extension header ?  what we will do with other extensions like security add
> extension header as well  ? This doesn’t make sense and not needed in all
> the cases
>
GIM2>> What are these cases that don't require active OAM?

> 2) the total header length on the base header is important and help for
> parsing in all the cases especially when you don’t like to deal with the
> extensions .
>
GIM2>> To be precise, if I look at TLV-based approach then the difference
is, at most, 4 bytes.

> 4)and adding ether type to the parsing graph is costly and can complicate
> things especially if you need to parse options(TLV)  before
>
GIM2>> What EtherType? Who says that active OAM must be combined with TLVs?
The benefit, in my opinion, of using Overlay Associated Channel, is that it
is self-contained and processing can be offloaded once the packet was
identified as OAC packet.

> *Sent:* Wednesday, April 05, 2017 10:44 PM
>
> > While  I agree with you regarding  Middle box and proactive OAM .The
> same can be achieve with the protocol extensions
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 10 Apr 2017 01:59:50 +0000

> On Apr 7, 2017, at 4:56 PM, Greg Mirsky <[email-masked]> wrote:
> 
> The main thing is:
> 
> GIM2>>  I feel that you assume that the proposed solution is for NVO3 only and thus had not thought about SFC and BIER. Dave Dolson had pointed out that the proposed solution is beneficial for SFC.
> 
> 

Could you please elaborate on what specifically and precisely the benefit for SFC is? I might have missed what’s other than overhead in this indirection.

Thanks,

—
Carlos Pignataro, [email-masked]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: [email-masked]
Date: Wed, 12 Apr 2017 09:30:30 +0800

Hi all,

I support the adoption of this draft. It works in many overlay networks.

BR.
Ting

发件人:         "Bocci, Matthew (Nokia - GB)" <[email-masked]>
收件人:         NVO3 <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, 
日期:   2017/03/31 23:35
主题:   [nvo3] Poll for NVO3 WG adoption and IPR call for 
draft-ooamdt-rtgwg-ooam-header-03
发件人: "nvo3" <[email-masked]>

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?

Regards
 
Matthew and Sam_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: David Mozes <[email-masked]>
Date: Wed, 12 Apr 2017 06:45:10 +0000

F Greg ,
1) I am aware that you are aiming it to other WG  rather than only NVO3
That  way you have to be focused on the common parts  which is  the OAM related  data  and the OAM mechanism.
You can come with requirements for the encapsulation protocols. However you should let them to deal with how to encap the OAM  and not redesign them yourself .
2) I am confusing since you with one hand speaking on the entire OAM  spectrum ,but from the other hand you bring just the active OAM to the discussion with me .
So what is the scope ?
3) I think I made my points already , I will lets other to comments

Thx
David

from: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, April 07, 2017 11:57 PM
To: David Mozes <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: Fioccola Giuseppe <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>; [email-masked]
Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03

Hi David,

Regards,
Greg

On Thu, Apr 6, 2017 at 12:32 AM, David Mozes <[email-masked]<mailto:[email-masked]>> wrote:
Greg ,
I have a lot to say on what you write below , but let put the discussion in the right content.
The main thing is:
I think yours work and the OAM design team should be focus to define the OAM related data and  the OAM mechanism and there is a lot to do on this area .and try to make it uniform on all the diffenet encapsulations (NVO3,BEIR,SFC) and not dealing with the encapsulation itself. By this you mixed all things up and we will achieve nothing .
GIM2>>  I feel that you assume that the proposed solution is for NVO3 only and thus had not thought about SFC and BIER. Dave Dolson had pointed out that the proposed solution is beneficial for SFC.

Specifically:
1)The extension header (container) concept was discussed on the encap design team . the content was to make VXLN-GPE extendable (While it is not by adding NSH  header to it and was rejected because of the bytes overhead (less bytes than your proposal).
Now you like to take encap protocol with build  in extension and add to it extension header ?  what we will do with other extensions like security add extension header as well  ? This doesn’t make sense and not needed in all the cases
GIM2>> What are these cases that don't require active OAM?
2) the total header length on the base header is important and help for parsing in all the cases especially when you don’t like to deal with the extensions .
3) 8 bytes overhead is important
GIM2>> To be precise, if I look at TLV-based approach then the difference is, at most, 4 bytes.
4)and adding ether type to the parsing graph is costly and can complicate things especially if you need to parse options(TLV)  before
GIM2>> What EtherType? Who says that active OAM must be combined with TLVs? The benefit, in my opinion, of using Overlay Associated Channel, is that it is self-contained and processing can be offloaded once the packet was identified as OAC packet.

Thx
David

Hi David,

Regards,
Greg

Hi David,

David
Greg

Thx
David

Hi All,

Regards,

Giuseppe

Regards

Matthew and Sam