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://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07 > 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://datatracker.ietf.org/doc/html/rfc4364#section-10. 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://www.merriam-webster.com/dictionary/dimension) and measurements > (https://www.merriam-webster.com/dictionary/measurement). Dimensions are > important for Dimensional data modelling > (https://en.wikipedia.org/wiki/Dimensional_modeling). 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://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-08.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt 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%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cqmEKyd5B0ZoBK0kTMNF1%2BnOFoyJ2%2FmyPNVRoLvEXTA%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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NRFVezr2O2J6IyAiXvlXm%2BdXFtZIyS1aM1tGUaDLJ2Q%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%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hh5IT341AwjwYta3ohga2%2FOtsrBbFZeY%2FUklGjOy9tU%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.) > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
