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.
> 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. >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. > 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 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.)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
