Re: [spring] review of draft-tgraf-ipfix-mpls-sr-label-type-01

["Aitken, Paul" <[e-mail]>]

Thomas,

I've highlighted lots of small changes, with other comments inline:


Abstract:

   This document introduces additional code points in the mplsTopLabelType IPFIX
   Information Element for IS-IS, OSPFv2, and OSPFv3 MPLS Segment
   Routing (SR) extensions, and a new SID type Information Element to enable Segment
   Routing label and segment type information in IP Flow Information
   Export (IPFIX).


1.  Introduction

   Besides existing MPLS control plane protocols such as BGP-4
   [RFC8277], LDP [RFC5036] and BGP VPN [RFC4364], three new routing-
   protocols, OSPFv2 Extensions [RFC8665], OSPFv3 Extensions [RFC8666]
   and IS-IS Extensions [RFC8667] have been added <where?> to propagate Segment
   Routing labels for the MPLS dataplane [RFC8660].

   Traffic Accounting in Segment Routing Networks
   [I-D.ali-spring-sr-traffic-accounting] describes how IPFIX can be
   leveraged to account traffic to MPLS-SR label dimensions within a
   Segment Routing domain.

I preferred that MPLS-SR was spelled out as "MPLS Segment Routing", especially for those of use who aren't familiar with the terminology. Else, add an xref to wherever MPLS-SR is defined?


2.  MPLS Segment Routing Top Label Type

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF.  By looking at the MPLS label value
   itself, it is not always clear as to which label protocol it belongs,
   since they could potentially share the same label allocation range.
   This is the case for IGP-Adjacency SID's and LDP as an example.

There's a lot of terminology in the this paragraph. Perhaps the reader isn't familiar with LDP, SID. Consider adding a note at the end of section 1, "MPLS specific terminology used in this document is defined in <some RFC>".


3.  Segment Routing Segment Identifier Type

   By introducing a new Information Element called SrSidType, which
   contains the Segment Routing Segment Identifier type according to
   Segment Routing Architecture [RFC8402], we get the intended Segment
   Routing forwarding behaviour in the forwarding plane.

This suggests that the forwarding behaviour is dependent on the Information Element. Consider, "allows the Segment Routing forwarding behaviour to be exported in IPFIX" ?


Figure 2

  Description: This field identifies the Segment Routing Identifier Type of the top-of-stack.


Consider, "MPLS top-of-stack label", or similar - else there's nothing to constrain this to MPLS.


Figure 3

Consider reserving the zero value for "Unknown", for use when the SID type cannot be determined and for cases where the a flow record containing a SrSidType field is used for non MPLS traffic.


7.2.  Informative References

Note that this draft would be blocked until all the I-Ds become RFCs since it couldn't be published while citing WIP docs.


Check the nits:


  == The document doesn't use any RFC 2119 keywords, yet has text resembling
     RFC 2119 boilerplate text.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPFIX-IE46'

  ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012)

P.