[mpls] Response to RtgDir review: draft-ietf-mpls-sfl-framework-06

[Stewart Bryant <[e-mail]>]

Dear Michael,

Thank you for your review.

New version just uploaded.

To: [e-mail] Cc: [e-mail], [e-mail], [e-mail] Subject: RtgDir review: draft-ietf-mpls-sfl-framework-06 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-sfl-framework Reviewer: Michael Richardson Review Date: 2020-01-05 IETF LC End Date: unknown Intended Status: Informational 


 Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. 

 Comments: This document is clearly written and easy to understand. I would have preferred to have a stronger link back to the requirements given in RFC8372.

SB> I think it meets all the requirements, so the Intro text includes no exceptions. Think this is fine. If there were exceptions then more text would be needed, but I don’t think that is necessary. If anyone can see text that needs to be added, I would be delighted to do so.


I see how no significant data-plane changes are required on intermediate routers. 

SB> Correct that is the intention, indeed the requirement.

 It would be nice to be sure that they are also minimized at the edges. 

SB> Again that was the intent. In terms of sending on the alternate label that just looks like another label to each end, so for many operations the change is zero. If we look at loss measurement as a good example routers often have a packet counter associated with a specific label value. In such cases there are no data plane changes, we are mapping the measurement onto existing common functionality. If we consider a more complex functions, then obviously there will a new action associated with the label value, that is in the nature of the beast. However if you think of an MPLS label as a vector to a previously defined function, that much of the data plane remains untouched. Obviously the forwarder will need the new function installed, but such change is inevitable with the introduction of new functionality.

 Are current OAM mechanisms able to obtain sufficient granalarity in latency to collect the right data? 

SB> The purpose of this method is to address the issue of forwarder performance by morphing the problem to one that can be readily addressed. If you look at the RFC6374 document draft-ietf-mpls-rfc6374-sfl-06 you can see the approach.

 Given that no IANA actions are required, and no mechanisms are described to collect the data, or allocate the SFLs, I understand why this is an Informational document. I don't see how it will contribute to better interoperation. Do we even need to publish this? 

SB> We split this the applications because the WG though that it was a technology in its own right with other potential applications beyond RFC6374. If we had put this the OAM text, then it would have needed to either unwound it from that text in pointing to it from another document, or it would have needed to be repeated. In the end we thought that it was cleaner to put it in its own RFC, and the given that the bulk of the text needs to be somewhere the incremental work was small.

 Major Issues: No major issues found 

 Minor Issues: section 3: "By some method outside the scope of this text, two labels" It seems that there might be significant operational and/or privacy issues with this assumption. It would be good if the reader had some idea of where to look for a protocol which would be easily adapted to this need. 

SB> I have added the line: One control protocol providing a method of exhanging SFLs  is described in
{{I-D.bryant-mpls-sfl-control}}.

 Nits: I think that starting the abstract with [RFCxxxx] may not be accepted by the RFC-editor. Maybe a single sentence summary is needed. 

SB> I have added its name in brackets.

- Stewart