Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

From: James Guichard <[email-masked]>
Date: Thu, 2 Sep 2021 18:02:22 +0000

Dear WG:

The chairs have extended the WGLC for a further 2 weeks due to the lack of feedback from the WG on the original WGLC.

Please read the document and provide comments to the SFC WG mailing list no later than September 17th 2021. Note that this document is a normative reference for https://datatracker.ietf.org/doc/html/draft-ietf-sfc-proof-of-transit that is currently in AD review and we would therefore like to conclude this WGLC so that its dependent documents can further progress.

Thanks!

Jim & Joel

From: James Guichard <[email-masked]>
Sent: Wednesday, August 18, 2021 8:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

This email starts a 2 week Working Group Last Call for draft-ietf-sfc-ioam-nsh [1].

Please read this document if you haven't read the most recent version and send your comments to the SFC WG list no later than September 1st 2021.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributor please response to indicate whether you know of any undisclosed IPR related to this document.

Thanks!

Jim & Joel

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5d6bc76f69df4c2a8cdb08d962443814%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637648867414771153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YC18mVsN4Kfw%2BAP2OfZBWkj8jLGembb1HEXsR1vAzLo%3D&reserved=0>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 3 Sep 2021 13:47:31 +0000

Hi,

I support as a coauthor and editor I support the drafts. Given  that the draft has been presented and reviewed several times, I do think it is ready.

Regards, Frank

From: sfc <[email-masked]> On Behalf Of James Guichard
Sent: Donnerstag, 2. September 2021 20:02
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

Thanks!

Jim & Joel

From: James Guichard <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 18, 2021 8:32 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

Thanks!

Jim & Joel

---

From: <[email-masked]>
Date: Fri, 3 Sep 2021 15:05:14 +0000

Hi Jim, all,

I support advancing the document.

Below some few items that might be considered by the authors:

* I'm not sure to understand the following:

   If "proof-of-transit" is used in
   conjunction with NSH, the implementation of proof of transit MUST
   follow [I-D.ietf-sfc-proof-of-transit].

Rather than such statement, I think it would be better to explain why proof of transit is useful for ioam.

* IOAM-Data-Fields is not shown in the figure (Section 3).

* Please define what is meant by "NSH tunnel endpoints" as RFC7565 does not define such nodes.

* Section 4.1 says:

   An encapsulation of IOAM-Data-Fields in NSH should be friendly to an

   implementation in both hardware as well as software forwarders and

   support a wide range of deployment cases, including large networks

   that desire to leverage multiple IOAM-Data-Fields at the same time.

It would be good to have a technical characterization about what is meant by "friendly" in this excerpt. Is this what is discussed in the paragraph right after or you had something else in mind? If so, please make it explicit.

* I'm afraid that the security considerations section is under-specified. I would cite at least those in 8300 and the draft-ietf-sfc-nsh-integrity.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James Guichard
Envoyé : jeudi 2 septembre 2021 20:02
À : James Guichard <[email-masked]>; [email-masked]
Cc : [email-masked]
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

Thanks!

Jim & Joel

Dear WG:

Thanks!

Jim & Joel

_________________________________________________________________________________________________________________________

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: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 3 Sep 2021 16:07:05 +0000

Hi, Jim and Joel,

I support advancing draft-ietf-sfc-ioam-nsh. This document has received lots of WG review and input and I feel is technically (and stylistically) ready.

Thanks,

Carlos.

9/2/21 午後2:02、James Guichard <[email-masked]<mailto:[email-masked]>>のメール:

Dear WG:

Please read the document and provide comments to the SFC WG mailing list no later than September 17th2021. Note that this document is a normative reference for https://datatracker.ietf.org/doc/html/draft-ietf-sfc-proof-of-transit that is currently in AD review and we would therefore like to conclude this WGLC so that its dependent documents can further progress.

Thanks!

Jim & Joel

Dear WG:

Please read this document if you haven’t read the most recent version and send your comments to the SFC WG list no later than September 1st 2021.

Thanks!

Jim & Joel

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

---

From: Tal Mizrahi <[email-masked]>
Date: Sat, 4 Sep 2021 09:26:32 +0300

Hi,

I believe this draft is ready to be submitted to the IESG for publication.

Regards,
Tal.

On Wed, Aug 18, 2021 at 3:32 PM James Guichard <
[email-masked]> wrote:

> Please read this document if you haven’t read the most recent version and
> send your comments to the SFC WG list no later than September 1st 2021.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributor please response to indicate
> whether you know of any undisclosed IPR related to this document.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Mon, 6 Sep 2021 10:23:10 +0800 (CST)

Hi, Jim and Joel,

I support advancing draft-ietf-sfc-ioam-nsh.

One comment for consideration：

Suggest to replace the following figure in“3.  IOAM data fields encapsulation in NSH”

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP = TBD_IOAM | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
 | Service Path Identifier | Service Index | S
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
 | ... | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
with

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP = TBD_IOAM | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
 | Service Path Identifier | Service Index | S
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
 ~ Context Header(s) ~ |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

Best Regards,

Yuehua Wei

M: +86 13851460269 E: [email-masked]

原始邮件

发件人：JamesGuichard
收件人：James Guichard;[email-masked];
抄送人：[email-masked];
日 期 ：2021年09月03日 02:03
主 题 ：Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

[email-masked]

Dear WG:

 

 

Thanks!

Jim & Joel

 

Dear WG:

 

 

 

 

Thanks!

Jim & Joel

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 6 Sep 2021 20:24:30 -0400

I have read this draft and support its publication.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 7 Sep 2021 18:55:56 +0000

I have read the document and support the WGLC. I think the discussion of the encapsulation approach is very helpful.

Best Regards,

Linda Dunbar
发件人：JamesGuichard
抄送人：[email-masked]<mailto:[email-masked]>;

Please read the document and provide comments to the SFC WG mailing list no later than September 17th 2021. Note that this document is a normative reference for https://datatracker.ietf.org/doc/html/draft-ietf-sfc-proof-of-transit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sfc-proof-of-transit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66538d1748f44d91e3c408d970dd5539%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637664918188265564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NpIGn%2BgdM85tKquMfDdvaLxreZKj9Wiqhr5OCFmPms8%3D&reserved=0> that is currently in AD review and we would therefore like to conclude this WGLC so that its dependent documents can further progress.

Thanks!

Jim & Joel

Dear WG:

Thanks!

Jim & Joel

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66538d1748f44d91e3c408d970dd5539%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637664918188275525%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ympSh8%2BKV5TN0ZoO%2BrbCwgXVfWdwlcau2nNLygITbNE%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Sep 2021 15:00:00 -0700

Dear Authors and All,
I've read the current version of the draft and have some comments I'd like
to share with you. I much appreciate your thoughts on where this work
should go considering developments in other IETF WGs. Please find my notes
and questions below:

   - It is stated in the Abstract that:

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.

But that is the case only for the pre-allocated and incremental trace
option types. The Direct Export option
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/> does
not write telemetry data into the data packet itself but export telemetry
information in a specially constructed packet.
And as we are talking about different IOAM trace options, the question of
the scope of this document seems appropriate. There is a WGLC on two IOAM
documents
<https://mailarchive.ietf.org/arch/msg/ippm/A0OcGQ5LlNjnjfRVp_iUTMYMrcs/>
active through September 15th at the IPPM WG. I believe that it would be
beneficial if we had a single document that describes the applicability of
IOAM in all its functionality defined by documents in IPPM WG. Of course,
that cannot be a moving target as that would not be helpful. But since the
IPPM WG discusses the progress of two IOAM documents, it could be a great
time to address the applicability of the Direct Export trace type
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/> and
Loopback and Active flags defined in draft-ietf-ippm-ioam-flags
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/>. It would be
concerning to have more than one SFC document describing the applicability
of the generic IOAM mechanisms.

   - The location of the IOAM header in the SFC NSH-encapsulated packet is
   defined in Section 3:

   IOAM-Data-Fields are carried in NSH
   using a next protocol header which follows the NSH MD context
   headers.

I've checked RFC 8300 but couldn't find it defines the Next Protocol
header. Also, it appears that NSH Context headers are optional. Hence my
question. Is the presence of an NSH Context header required when using
IOAM? Could you clarify which mechanism is used to identify the payload of
an SFC NSH-encapsulated packet as IOAM?

   - If I understand the format of the IOAM header defined in Section 3
   correctly, the header's length is limited by 1020 octets, while the
   effective length containing IOAM options and data - 1016 octets. Is that
   correct? What is the recommended technique of collecting IOAM data that
   exceeds that limit?
   - In Section 4.1, I've found the text reflecting the history of the
   discussion about how to carry the IOAM header using NSH encapsulation. As
   the text has no normative value, I suggest moving it into an Appendix.
   - I find the rules of handling the O-bit in NSH listed in Section 4.2
   inconsistent and confusing. The IOAM header is not part of NSH
   encapsulation but is a part of the payload. But in one case, when user data
   follows it, the O-bit must not be set as. If there's no user data after the
   IOAM header, then the O-bit must be set. But from the perspective of NSH
   encapsulation, it includes specially constructed data added for the sole
   purpose of collecting OAM/telemetry information. Then, why, in one case,
   the O-bit is cleared and in the other set if, in both cases, the
   NSH-encapsulated packet is used to perform the OAM function?

I much appreciate your consideration of my comments and questions and
looking forward to your feedback.

Regards,
Greg

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Fri, 10 Sep 2021 13:16:59 +0000

Hello, 
I read this document and I support advancing it.
Best regards
Roberta

From: sfc <[email-masked]> On Behalf Of James Guichard
Sent: Thursday, September 2, 2021 8:02 PM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

Thanks!

Jim & Joel

From: James Guichard <mailto:[email-masked]> 
Sent: Wednesday, August 18, 2021 8:32 AM
To: mailto:[email-masked]
Cc: mailto:[email-masked]
Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear WG:

Thanks!

Jim & Joel

[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5d6bc76f69df4c2a8cdb08d962443814%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637648867414771153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YC18mVsN4Kfw%2BAP2OfZBWkj8jLGembb1HEXsR1vAzLo%3D&reserved=0

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 10 Sep 2021 09:42:01 -0400

Hi WG,

I have been following the draft as part of MPLS encapsulation for IOAM in
draft-gandhi-mpls-ioam.

I believe the document is ready to progress to the next step.

Thanks,

Rakesh

> Subject: Re: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>
> Dear WG:
>
> The chairs have extended the WGLC for a further 2 weeks due to the lack of
> feedback from the WG on the original WGLC.
>
> Please read the document and provide comments to the SFC WG mailing list
> no later than September 17th 2021. Note that this document is a normative
> reference for
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-proof-of-transit
> that is currently in AD review and we would therefore like to conclude this
> WGLC so that its dependent documents can further progress.
>
> Thanks!
>
> Jim & Joel
>
> Subject: WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>
> Dear WG:
>
> Please read this document if you haven't read the most recent version and
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5d6bc76f69df4c2a8cdb08d962443814%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637648867414771153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YC18mVsN4Kfw%2BAP2OfZBWkj8jLGembb1HEXsR1vAzLo%3D&reserved=0
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 21 Sep 2021 14:33:13 -0700

Dear WG Chairs, Authors, and the WG community,
two weeks ago I've shared my thoughts, concerns related to
draft-ietf-sfc-ioam-nsh. So far, I haven't seen any comments from the WG,
nor responses from the Authors. It could be that my note got buried under
other emails. I want to recapitulate my position - the scope of the draft
seems more narrow than what was already produced by the IPPM WG (the WG LC
on two IOAM drafts has concluded). Considering the level of maturity of
IOAM specifications from the IPPM WG, it seems beneficial to have a single
document describing for the SFC NSH the applicability of all defined up to
date IOAM tracing options.
I hope that the Authors and the WG community will share their opinions.
Below is a copy of my earlier comments.

Regards,
Greg

On Tue, Sep 7, 2021 at 3:00 PM Greg Mirsky <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>
> does not write telemetry data into the data packet itself but export
> telemetry information in a specially constructed packet.
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>
> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags
> <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/>. It would
> be concerning to have more than one SFC document describing the
> applicability of the generic IOAM mechanisms.
>
>
>    - The location of the IOAM header in the SFC NSH-encapsulated packet
>    is defined in Section 3:
>