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 <haoyu.s...@futurewei.com> 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 <gregimir...@gmail.com> > *Sent:* Monday, February 28, 2022 2:00 PM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Tarek Saad <tsaad....@gmail.com>; mpls <m...@ietf.org>; > p...@ietf.org; DetNet WG <det...@ietf.org>; spring <spring@ietf.org>; > draft-saad-mpls-miad-useca...@ietf.org; Service Function Chaining IETF > list <s...@ietf.org> > *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 <haoyu.s...@futurewei.com> > 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 <gregimir...@gmail.com> > *Sent:* Monday, February 28, 2022 12:58 PM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Tarek Saad <tsaad....@gmail.com>; mpls <m...@ietf.org>; > p...@ietf.org; DetNet WG <det...@ietf.org>; spring <spring@ietf.org>; > draft-saad-mpls-miad-useca...@ietf.org > *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 <haoyu.s...@futurewei.com> 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 <gregimir...@gmail.com> > *Sent:* Monday, February 28, 2022 10:56 AM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Tarek Saad <tsaad....@gmail.com>; mpls <m...@ietf.org>; > p...@ietf.org; DetNet WG <det...@ietf.org>; spring <spring@ietf.org>; > draft-saad-mpls-miad-useca...@ietf.org > *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 <haoyu.s...@futurewei.com> > 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 <gregimir...@gmail.com> > *Sent:* Saturday, February 26, 2022 4:36 PM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Tarek Saad <tsaad....@gmail.com>; mpls <m...@ietf.org>; > p...@ietf.org; DetNet WG <det...@ietf.org>; spring <spring@ietf.org>; > draft-saad-mpls-miad-useca...@ietf.org > *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 <haoyu.s...@futurewei.com> > 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 <gregimir...@gmail.com> > *Sent:* Friday, February 25, 2022 9:54 AM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Tarek Saad <tsaad....@gmail.com>; mpls <m...@ietf.org>; > p...@ietf.org; DetNet WG <det...@ietf.org>; spring <spring@ietf.org>; > draft-saad-mpls-miad-useca...@ietf.org > *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 <haoyu.s...@futurewei.com> > 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 <gregimir...@gmail.com> > *Sent:* Thursday, February 24, 2022 5:09 PM > *To:* Tarek Saad <tsaad....@gmail.com> > *Cc:* mpls <m...@ietf.org>; p...@ietf.org; DetNet WG <det...@ietf.org>; > spring <spring@ietf.org>; draft-saad-mpls-miad-useca...@ietf.org > *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 <tsaad....@gmail.com> 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 <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Friday, February 18, 2022 at 4:15 PM > *To: *draft-saad-mpls-miad-useca...@ietf.org < > draft-saad-mpls-miad-useca...@ietf.org>, mpls <m...@ietf.org>, > p...@ietf.org <p...@ietf.org>, DetNet WG <det...@ietf.org>, spring < > spring@ietf.org> > *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 > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
