Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-mpls-sr-label-type-11

[abstract, nit]

* "protocol used" -> "protocol is used", or "protocol is in use"
  (as in section 2)

Nice work on the shepherd writeup.

This was the only working group document on this week's IESG telechat, which is remarkable.  It can truly be said that it got thorough IESG review.

Thank you to Hilarie Orman for the SECDIR review.

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

(1) The SR labels can also be programmed by a PCE (rfc8664).  For completeness, it would be very nice if a codepoint was also allocated for that.

(2) The "Additional Information" field in the IPFIX Information Elements registry includes information about mplsTopLabelType that will now be incomplete -- it currently says:

   See [RFC3031] for the MPLS label structure. See [RFC4364] for the 
   association of MPLS labels with Virtual Private Networks (VPNs). 
   See [RFC4271] for BGP and BGP routing. See [RFC5036] for Label 
   Distribution Protocol (LDP). See the list of MPLS label types 
   assigned by IANA at [http://www.iana.org/assignments/mpls-label-values]. 

It would be nice to add information here about the new fields.

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.)