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://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt 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%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268212042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZE7ap4WzesHE5wOJstYpopUlqTm8AJDiFZ91CyTlVBg%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%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7fB48K9MprNUDazBaASPc1PmYiCYeCwhS4VAFAuxwPU%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%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9DebdS9dUUB5ClCNwMNal5h0dFol9r9gPnRIfqt04jM%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%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yt7PrhbXPo93V6UOFX%2FCZC8QD7%2BSWy5gsR83afNvglU%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%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=No%2FQrRQ0Id4Pbkn7TaMOTNKWlVDaf7nJixuV3oRXTzA%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.com > %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-type > %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt&data > =04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c827 > 20%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000&sdata=jSqQWycX%2BpY2Xwo%2FBgK4blpMOpIq18g > 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%7C364e5 > b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C1000&sdata=tNQj%2BEZIlFdo5rWk03qTnoianqjvmvzWvy80NxC2s5o > %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%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2F > &data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f0 > 8d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C6376692252682 > 21998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=17OrrPh2jRjHfJT9cTGUeBeKVu > 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& > ;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d97 > 4c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C63766922526822199 > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 > Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY6z%2FpAIhrLfzUHY9RH65KvLCq7H > 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
