Dear Rob, Med and IESG Based on Ben's feedback, I submitted the final -11 version.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-11 I think the document is ready now for the RFC editor queue. Best wishes Thomas -----Original Message----- From: Benjamin Kaduk <ka...@mit.edu> Sent: Tuesday, September 14, 2021 1:57 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> Cc: i...@ietf.org; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) Hi Thomas, Many thanks; that looks like it should work quite nicely. -Ben On Sat, Sep 11, 2021 at 07:46:17AM +0000, thomas.g...@swisscom.com wrote: > Hi Benjamin, > > Thanks for the clarifications and suggestions. Very much appreciated. > > > I think it would be good to add a few words to hint at dimensional > > modeling, and maybe also to add a few words to clarify why > > draft-hegde-spring-mpls-seamless-sr is being referenced. > > I put additional thoughts into that paragraph and changed the reference to > RFC 8670 (BGP Prefix Segment in Large-Scale Data Centers) instead. RFC 7983 > (Use of BGP for Routing in Large-Scale Data Centers) describes the use of > BGP labeled-unicast in large data center environments. Where RFC 8670 focuses > on using Segmenting Routing with BGP by using the same architecture. RFC 8670 > describes the motivation of such a migration and is a stable document. I hope > this makes more sense now. > > Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow > Information Export [RFC7012] can be leveraged in dimensional data > modelling to account traffic to MPLS SR label dimensions within a > Segment Routing domain. > > Another use case is to monitor MPLS control plane migrations from > dynamic BGP labels [RFC8277] to BGP Prefix-SIDs [RFC8669]. The > motivation and benefits for such a migration is described in > [RFC8670]. > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2F%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.com > %2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fmaster%2Fdraft-ie > tf-opsawg-ipfix-mpls-sr-label-type-10.txt%26url2%3Dhttps%3A%2F%2Fraw.g > ithubusercontent.com%2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type > %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt&data > =04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123c > d4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000&sdata=6J6eFY%2FHjJWFUIKugTO%2F0q%2FhSUm9a > 54DE8qV2LSCa3E%3D&reserved=0 > > Let me know your thoughts. > > Best wishes > Thomas > > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Saturday, September 11, 2021 4:02 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> > Cc: i...@ietf.org; > draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; > opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com > Subject: Re: Benjamin Kaduk's No Objection on > draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) > > Hi Thomas, > > On Thu, Sep 09, 2021 at 05:19:00AM +0000, thomas.g...@swisscom.com wrote: > > Hi Benjamin, > > > > > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of > > > maturity to be a good reference here (and thus, that this example is > > > worth including). > > I agree. The only alternative is to reference > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07&data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W9Y9RGobCEdshkILs7JeW2HpAE3T%2BdJ322XTfbD9STo%3D&reserved=0 > > instead. The challenge is that Seamless MPLS is widely supported and used > > at network vendors and operators but not yet standardized at IETF. Both > > Seamless MPLS drafts are either in progress or expired. If you don't > > object, I like to keep that example and reference for not having a better > > alternative. > > To be clear, I don't have issues with referring to an individual draft in the > abstract. It's more that for this particular draft, I came away very unsure > what I was supposed to take away from reading it that made it worth > referencing. It would probably be possible to add more words to > draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for > in draft-hedge-spring-mpls-seamless-sr, or to make edits to > draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify what's > interesting about it that we want the reader to think about. Since I am > still unclear on what the important concepts are, I unfortunately don't have > any concrete suggestions for what that text could be. > > > > For example, the referenced section refers to "option A", "option B", and > > > "option C" but I couldn't find where in the document these options were > > > enumerated as such. > > That refers to RFC4364 section 10. > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4364%23section-10&data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480213187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=egYBTw%2BjoE%2FPMObnmULYGU87D5%2B3SI8uPSI9wK62%2Frg%3D&reserved=0. > > And yes, the author should include the reference for clarity. I will > > follow up on that. > > Thanks for following up; having that reference from > draft-hegde-spring-mpls-seamless-sr would have been very helpful. > > > >I don't understand the word "dimensions" in this context. (It > > >doesn't appear in the referenced documents, either, which suggests > > >that a different word may have been intended.) > > > > Regarding: account traffic to MPLS SR label dimensions > > > > In data engineering, metrics are divided into two groups. Dimensions > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fdimension&data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9zlM0D%2Fgn1IWEJhRydRtL%2F9yBihplYJh2wXqqjZEdDg%3D&reserved=0) > > and measurements > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.merriam-webster.com%2Fdictionary%2Fmeasurement&data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dQjLrclhC04vYVxY84On41kzB1wT1xWSWry0c6sMk7c%3D&reserved=0). > > Dimensions are important for Dimensional data modelling > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDimensional_modeling&data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480218162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3WUOXXKkCD6s7ToxCrEkEuZPlPAPHC4xHZY1VknBYe0%3D&reserved=0). > > To give measurements context. I agree that the words dimensions and > > measurements aren't widely used at IETF in such a context. > > Thanks for the reference! Knowing that "dimensional modeling" is the > intended context would have been enough for me to figure it out, I think. > That could be as simple as "account traffic to MPLS SR label dimensions > within a dimensional model of a Segment Routing domain" (if that makes sense). > > > > The most that I would suggest changing is to add the word "significant", > > > for "no significant extra security considerations". > > Acknowledged and merged into -09 version. > > > > > I suggest dropping the word "new", which is a relative term and will be > > > less and less applicable over time. > > Acknowledged and merged into -09 version. > > > > I am going to publish -09 version once all the IESG reviews are > > concluded. Here the inputs I received and merged so far > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org%2F%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.c > > om > > %2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fmaster%2Fdraft- > > ie > > tf-opsawg-ipfix-mpls-sr-label-type-08.txt%26url2%3Dhttps%3A%2F%2Fraw > > .g > > ithubusercontent.com%2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-ty > > pe > > %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt&da > > ta > > =04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c8 > > 27 > > 20%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7 > > CU > > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > > ha > > WwiLCJXVCI6Mn0%3D%7C1000&sdata=jSqQWycX%2BpY2Xwo%2FBgK4blpMOpIq1 > > 8g > > byT6B322uF2E%3D&reserved=0 > > Thanks for the link. > > I think it would be good to add a few words to hint at dimensional modeling, > and maybe also to add a few words to clarify why > draft-hegde-spring-mpls-seamless-sr is being referenced. > > -Ben > > > Best wishes > > Thomas > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker <nore...@ietf.org> > > Sent: Wednesday, September 8, 2021 7:01 PM > > To: The IESG <i...@ietf.org> > > Cc: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; > > opsawg-cha...@ietf.org; opsawg@ietf.org; > > mohamed.boucad...@orange.com; mohamed.boucad...@orange.com > > Subject: Benjamin Kaduk's No Objection on > > draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=04%7C01 > > %7 > > CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364 > > e5 > > b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7 > > CT > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > > CI > > 6Mn0%3D%7C1000&sdata=tNQj%2BEZIlFdo5rWk03qTnoianqjvmvzWvy80NxC2s > > 5o > > %3D&reserved=0 for more information about DISCUSS and COMMENT > > positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > > ta > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type% > > 2F > > &data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7 > > f0 > > 8d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C63766922526 > > 82 > > 21998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC > > JB > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=17OrrPh2jRjHfJT9cTGUeBeK > > Vu > > qlk%2FbUqdEGG5tgjEY%3D&reserved=0 > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > This document presents a couple use cases for the new IE 46 codepoints, but > > both are in the context of monitoring the rollout of a migration of > > control-plane technology. Are there steady-state use cases for these > > values? > > > > Section 2 > > > > Another use case is to monitor MPLS control plane migrations from > > dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of > > Seamless MPLS SR described in Section 4.6 of > > [I-D.hegde-spring-mpls-seamless-sr]. > > > > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state > > of maturity to be a good reference here (and thus, that this example > > is worth including). For example, the referenced section refers to > > "option A", "option B", and "option C" but I couldn't find where in > > the document these options were enumerated as such. (Maybe it's > > supposed to be what's described in sections 4.1.{1,2,3}; maybe not.) > > (Further aside about that draft: it also isn't using the RFC 8174 > > version of the BCP 14 boilerplate, and has more authors than > > recommended by the RFC Series Editor statement on authorship, > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Fpipermail%2Frfc-interest%2F2015-May%2F008869.html&a > > mp > > ;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d > > 97 > > 4c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268221 > > 99 > > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > > I6 > > Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY6z%2FpAIhrLfzUHY9RH65KvLCq > > 7H > > FlqpFXNUzPgdENY%3D&reserved=0 > > .) > > > > Section 5 > > > > If pressed to come up with new security considerations from this > > work, I would submit that conveying information about what > > control-plane protocol is in use gives an attacker information to > > use in planning an attack on that control plane. But the attacker > > would need to have access to the IPFIX information in order to do > > so, and RFCs 7012 and > > 7011 are clear that the mechanism for conveying the IPFIX data has to > > provide confidentiality protection, so it seems that endpoint compromise > > would be needed for the attacker to actually gain access, and it's hard to > > come up with a realistic scenario involving endpoint compromise where these > > new codepoints are key to an attack. In short, it doesn't really seem like > > a consideration that's relevant enough to be worth mentioning in this > > document, so I'm okay with leaving this section as-is. > > > > The most that I would suggest changing is to add the word "significant", > > for "no significant extra security considerations". > > > > NITS > > > > Section 1 > > > > Four new routing protocol extensions, OSPFv2 Extensions > > [RFC8665], > > > > I suggest dropping the word "new", which is a relative term and will be > > less and less applicable over time. > > > > Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow > > Information Export [RFC7012] can be leveraged to account traffic to > > MPLS SR label dimensions within a Segment Routing domain. > > > > I don't understand the word "dimensions" in this context. (It > > doesn't appear in the referenced documents, either, which suggests > > that a different word may have been intended.) > > > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
