[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) Author : Thomas Graf Filename: draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt Pages : 6 Date: 2021-09-08 Abstract: This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol used within a Segment Routing domain. In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for PCE, IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-mpls-sr-label-type-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Thomas, It seems that you just confirmed that I need new reading glasses :-( Let's ignore my comment then. Thank you for your reply Regards -éric -Original Message- From: Date: Thursday, 9 September 2021 at 06:31 To: Eric Vyncke , Cc: , , , Subject: RE: Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) Hi Eric, Thanks a lot for the review and the comment. I am not sure to which IE you are referring to. The first encounter in the document is in section 1 where it is expanded. In [RFC7012], the Information Element (IE) mplsTopLabelType(46) identifies which MPLS control plane protocol allocated the top-of- stack label in the MPLS label stack. Section 7.2 of [RFC7012] creates the "IPFIX MPLS label type (Value 46)" subregistry [IANA-IPFIX] where MPLS label type should be added. This document defines new code points to address typical use cases that are discussed in Section 2. Maybe I miss something. Thanks for a brief clarification. Best wishes Thomas -Original Message- From: Éric Vyncke via Datatracker Sent: Monday, September 6, 2021 3:26 PM To: The IESG 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: Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) Éric Vyncke 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.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H%2FOEEBHBT9YXhskb6u7s%2F%2FrdfdovIRAnO1ssAFeKZIk%3Dreserved=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%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TKJwqgsWY01S7KoP6t5nZuSewZzRL4Uq5jp1N8sIAdY%3Dreserved=0 -- COMMENT: -- Thank you for the work put into this document. I have only one suggestion: expand "IE" on the first use. Special thanks to Med Boucadair for his detailed shepherd's write-up notably about the WG consensus. I hope that this helps to improve the document, Regards, -éric ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
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=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 Sent: Wednesday, September 8, 2021 7:01 PM To: The IESG 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.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cqmEKyd5B0ZoBK0kTMNF1%2BnOFoyJ2%2FmyPNVRoLvEXTA%3Dreserved=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%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NRFVezr2O2J6IyAiXvlXm%2BdXFtZIyS1aM1tGUaDLJ2Q%3Dreserved=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"
Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Hi Eric, Thanks a lot for the review and the comment. I am not sure to which IE you are referring to. The first encounter in the document is in section 1 where it is expanded. In [RFC7012], the Information Element (IE) mplsTopLabelType(46) identifies which MPLS control plane protocol allocated the top-of- stack label in the MPLS label stack. Section 7.2 of [RFC7012] creates the "IPFIX MPLS label type (Value 46)" subregistry [IANA-IPFIX] where MPLS label type should be added. This document defines new code points to address typical use cases that are discussed in Section 2. Maybe I miss something. Thanks for a brief clarification. Best wishes Thomas -Original Message- From: Éric Vyncke via Datatracker Sent: Monday, September 6, 2021 3:26 PM To: The IESG 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: Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) Éric Vyncke 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.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H%2FOEEBHBT9YXhskb6u7s%2F%2FrdfdovIRAnO1ssAFeKZIk%3Dreserved=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%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TKJwqgsWY01S7KoP6t5nZuSewZzRL4Uq5jp1N8sIAdY%3Dreserved=0 -- COMMENT: -- Thank you for the work put into this document. I have only one suggestion: expand "IE" on the first use. Special thanks to Med Boucadair for his detailed shepherd's write-up notably about the WG consensus. I hope that this helps to improve the document, Regards, -éric smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] 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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/
--
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://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
.)
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
