Re: [sfc] [spring] Comments on draft-saad-mpls-miad-usecases

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
> 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.
>
>
>
> Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Monday, February 28, 2022 2:00 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tarek Saad <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; DetNet WG <[e-mail]>; spring <[e-mail]>;
> [e-mail]; Service Function Chaining IETF
> list <[e-mail]>
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> 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 <[e-mail]>
> 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
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Monday, February 28, 2022 12:58 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tarek Saad <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; DetNet WG <[e-mail]>; spring <[e-mail]>;
> [e-mail]
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> 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 <[e-mail]> 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
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Monday, February 28, 2022 10:56 AM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tarek Saad <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; DetNet WG <[e-mail]>; spring <[e-mail]>;
> [e-mail]
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> 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 <[e-mail]>
> wrote:
>
> 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
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Saturday, February 26, 2022 4:36 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tarek Saad <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; DetNet WG <[e-mail]>; spring <[e-mail]>;
> [e-mail]
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> 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 <[e-mail]>
> 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
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tarek Saad <[e-mail]>; mpls <[e-mail]>;
> [e-mail]; DetNet WG <[e-mail]>; spring <[e-mail]>;
> [e-mail]
> *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 <[e-mail]>
> wrote:
>
>
>    - 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 <[e-mail]>
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad <[e-mail]>
> *Cc:* mpls <[e-mail]>; [e-mail]; DetNet WG <[e-mail]>;
> spring <[e-mail]>; [e-mail]
> *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 <[e-mail]> 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%7C0612b57495a340db3d0308d9fb05c371%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637816824472211805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Coxqh6blcdoKOQPTmSowDNzv8pL1l1M%2B3XuuGSWWXVI%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *[e-mail] <
> [e-mail]>, mpls <[e-mail]>,
> [e-mail] <[e-mail]>, DetNet WG <[e-mail]>, spring <
> [e-mail]>
> *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
>
>