Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 27 September 2018 18:32 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00B130EF9; Thu, 27 Sep 2018 11:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 scpwlLGwhdus; Thu, 27 Sep 2018 11:32:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC7C130F04; Thu, 27 Sep 2018 11:32:36 -0700 (PDT)
X-AuditID: 1209190e-4cdff700000068e3-5c-5bad224264b7
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 29.ED.26851.2422DAB5; Thu, 27 Sep 2018 14:32:35 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w8RIWTPr019576; Thu, 27 Sep 2018 14:32:30 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8RIWOJu000492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Sep 2018 14:32:27 -0400
Date: Thu, 27 Sep 2018 13:32:24 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>, Christian Hopps <chopps@chopps.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <20180927183224.GD24695@kduck.kaduk.org>
References: <153799837555.21625.17869101343542542632.idtracker@ietfa.amsl.com> <6685a165f91a47b59aecff7005884763@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6685a165f91a47b59aecff7005884763@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT13VWWhtt0LqCxeLGoQ1MFtM2H2S2 +LPWxmLDn43sFjP+TGS2WH/1JIvFiScrWB3YPe7dXczkMeX3RlaPnbPusnssWfKTKYAlissm JTUnsyy1SN8ugStj6cmDbAU9ihWb9r9kbWDslupi5OSQEDCRmPJ5OROILSSwmEni6Jb4LkYu IHsjo0Tnxt/MEM5VJon92w+zgFSxCKhK9Fzayg5iswmoSDR0XwYq4uAQETCSWPxcG6SeWeAM k8TLrc9ZQWqEBdIktt2fCGbzAm3rujiPEWJoJ6PE1U+fmCESghInZz4BW8AsoCVx499LJpCh zALSEsv/cYCEOQVcJf6s+sIIYosKKEvs7TvEPoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZ U5yarFucnJiXl1qka6yXm1mil5pSuokRFOqcknw7GCc1eB9iFOBgVOLh5XiwJlqINbGsuDL3 EKMkB5OSKK/C3tXRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR41aTWRgvxpiRWVqUW5cOkpDlY lMR5J7QsjhYSSE8sSc1OTS1ILYLJynBwKEnwHlAEahQsSk1PrUjLzClBSDNxcIIM5wEavhOk hre4IDG3ODMdIn+KUVFKnDcYJCEAksgozYPrBaUiiez9Na8YxYFeEea9pgBUxQNMY3Ddr4AG MwENFjmwBmRwSSJCSqqB8da9y0e5Zmgu4Ki7bfOpROS8UraI557jSQcrd2z8HM/Bd+bzAb+2 jzuvnBRY1/q4r7Ro/tTzU7zMtFZ/fywc8P7P7CDDlTznJdTyvjYbtopvPqn+8Effjmy9XU3i eWw/DoVmZpw7tkHv+ZcXpbcm9L4qXNVTtfT/1vr39hd0OCzfb3mppLy4/pkSS3FGoqEWc1Fx IgDXajtdIAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/azQ1lBOUJskanQVNbq3oA_HubLk>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 18:32:40 -0000

On Wed, Sep 26, 2018 at 11:09:10PM +0000, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> Responses inline.
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@mit.edu>;
> > Sent: Wednesday, September 26, 2018 2:46 PM
> > To: The IESG <iesg@ietf.org>;
> > Cc: draft-ietf-isis-segment-routing-msd@ietf.org; Christian Hopps
> > <chopps@chopps.org>;; aretana.ietf@gmail.com; lsr-chairs@ietf.org;
> > chopps@chopps.org; lsr@ietf.org
> > Subject: Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-
> > msd-17: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-isis-segment-routing-msd-17: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this introductory
> > paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > The shepherd writeup is silent about the WG's discussion of the IPR
> > disclosure (but the corresponding ospf draft says this sort of thing is typical
> > for LSR drafts).
> > 
> > Section 3
> > 
> >    The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
> >    223 to carry the MSD of the interface associated with the link.  MSD
> > 
> > Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers.
> > 
> [Les:] The document is an IS-IS document. Such a statement is therefore unnecessary.
> 
> >    MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
> >    represents lack of the ability to support SID stack of any depth; any
> >    other value represents that of the link.
> > 
> > It's unclear that there's a referent for "that of the link" to attach to.
> > That is, is it better to say "represents the maximum SID depth supported by
> > the link" (or similar)?
> > 
> [Les:] Would you be satisfied with the corresponding text in the OSPF document?
> 
> " any other value represents that of the particular link when used as an outgoing
>    interface."

That's better text (IMHO), but on a different axis.  I was thinking more
like "represents the MSD of the link".  However, my opinion doesn't have to
count for much here, so feel free to leave it as-is.

> > Section 6
> > 
> > As discussed in the secdir review, this section needs to include guidance to
> > the Experts to check that the meaning of the absence of an MSD type is
> > specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
> > attempts to place a similar requirement on future MSD types (but for OSPF
> > vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
> > appropriately general fashion so as to apply to all places where the registered
> > MSD value would be used.
> > 
> [Les:] I have answered this twice already. :-)

And  I have agreed to leave it to Alvaro :)

> > Section 7
> > 
> >    Advertisement of the additional information defined in this document
> >    that is false, e.g., an MSD that is incorrect, may result in a path
> >    computation failing, having a service unavailable, or calculation of
> >    a path that cannot be supported by the head-end (the node performing
> >    the imposition).
> > 
> > In the analogous OSPF document we split out the case of a value that is too
> > small and a value that is too large, to describe the different consequences.
> > 
> > I would also suggest rewording to something like "calculation by the head-
> > end of a path that cannot be supported" to avoid the mis-parsing
> > "(calculation of a path) (that cannot be supported by the head-end)".
> > 
> 
> [Les:] I will align w the equivalent OSPF text in the next revision.


Thanks!

-Benjamin