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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 03 June 2020 15:16 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819D23A0D06; Wed, 3 Jun 2020 08:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDVrebxK78mJ; Wed, 3 Jun 2020 08:16:31 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9F43A0CE9; Wed, 3 Jun 2020 08:16:22 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id x13so2790798wrv.4; Wed, 03 Jun 2020 08:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=DuQTz1eRkfEt/gU2SJ0hzSC+uS7Wa57CF/wg/DZFOn0=; b=i5RKJqXfwDeKd1fM1eVSG6i/gf/Pz2eGt08Zq26JtL16imPiJmhrMETtwdYH6Bb3S/ lAG3lKuiWpLITmpzijFrqP3mizIeqWlGxvImEnHKcAEMH8cOTorzxz6bUNgCI408YljT uDvWsnP+vge7dek7x95T90e+3v5+f1CdVoQY6j3arxZDpWWvvQsT2KcXCzOqmzMR/ZOD VG5WHNFOFgPa+6tOZkVM/i+ois7QnGrArK1oheZ42dvKfUWEYOlUUlRbiVXGO8SGCl+3 gQk4xC/pN/cxs2XZsh/EQSg8J6onTNaTut6I4urWhpOnv31GJRxPhha0IT7GTfD9VtBq FUww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=DuQTz1eRkfEt/gU2SJ0hzSC+uS7Wa57CF/wg/DZFOn0=; b=l/++oganBTu1yBFcFFnZOxHJGOIYbVB5g4rXrq3vFfT9GtnlpLN0HW/wAmvi5WdFHt /rKIzCPWGM+tSHr8hTsC9Fk3hgvf4a3YwE+UgB3YZsXceQ9AX9pnv3BbLkxnbmHp/b9i yEPW/XGcfhjQClg2NV/ulnP1i/4YRLxSZ0lv0OQ+KJ/Yx8+hmOhkibJrdBoEFDM5KsxZ TQ5cQQDWAFFB/vt5wj5a9ZO179dr+Mx6xTZfLjSje0l89eJF6+FuzGilwrafb3o3A5xs rP59OFCADBMkcZAyzpjlr9mfqq4t3YtWGyKP7WAJCtWCGrqOx75iDWqxfbJfEM4BHU1s IJ1Q==
X-Gm-Message-State: AOAM530qHhhPI9SPE/g1mhLY6DEmk+2OOF+kkgzZhoycTsvWhXp66lp6 UKq4n/YNAV8+AI4NEZIEXHjuOIxVksI=
X-Google-Smtp-Source: ABdhPJx3UJ+Wd0fO5jtiqPu/Wfj7JLZ3hm+ItXhNPpB444HYs6h/07mBebgnv13ton3NlNSbDmRQ1Q==
X-Received: by 2002:a5d:604b:: with SMTP id j11mr31231423wrt.193.1591197380179; Wed, 03 Jun 2020 08:16:20 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id h27sm4720364wrb.18.2020.06.03.08.16.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 08:16:19 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <D492FEC5-421A-4E22-BF35-D5BA562C0961@gmail.com>
Date: Wed, 3 Jun 2020 16:16:18 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, rtg-dir@ietf.org, draft-ietf-mpls-sfl-framework.all@ietf.org, mpls <mpls@ietf.org>
To: rtg-ads@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/H7s-MAz9oMUQ4RkcBcMLAYwqDk4>
Subject: [mpls] Response to RtgDir review: draft-ietf-mpls-sfl-framework-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 15:16:40 -0000

Dear Michael,

Thank you for your review.

New version just uploaded.

To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-mpls-sfl-framework.all@ietf.org, mpls@ietf.org 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