Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

From: <[email-masked]>
Date: Tue, 12 Jan 2021 10:08:28 +0000

Hi Greg,

Thank you for sharing this updated version.

I have a comment about the new Authentication TLV. We used to have a similar discussion in the past: whether each TLV document has to include its own protection means or have a generic solution. Please check Slide 7 of https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01. As a follow-up, the WG developed https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-02.

I suggest to avoid duplicated functionality and refer to draft-ietf-sfc-nsh-integrity if integrity at the NSH level is required.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Greg Mirsky
Envoyé : mardi 15 décembre 2020 02:18
À : Service Function Chaining IETF list <[email-masked]>; [email-masked]
Objet : [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

Dear All,
in addition to a number of nits being fixed, updates in this version include:

  *   a change in the format of the TLV used in the SFC Echo Request/Reply. The shorter Type field seems not to affect extensibility but an additional one-octet-long filed can be used in some cases (one being the new Authentication TLV);
  *   a new Authentication TLV that can be used to protect the base SFC Echo Request/Reply as well as any optional TLV.
Authors welcome your comments, questions, and suggestions.

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining WG of the IETF.

        Title           : Active OAM for Service Function Chains in Networks
        Authors         : Greg Mirsky
                          Wei Meng
                          Bhumip Khasnabish
                          Cui Wang
        Filename        : draft-ietf-sfc-multi-layer-oam-07.txt
        Pages           : 22
        Date            : 2020-12-14

Abstract:
   A set of requirements for active Operation, Administration and
   Maintenance (OAM) of Service Function Chains (SFCs) in networks is
   presented.  Based on these requirements, an encapsulation of active
   OAM message in SFC and a mechanism to detect and localize defects
   described.  Also, this document updates RFC 8300 in the definition of
   O (OAM) bit in the Network Service Header (NSH) and defines how the
   active OAM message is identified in SFC NSH.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-07
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 12 Jan 2021 13:27:32 -0800

Hi Med,
many thanks for your comment on the new Authentication TLV and the
reference to draft-ietf-sfc-nsh-integrity. I've compared the scope of both
integrity protection mechanisms and think that there is no functional
duplication or overlap but they are rather complementary. Please correct me
if my understanding of draft-ietf-sfc-nsh-integrity is not accurate. As I
understood it, the proposed in Section 5 of the NSH Integrity Protection
draft Variable-Length Context Headers secure only the NSH layer, not a
payload. The goal of the Authentication TLV is to protect the integrity of
the SFC Echo Request, Echo Reply messages, and optional TLVs. The text over
which HMAC is calculated includes fields only within the SFC Echo
Request/Reply message. We can certainly add a text pointing out that the
Authentication TLV and its use are independent of the use of context
headers defined in draft-ietf-sfc-nsh-integrity.
Also, would you suggest enhancing the text used by the Authentication TLV
by including a field from the NSH Base or NSH Path headers?

Best regards,
Greg

On Tue, Jan 12, 2021 at 2:08 AM <[email-masked]> wrote:

> I have a comment about the new Authentication TLV. We used to have a
> similar discussion in the past: whether each TLV document has to include
> its own protection means or have a generic solution. Please check Slide 7
> of
> https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01.
> As a follow-up, the WG developed
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-02.
>
>
>
> I suggest to avoid duplicated functionality and refer to
> draft-ietf-sfc-nsh-integrity if integrity at the NSH level is required.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc [mailto:[email-masked]] *De la part de* Greg Mirsky
> *Envoyé :* mardi 15 décembre 2020 02:18
> *À :* Service Function Chaining IETF list <[email-masked]>;
> [email-masked]
> *Objet :* [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
>
>
>
> Dear All,
>
>    - a change in the format of the TLV used in the SFC Echo
>    Request/Reply. The shorter Type field seems not to affect extensibility but
>    an additional one-octet-long filed can be used in some cases (one being the
>    new Authentication TLV);
>    - a new Authentication TLV that can be used to protect the base SFC
>    Echo Request/Reply as well as any optional TLV.
>
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 13 Jan 2021 09:10:57 +0000

Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : mardi 12 janvier 2021 22:28
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : Service Function Chaining IETF list <[email-masked]>; [email-masked]
Objet : Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

Hi Med,
many thanks for your comment on the new Authentication TLV and the reference to draft-ietf-sfc-nsh-integrity. I've compared the scope of both integrity protection mechanisms and think that there is no functional duplication or overlap but they are rather complementary. Please correct me if my understanding of draft-ietf-sfc-nsh-integrity is not accurate. As I understood it, the proposed in Section 5 of the NSH Integrity Protection draft Variable-Length Context Headers secure only the NSH layer, not a payload.

[Med] Actually, the payload is also covered. You may refer to these figures in Section 4.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Transport Encapsulation                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
      |                Base Header                            |  |
   +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
   |  |                Service Path Header                    |  S
   |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
   |  |                Context Header(s)                      |  |
   |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
   |  |                Original Packet                        |
   +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +------Scope of integrity protected data

and

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Transport Encapsulation                |
   +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
   |  |                Base Header                            |  |
   |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
   |  |                Service Path Header                    |  S
   |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
   |  |                Context Header(s)                      |  |
   |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
   |  |                Original Packet                        |
   +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +----Scope of integrity protected data

The goal of the Authentication TLV is to protect the integrity of the SFC Echo Request, Echo Reply messages, and optional TLVs. The text over which HMAC is calculated includes fields only within the SFC Echo Request/Reply message. We can certainly add a text pointing out that the Authentication TLV and its use are independent of the use of context headers defined in draft-ietf-sfc-nsh-integrity.
Also, would you suggest enhancing the text used by the Authentication TLV by including a field from the NSH Base or NSH Path headers?

[Med] Protecting part of the NSH information is suboptimal as attacks are still possible by misbehaving nodes by altering some of these fields. I would just remove the Authentication TLV from the OAM draft and point to the integrity draft where these matters are discussed. Thank you.

Best regards,
Greg

On Tue, Jan 12, 2021 at 2:08 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cheers,
Med

De : sfc [mailto:[email-masked]<mailto:[email-masked]>] De la part de Greg Mirsky
Envoyé : mardi 15 décembre 2020 02:18
À : Service Function Chaining IETF list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

Dear All,

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

Abstract:

Thank you.

---

From: <[email-masked]>
Date: Wed, 13 Jan 2021 13:53:33 +0000

Hi Greg,

FWIW, some comments on the first part of the document can be seen at:

·         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-sfc-multi-layer-oam-07-rev%20Med.doc

·         pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-sfc-multi-layer-oam-07-rev%20Med.pdf

Hope this helps.

Cheers,
Med

Dear All,

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

Abstract:

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Jan 2021 09:03:35 -0800

Hi Med,
many thanks for your review and comments. I agree that the new
Authentication TLV is not necessary. You are right in pointing that an
active SFC OAM protocol, e.g., SFP Echo Request/Reply defined
in draft-ietf-sfc-multi-layer-oam, must use a MAC Header, as defined
in draft-ietf-sfc-nsh-integrity. I have some questions about
the draft-ietf-sfc-nsh-integrity:

   - I think that the scope of the MAC#1 Context Header is more suitable
   for the active OAM over an SFP. At the same time, it appears that such use
   is not considered in the draft. For example, in Section 5.1 is noted that:

   It does
   not require to re-compute the MAC by each SFF because of TTL
   processing.

   - Also, I understand that encryption is optional and it not being in use
   indicated by setting the value of the IV LEngth field to 0. But I couldn't
   find the text that explains what must be done with the Initialization
   Vector field. On the one hand, that is a variable-length field and thus
   must not be included in the header when the IV Length =0. On the other
   hand, I expect that three-octet-long padding should be applied, zeroed on
   the transmission, and ignored on the receipt. If that is what is expected,
   perhaps clarifying text in Section 5.1 could be added.
   - And another question is on how an SFC element, SFF, for example, would
   realize that the particular must or must not include MAC context header? In
   some protocols, the use of authentication/encryption indicated in the
   packet, e.g., Authentication flag in the BFD control message. Had the
   authors considered a similar method?

I'll update draft-ietf-sfc-multi-layer-oam as you've suggested.

Regards,
Greg

On Wed, Jan 13, 2021 at 1:10 AM <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:[email-masked]]
> *Envoyé :* mardi 12 janvier 2021 22:28
> *À :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> *Cc :* Service Function Chaining IETF list <[email-masked]>;
> [email-masked]
> *Objet :* Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
>
>
>
> Hi Med,
>
> payload.
> The goal of the Authentication TLV is to protect the integrity of the SFC
> Echo Request, Echo Reply messages, and optional TLVs. The text over which
> HMAC is calculated includes fields only within the SFC Echo Request/Reply
> message. We can certainly add a text pointing out that the Authentication
> TLV and its use are independent of the use of context headers defined
> in draft-ietf-sfc-nsh-integrity.
>
> [Med] Protecting part of the NSH information is suboptimal as attacks are
> still possible by misbehaving nodes by altering some of these fields. I
> would just remove the Authentication TLV from the OAM draft and point to
> the integrity draft where these matters are discussed. Thank you.
>
>
>
> Best regards,
>
> Greg
>
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 19 Jan 2021 14:18:19 +0000

Hi Greg,

Please see inline.

Cheers,
Med

Envoyé : lundi 18 janvier 2021 18:04

Hi Med,
many thanks for your review and comments. I agree that the new Authentication TLV is not necessary.
[Med] Glad to see that we are in agreement.

You are right in pointing that an active SFC OAM protocol, e.g., SFP Echo Request/Reply defined in draft-ietf-sfc-multi-layer-oam, must use a MAC Header, as defined in draft-ietf-sfc-nsh-integrity. I have some questions about the draft-ietf-sfc-nsh-integrity:

  *   I think that the scope of the MAC#1 Context Header is more suitable for the active OAM over an SFP.
[Med] Actually, as the “payload” is modified by SFFs, MAC#2 would be more appropriate here. It also allows to detect misbehaving nodes that may unset the O-bit while they shouldn’t.
At the same time, it appears that such use is not considered in the draft. For example, in Section 5.1 is noted that:
   It does
   not require to re-compute the MAC by each SFF because of TTL
   processing.

  *   Also, I understand that encryption is optional and it not being in use indicated by setting the value of the IV LEngth field to 0. But I couldn't find the text that explains what must be done with the Initialization Vector field.
[Med] That field won’t be present. Will add explicit text to record this.
 On the one hand, that is a variable-length field and thus must not be included in the header when the IV Length =0. On the other hand, I expect that three-octet-long padding should be applied, zeroed on the transmission, and ignored on the receipt. If that is what is expected, perhaps clarifying text in Section 5.1 could be added.
[Med] We don’t mention padding as this is new a NEW requirement. Padding is assumed to be applied when appropriate as per Section 2.2 of RFC8300. We can add a reminder, though.

  *   And another question is on how an SFC element, SFF, for example, would realize that the particular must or must not include MAC context header? In some protocols, the use of authentication/encryption indicated in the packet, e.g., Authentication flag in the BFD control message. Had the authors considered a similar method?
[Med] As discussed in the draft, that is the responsibility of the control plane. Once a MAC# is imposed, downstream nodes will need to comply with the behavior for validating/updating the enclosed information.
I'll update draft-ietf-sfc-multi-layer-oam as you've suggested.

Regards,
Greg

On Wed, Jan 13, 2021 at 1:10 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 12 janvier 2021 22:28
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : Service Function Chaining IETF list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

Hi Med,

and

Best regards,
Greg

Cheers,
Med

Dear All,

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

Abstract:

Thank you.

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 Jan 2021 09:31:56 -0800

Hi Med,
I much appreciate your quick response to my questions. I've updated the
Authentication section in the draft. Please let me know if you agree with
the proposed text:
5.2.  Authentication in Echo Request/Reply

   Authentication can be used to protect the integrity of the
   information in SFC Echo Request and/or Echo Reply.  In the
   [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has
   been defined to protect the integrity of the NSH and the payload.
   The header can also be used for the optional encryption of the
   sensitive metadata.  MAC#1 Context Header is more suitable for the
   integrity protection of active SFC OAM, particularly of the defined
   in this document SFC Echo Request and Echo Reply.  On the other hand,
   using MAC#2 Context Header allows the detection of mishandling of the
   O-bit by a transient SFC element.

And I've accordingly updated draft-ao-sfc-oam-return-path specified and
draft-ao-sfc-oam-path-consistency also to refer to the
draft-ietf-sfc-nsh-integrity.
A couple of new notes logged in-line tagged GIM>>.

Regards,
Greg

On Tue, Jan 19, 2021 at 6:18 AM <[email-masked]> wrote:

> *Envoyé :* lundi 18 janvier 2021 18:04
> Authentication TLV is not necessary.
>
> You are right in pointing that an active SFC OAM protocol, e.g., SFP Echo
> Request/Reply defined in draft-ietf-sfc-multi-layer-oam, must use a MAC
> Header, as defined in draft-ietf-sfc-nsh-integrity. I have some questions
> about the draft-ietf-sfc-nsh-integrity:
>
>    for the active OAM over an SFP.
>
> [Med] Actually, as the “payload” is modified by SFFs, MAC#2 would be more
> appropriate here. It also allows to detect misbehaving nodes that may unset
> the O-bit while they shouldn’t.
>
GIM>> Thank you for pointing that out. I agree that is beneficial and the
choice can be left up to an operator.

>    - Also, I understand that encryption is optional and it not being in
>    use indicated by setting the value of the IV LEngth field to 0. But I
>    couldn't find the text that explains what must be done with the
>    Initialization Vector field.
>
>  On the one hand, that is a variable-length field and thus must not be
> included in the header when the IV Length =0. On the other hand, I expect
> that three-octet-long padding should be applied, zeroed on the
> transmission, and ignored on the receipt. If that is what is expected,
> [Med] We don’t mention padding as this is new a NEW requirement. Padding
> is assumed to be applied when appropriate as per Section 2.2 of RFC8300. We
> can add a reminder, though.
>
GIM>> Thank you. I agree that some clarifying text would be helpful.

>
>    - And another question is on how an SFC element, SFF, for example,
>    would realize that the particular must or must not include MAC context
>    header? In some protocols, the use of authentication/encryption
>    indicated in the packet, e.g., Authentication flag in the BFD control
>    message. Had the authors considered a similar method?
>
> [Med] As discussed in the draft, that is the responsibility of the control
> plane. Once a MAC# is imposed, downstream nodes will need to comply with
> the behavior for validating/updating the enclosed information.
>
GIM>> Please, correct me if I misunderstood the use of the MAC Context
Header. Once its presence in the NSH is signaled through the control plane,
it MUST be present in each NSH and it cannot be used intermittently.
Without comparing, from the experience with BFD authentication, we learned
that requiring authentication of each control message is burdensome and not
critical. A lighter approach where some messages are authenticated has been
developed by the BFD WG by introducing NULL Authentication. Do you think a
similar option could be useful in SFC NSH?

---

From: <[email-masked]>
Date: Wed, 20 Jan 2021 06:19:31 +0000

Hi Greg,

Looks good to me. Thanks.

Cheers,
Med

Envoyé : mardi 19 janvier 2021 18:32

Hi Med,
I much appreciate your quick response to my questions. I've updated the Authentication section in the draft. Please let me know if you agree with the proposed text:
5.2.  Authentication in Echo Request/Reply

And I've accordingly updated draft-ao-sfc-oam-return-path specified and draft-ao-sfc-oam-path-consistency also to refer to the draft-ietf-sfc-nsh-integrity.
A couple of new notes logged in-line tagged GIM>>.

Regards,
Greg

On Tue, Jan 19, 2021 at 6:18 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Please see inline.

Cheers,
Med

Hi Med,

GIM>> Thank you for pointing that out. I agree that is beneficial and the choice can be left up to an operator.

  *   And another question is on how an SFC element, SFF, for example, would realize that the particular must or must not include MAC context header? In some protocols, the use of authentication/encryption indicated in the packet, e.g., Authentication flag in the BFD control message. Had the authors considered a similar method?
[Med] As discussed in the draft, that is the responsibility of the control plane. Once a MAC# is imposed, downstream nodes will need to comply with the behavior for validating/updating the enclosed information.
GIM>> Please, correct me if I misunderstood the use of the MAC Context Header. Once its presence in the NSH is signaled through the control plane, it MUST be present in each NSH and it cannot be used intermittently. Without comparing, from the experience with BFD authentication, we learned that requiring authentication of each control message is burdensome and not critical. A lighter approach where some messages are authenticated has been developed by the BFD WG by introducing NULL Authentication. Do you think a similar option could be useful in SFC NSH?

Regards,
Greg

Please see inline.

Cheers,
Med

Hi Med,

and

Best regards,
Greg

Cheers,
Med

Dear All,

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

Abstract:

Thank you.

Thank you.

Thank you.