I'm going to push back a little here. If there is some IETF technology involved in the network (dataplane, management plane, control plane) and that technology continues to play a part in network slice, then this an IETF network slice. Clearly, if you have an optical network without a control plane and managed using TL1, then you may slice it, but it is not an IETF network slice. We have a long history of control and management plane technologies for "transport networks" that you can find mainly in the CCAMP working group (although some work in TEAS now covers the generalisations). I think we don't need any further change for this. Cheers, Adrian -----Original Message----- From: last-call <last-call-bounces@xxxxxxxx> On Behalf Of mohamed.boucadair@xxxxxxxxxx Sent: 23 July 2023 17:08 To: Dirk Von Hugo <dirkvhugo@xxxxxxxxx>; int-dir@xxxxxxxx Cc: draft-ietf-teas-ietf-network-slices.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx Subject: Re: [Last-Call] Intdir telechat review of draft-ietf-teas-ietf-network-slices-21 Hi Dirk, > Since on p.3 scope is limited to network technologies described > and standardized by the IETF, I would omit on p.4 mentioning > 'optical' and mayde replace by L3VPN or other IETF network > technology. This is a good observation, but I don't think a change is needed for this example :-) The framework intends to cover generally what is called outside the IETF "transport domain" or "transport network". Optical network are part of those. FYI, an instantiation of this framework in OTN can be for example in https://datatracker.ietf.org/doc/draft-ietf-ccamp-yang-otn-slicing/. You may then argue that then call these "IETF *"? I would agree that "IETF network slice" is a little bit misleading but is this a blocking point to digest the concept? FYI, the WG spent too many cycles on that single terminology point. I was among those in favor of avoiding calling this "IETF *" and proposed at the time "connectivity network slice", but the call of the WG was to proceed with the "IETF" in the name. I don't think that we need to reopen that discussion again. I leave this to Adrian, but if this helps we may consider the following: OLD: An IETF Network Slice is a logical partition of a network that uses IETF technology. NEW: An IETF Network Slice is a logical partition of a network that uses mainly IETF technology. Other technologies from other SDOs (e.g., IEEE, ITU) may be combined with IETF technologies for the realization Of a Network Slice. Cheers, Med > -----Message d'origine----- > De : last-call <last-call-bounces@xxxxxxxx> De la part de Dirk Von > Hugo via Datatracker > Envoyé : vendredi 21 juillet 2023 19:01 > À : int-dir@xxxxxxxx > Cc : draft-ietf-teas-ietf-network-slices.all@xxxxxxxx; last- > call@xxxxxxxx; teas@xxxxxxxx > Objet : [Last-Call] Intdir telechat review of draft-ietf-teas- > ietf-network-slices-21 > > Reviewer: Dirk Von Hugo > Review result: Ready with Nits > > Hello, > I am an assigned INT directorate reviewer for draft-ietf-teas- > ietf-network-slices. These comments were written primarily for the > benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along > with any other Last Call comments that have been received. For > more details on the INT Directorate, see > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2F&data=05%7C01%7Cmo > hamed.boucadair%40orange.com%7Cb52ac523b8d545f5840b08db8a0c18d0%7C > 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638255556796287942%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zi3YA%2FJPQfxnjgpGdUoBG > %2FvCW8XlWC2Jpk6U2uCOigU%3D&reserved=0 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fdatatracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2F&data=05%7C01%7Cm > ohamed.boucadair%40orange.com%7Cb52ac523b8d545f5840b08db8a0c18d0%7 > C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638255556796287942%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zi3YA%2FJPQfxnjgpGdUoB > G%2FvCW8XlWC2Jpk6U2uCOigU%3D&reserved=0> Based on my review, if I > was on the IESG I would ballot this document as NO OBJECTION. > ... > > The following are other (minor) issues I found with this document > that SHOULD be corrected before publication: > > Since on p.3 scope is limited to network technologies described > and standardized by the IETF, I would omit on p.4 mentioning > 'optical' and mayde replace by L3VPN or other IETF network > technology. > ____________________________________________________________________________ ________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
