Hi Paul, Thanks a lot for the detailed feedback. This is greatly appreciated. All reviewed, understood and input implemented for the next version.
Best Wishes
Thomas
From: Aitken, Paul <paul.ait...@intl.att.com>
Sent: Monday, March 30, 2020 11:07 PM
To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com>
Cc: bruno.decra...@orange.com; spring@ietf.org; martin.vigour...@nokia.com
Subject: Re: review of draft-tgraf-ipfix-mpls-sr-label-type-01
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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
