Subject: [Pals] Comments on draft-saad-mpls-miad-usecases

From: Greg Mirsky <[email-masked]>
Date: Fri, 18 Feb 2022 13:14:40 -0800

Dear Authors,
thank you for your work putting this document together. It helps to analyze
essential use cases in the scope of the work at the Open DT. Attached,
please find a copy of the draft with my notes and some
editorial suggestions. I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

---

From: Tarek Saad <[email-masked]>
Date: Thu, 24 Feb 2022 13:52:45 +0000

Hi Greg,

Thanks for your comments. I’ve addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt>

Regards,
Tarek (for co-authors)

From: spring <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Friday, February 18, 2022 at 4:15 PM
To: [email-masked] <[email-masked]>, mpls <[email-masked]>, [email-masked] <[email-masked]>, DetNet WG <[email-masked]>, spring <[email-masked]>
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze essential use cases in the scope of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial suggestions. I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 24 Feb 2022 17:09:16 -0800

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed
the diff and got several follow-up notes:

   - the new text in the Introduction section explains the ISD as being
   encoded as labels:

within the label stack, e.g., encoded as labels, referred to as In

     Stack Data (ISD), and

I think s/as labels/into label stack elements/ makes the text a bit more
accurate. What do you think?

   - in my earlier comments, I've noted that the informational RFC 8596
   appears not posing any requirements for enhancements in the MPLS data
   plane. If I am missing something, please let me know.
   - I might have missed it earlier. The TSN is the term used for a very
   specific technology developed at IEEE to support, for example, URLLC
   services. The DetNet WG defines the methodology in support of these
   services using IETF technologies - MPLS and IP. I think it would be
   appropriate if an IETF document refers to Deterministic Networking, not
   TSN. What is your opinion?

Regards,
Greg

On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Thanks for your comments. I’ve addressed several of your comments. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> <https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: [email-masked] <
> [email-masked]>, mpls <[email-masked]>,
> [email-masked] <[email-masked]>, DetNet WG <[email-masked]>, spring <
> [email-masked]>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some

---

From: Haoyu Song <[email-masked]>
Date: Fri, 25 Feb 2022 17:42:04 +0000

*   in my earlier comments, I've noted that the informational RFC 8596 appears not posing any requirements for enhancements in the MPLS data plane. If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to be supported in MPLS as well, so it's a legitimate use case like the others in the draft. When we need to support multiple such use cases at the same time, we need a generic mechanism to support them, so the use-case draft serves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>; spring <[email-masked]>; [email-masked]
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed the diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being encoded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more accurate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 appears not posing any requirements for enhancements in the MPLS data plane. If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very specific technology developed at IEEE to support, for example, URLLC services. The DetNet WG defines the methodology in support of these services using IETF technologies - MPLS and IP. I think it would be appropriate if an IETF document refers to Deterministic Networking, not TSN. What is your opinion?
Regards,
Greg

On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca25ba0813707413b445108d9f7fb7dac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637813481798472749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5ZAFo77LGZeJuVzSIgVan4snl%2FC%2FaMEpdKS62AY%2BxB8%3D&reserved=0>

Regards,
Tarek (for co-authors)

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 18, 2022 at 4:15 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, DetNet WG <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze essential use cases in the scope of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial suggestions. I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 25 Feb 2022 09:54:28 -0800

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to
the existing MPLS architecture. I would agree that SFC NSH using MPLS to
connect SFP components might benefit from the new enhancements to the MPLS,
but so would any other client that uses the MPLS network. Do you think that
the use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <[email-masked]> wrote:

> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it’s a legitimate use case like the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad <[email-masked]>
> *Cc:* mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>;
> spring <[email-masked]>; [email-masked]
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca25ba0813707413b445108d9f7fb7dac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637813481798472749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5ZAFo77LGZeJuVzSIgVan4snl%2FC%2FaMEpdKS62AY%2BxB8%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 25 Feb 2022 19:34:00 +0000

Hi Greg,

There have been some existing standards (e.g., EL and this one) and proposals (some are listed in the document) with each dealing with a specific use case. I think it's beneficial to list them all and then consider to use a generic mechanism to handle all these otherwise piecemeal solutions. Of course, finally we would need to pick which shall actually be supported with the generic method, but at this point, we shall not limit ourself.

Regards,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song <[email-masked]>
Cc: Tarek Saad <[email-masked]>; mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>; spring <[email-masked]>; [email-masked]
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to the existing MPLS architecture. I would agree that SFC NSH using MPLS to connect SFP components might benefit from the new enhancements to the MPLS, but so would any other client that uses the MPLS network. Do you think that the use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; DetNet WG <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C98e5a6f0e02545303be608d9f887e5ee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637814084842706350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWEI89B3BQGMJLu%2Fb4HmOSMGNZwSIqC74cwyX0oD4Rs%3D&reserved=0>

Regards,
Tarek (for co-authors)

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 26 Feb 2022 16:35:30 -0800

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my
question How the MIAD work is applicable to the informational RFC 8596? In
other words, What do you see as missing in the solution described in RFC
8596 that MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it’s beneficial to list them all and then
> consider to use a generic mechanism to handle all these otherwise piecemeal
> solutions. Of course, finally we would need to pick which shall actually be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* Tarek Saad <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; DetNet WG <[email-masked]>; spring <[email-masked]>;
> [email-masked]
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C98e5a6f0e02545303be608d9f887e5ee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637814084842706350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWEI89B3BQGMJLu%2Fb4HmOSMGNZwSIqC74cwyX0oD4Rs%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 28 Feb 2022 18:05:00 +0000

Hi Greg,

What I think is that whatever output is from MIAD, it will provide a new solution to support NSH SFC in MPLS.
RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be cooperative with the other use cases in the same packet. MIAD tries to solve this problem.

Best,
Haoyu

Sent: Saturday, February 26, 2022 4:36 PM

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my question How the MIAD work is applicable to the informational RFC 8596? In other words, What do you see as missing in the solution described in RFC 8596 that MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Haoyu

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: Tarek Saad <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; DetNet WG <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,

Regards,
Greg

Hi Tarek,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ce4a77166e27a4b79306108d9f9891661%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637815189475709108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xYkZ2xwVot4LiLnYPp%2FL1y8d%2Bk%2BtNp3%2B54JjLRk7oE4%3D&reserved=0>

Regards,
Tarek (for co-authors)

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 10:56:27 -0800

Hi Haoyu,
can you give an example of "the other use cases in the same packet"? I
don't think that discussing some hypothetical scenarios is a productive way
for the Open DT.

Regards,
Greg

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <[email-masked]>
wrote:

> RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be
> cooperative with the other use cases in the same packet. MIAD tries to
> solve this problem.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *Sent:* Saturday, February 26, 2022 4:36 PM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ce4a77166e27a4b79306108d9f9891661%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637815189475709108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xYkZ2xwVot4LiLnYPp%2FL1y8d%2Bk%2BtNp3%2B54JjLRk7oE4%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 28 Feb 2022 20:50:41 +0000

Hi Greg,

How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I think these scenarios are possible. Maybe I misunderstand something. Could you please give more explanation on why you don't like this use case particularly? Thanks.

Best,
Haoyu

Sent: Monday, February 28, 2022 10:56 AM

Hi Haoyu,
can you give an example of "the other use cases in the same packet"? I don't think that discussing some hypothetical scenarios is a productive way for the Open DT.

Regards,
Greg

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Regards,
Haoyu

Hi Haoyu,

Regards,
Greg

Hi Tarek,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cda35e9b46e054e41cf9b08d9faec0dc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637816714042137291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NBW4%2BTmNyQz%2Fs7HwwxW0U1MFxejG7DlRZObINe14Iw0%3D&reserved=0>

Regards,
Tarek (for co-authors)

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 12:57:40 -0800

Hi Haoyu,
I wouldn't say that I don't like any use case, I just don't understand how
the RFC 8596 is related to MIAD work. As for your questions, I believe that
all these scenarios should be discussed by the SFC WG. In fact,
draft-ietf-sfc-ioam-nsh defines one them already.

Regards,
Greg

On Mon, Feb 28, 2022, 12:50 Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> How about IOAM (or other types of OAM) + SFC (i.e., apply OAM
> simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice)
> ? I think these scenarios are possible. Maybe I misunderstand something.
> Could you please give more explanation on why you don’t like this use case
> particularly? Thanks.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *Sent:* Monday, February 28, 2022 10:56 AM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cda35e9b46e054e41cf9b08d9faec0dc5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637816714042137291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NBW4%2BTmNyQz%2Fs7HwwxW0U1MFxejG7DlRZObINe14Iw0%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 28 Feb 2022 21:19:44 +0000

Hi Greg,

Here's my logic. I think NSH SFC could be a use case in MPLS and RFC8596, as a reference, shows that this has been considered before, so I take it as an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are working on a generic way to support different use cases in MPLS data plane , so the use cases also include NSH SFC, right? Sure, finally we may end up with a different solution than RFC8596, but we have good reason for that, as I have explained in pervious emails (e.g., to support multiple use cases at the same time). Please note that this is only a use case draft and it doesn't enforce any solution but to show we have such requirements. When MIAD is developed, whether and where another draft for applying NSH SFC in it needs to be developed is a totally different issue.

Best,
Haoyu

Sent: Monday, February 28, 2022 12:58 PM

Hi Haoyu,
I wouldn't say that I don't like any use case, I just don't understand how the RFC 8596 is related to MIAD work. As for your questions, I believe that all these scenarios should be discussed by the SFC WG. In fact, draft-ietf-sfc-ioam-nsh defines one them already.

Regards,
Greg

On Mon, Feb 28, 2022, 12:50 Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Regards,
Haoyu

Hi Haoyu,

Regards,
Greg

Hi Tarek,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1c077c7484e4e914f8d08d9fafcfd9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637816786791729815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YsRqTdqBanHII3XGVQxpiAM%2Bn1WHPipcWLtncV1vtag%3D&reserved=0>

Regards,
Tarek (for co-authors)

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 14:00:29 -0800

Hi Haoyu,
adding the SFC WG to our discussion.

I feel that if we continue your way of thinking about the SFC NSH and the
MIAD, then everything we know how to do over MPLS should be revisited.
Would you agree that is a fair conclusion based on your explanation of your
position? I can agree that the extended MPLS architecture enhanced by the
MIAD coupled with the new ways of doing things we already know how to do
might show some level of improvement. But I believe that would not be level
to justify dramatically changing existing mechanisms of delivery services
over an MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596
is informational because it describes how existing and known MPLS
techniques can be used to connect elements of an SFP. I think that is the
best possible solution - re-using the existing technology.
Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciate
it if other participants of the Open DT work and members of WGs share their
opinions. I've stated mine, I believe quite clearly.

Regards,
Greg

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Here’s my logic. I think NSH SFC could be a use case in MPLS and RFC8596,
> as a reference, shows that this has been considered before, so I take it as
> an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are
> working on a generic way to support different use cases in MPLS data plane
> , so the use cases also include NSH SFC, right? Sure, finally we may end up
> with a different solution than RFC8596, but we have good reason for that,
> as I have explained in pervious emails (e.g., to support multiple use cases
> at the same time). Please note that this is only a use case draft and it
> doesn’t enforce any solution but to show we have such requirements. When
> MIAD is developed, whether and where another draft for applying NSH SFC in
> it needs to be developed is a totally different issue.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *Sent:* Monday, February 28, 2022 12:58 PM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1c077c7484e4e914f8d08d9fafcfd9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637816786791729815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YsRqTdqBanHII3XGVQxpiAM%2Bn1WHPipcWLtncV1vtag%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 28 Feb 2022 22:23:05 +0000

Hi Greg,

Thank you for the clarification. To further the discussion, could you please answer the following questions?

  1.  Could you be specific on exactly what  should be revisited on how to do things over MPLS? This is very important and should be of the interest of the open DT.
  2.  Given that there's no solution consensus yet at this stage, what make you think it will be dramatical changing  existing mechanisms of delivery services over an MPLS network?
  3.  Similarly, based on what you think RFC8596 is the "best possible" solution? This seems a very bold claim.

Thanks,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Monday, February 28, 2022 2:00 PM
To: Haoyu Song <[email-masked]>
Cc: Tarek Saad <[email-masked]>; mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>; spring <[email-masked]>; [email-masked]; Service Function Chaining IETF list <[email-masked]>
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,

I feel that if we continue your way of thinking about the SFC NSH and the MIAD, then everything we know how to do over MPLS should be revisited. Would you agree that is a fair conclusion based on your explanation of your position? I can agree that the extended MPLS architecture enhanced by the MIAD coupled with the new ways of doing things we already know how to do might show some level of improvement. But I believe that would not be level to justify dramatically changing existing mechanisms of delivery services over an MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596 is informational because it describes how existing and known MPLS techniques can be used to connect elements of an SFP. I think that is the best possible solution - re-using the existing technology.
Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciate it if other participants of the Open DT work and members of WGs share their opinions. I've stated mine, I believe quite clearly.

Regards,
Greg

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Regards,
Haoyu

Hi Haoyu,

Regards,
Greg

Hi Tarek,

Thanks for your comments. I've addressed several of your comments. The latest diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0612b57495a340db3d0308d9fb05c371%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637816824472211805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Coxqh6blcdoKOQPTmSowDNzv8pL1l1M%2B3XuuGSWWXVI%3D&reserved=0>

Regards,
Tarek (for co-authors)

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Feb 2022 14:32:39 -0800

Hi Haoyu,
please find my notes in-line below tagged by GIM>>.

Regards,
Greg

On Mon, Feb 28, 2022 at 2:23 PM Haoyu Song <[email-masked]> wrote:

>    1. Could you be specific on exactly what  should be revisited on how
>    to do things over MPLS? This is very important and should be of the
>    interest of the open DT.
>
> GIM>> You either misunderstood my note or are trying to put words in my
mouth that I didn't say. I merely extended the logic you've presented
explaining your support of keeping RFC 8596 in the use case draft.

>
>
>    1. Given that there’s no solution consensus yet at this stage, what
>    make you think it will be dramatical changing  existing mechanisms of
>    delivery services over an MPLS network?
>
> GIM>> Again, you're either misunderstanding my position or else. I am not
proposing revisiting existing and well-known methods of delivering services
over an MPLS network.

>
>    1.
>    2. Similarly, based on what you think RFC8596 is the “best possible”
>    solution? This seems a very bold claim.
>
> GIM>> Because it follows the KISS principle.

>    1.
> *Sent:* Monday, February 28, 2022 2:00 PM
> [email-masked]; Service Function Chaining IETF
> list <[email-masked]>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C0612b57495a340db3d0308d9fb05c371%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637816824472211805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Coxqh6blcdoKOQPTmSowDNzv8pL1l1M%2B3XuuGSWWXVI%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>