Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 22:29 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 A9D02130DCA; Wed, 26 Sep 2018 15:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 VapeXLf5j-QM; Wed, 26 Sep 2018 15:29:47 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 1BD43130DC4; Wed, 26 Sep 2018 15:29:46 -0700 (PDT)
X-AuditID: 1209190d-bc7ff70000006552-75-5bac085842cd
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.C6.25938.9580CAB5; Wed, 26 Sep 2018 18:29:45 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8QMTemB016075; Wed, 26 Sep 2018 18:29:41 -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 w8QMTaAL009726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 18:29:38 -0400
Date: Wed, 26 Sep 2018 17:29:35 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ospf-segment-routing-msd@ietf.org" <draft-ietf-ospf-segment-routing-msd@ietf.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: <20180926222935.GU24695@kduck.kaduk.org>
References: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com> <81633BAD-48C9-455B-9CF4-1DB6652E6BF5@cisco.com> <20180926222013.GT24695@kduck.kaduk.org> <B4852861-1A5B-4F21-B98C-7E56A9A5E642@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B4852861-1A5B-4F21-B98C-7E56A9A5E642@cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nohvJsSbaYNceM4vJb+cxW9w4tIHJ 4ujXPWwWM/5MZLZYf/Uki8WJJytYHdg8pvzeyOqxc9Zddo8lS34yBTBHcdmkpOZklqUW6dsl cGVcXD+RteC6XMX5T3fZGxh/i3YxcnBICJhIzFjr0sXIxSEksJhJ4uibF4wQzkZGiSUvtrBA OFeZJOad6mbrYuTkYBFQlfj/5ikriM0moCLR0H2ZGWSSiICmxJb3LCBhZoF5TBIvN7KD2MIC uRLHJp0Ba+UFWvZ94TaomfcYJfpWv2CHSAhKnJz5BKpZXeLPvEtgM5kFpCWW/+OACMtLNG+d zQxicwrYSpztOwbWKiqgLLG37xD7BEbBWUgmzUIyaRbCpFlIJi1gZFnFKJuSW6Wbm5iZU5ya rFucnJiXl1qka6SXm1mil5pSuokRFAeckrw7GP/d9TrEKMDBqMTDG7F+dbQQa2JZcWXuIUZJ DiYlUV6FvUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzrtgPleFMSK6tSi/JhUtIcLErivBNa FkcLCaQnlqRmp6YWpBbBZGU4OJQkeLvZ10QLCRalpqdWpGXmlCCkmTg4QYbzAA2fDlLDW1yQ mFucmQ6RP8WoKCXOuwUkIQCSyCjNg+sFpSmJ7P01rxjFgV4R5vUHqeIBpji47ldAg5mABk/o WQEyuCQRISXVwLi9f9bfOfNsw+SerY3eVL6b+RiT9N9j6SwzGHYbSy09Y5FoHRX1rfLIHK0f rxSlcvqal/3K+Lp+mc1VHXVV3nPSf3ao2qvNdQxvYc7heZzr+fknzzu7D3a2HEoen+WNdTyD lb4/2dkcdTzhlkNC0dtOtfnbCmb9k9ijVLVBq09fW+9UpSivmBJLcUaioRZzUXEiAKxUPFMu AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/W4GA8rIblLgA1cCad_StZ4-eqQs>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and 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: Wed, 26 Sep 2018 22:29:50 -0000

On Wed, Sep 26, 2018 at 10:25:54PM +0000, Acee Lindem (acee) wrote:
> Hi Ben, Authors,
> 
> ´╗┐On 9/26/18, 6:20 PM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:
> 
>     Hi Acee,
>     
>     On Wed, Sep 26, 2018 at 10:14:21PM +0000, Acee Lindem (acee) wrote:
>     > Hi Ben, 
>     > 
>     > On 9/26/18, 6:02 PM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:
>     > 
>     >     Benjamin Kaduk has entered the following ballot position for
>     >     draft-ietf-ospf-segment-routing-msd-21: Discuss
>     >     
>     >     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-ospf-segment-routing-msd/
>     >     
>     >     
>     >     
>     >     ----------------------------------------------------------------------
>     >     DISCUSS:
>     >     ----------------------------------------------------------------------
>     >     
>     >     This is essentially a process discuss, and hopefully easy to resolve.
>     >     
>     >     In Section 4, we say:
>     >     
>     >        The meaning of the absence of both Node and Link MSD advertisements
>     >        for a given MSD type is specific to the MSD type.  Generally it can
>     >        only be inferred that the advertising node does not support
>     >        advertisement of that MSD type.  However, in some cases the lack of
>     >        advertisement might imply that the functionality associated with the
>     >        MSD type is not supported.  The correct interpretation MUST be
>     >        specified when an MSD type is defined.
>     >     
>     >     I don't think we can make this sort of normative requirement on a registry
>     >     created by a different document, at least not without updating the registry
>     >     to also point to this document.
>     > 
>     > Would you be satisfied if the same text were in both the IS-IS and OSPF document? We really want a copy registry for IGPs (which are really only disseminating the information) to Segment Routing capable routers in the routing domain. 
>     
>     I think that depends on which text you're thinking about.  In particular, I
>     also asked for the IS-IS document to include in the IANA considerations
>     some guidance to the experts that the experts need to check this
>     requirement, and I'm not sure if that would result in just adding text to
>     the IANA considerations or also removing text from earlier in the document.
>     
>     On a slightly different note, we do occasionally have things like "[this
>     other document] placed some requirements on [foo].  Those requirements also
>     apply here, so we are copying the following paragraph from [this other
>     document] below for the convenience of the reader", and I could see a
>     copy+reference working here.
>     
>     So, if the other document enforces the normative requirement we need, but
>     we want to call attention to the requirement in this document as well,
>     copying the text with a note about where it came from should suffice.
> 
> I think this is the best path since we want the documents to be independent of one another even though they share the registry and semantics. If we'd have merged the OSPF and IS-IS WGs earlier, we'd have had a single document and have done so with the Flex Algorithm draft.  

Indeed, and sorry for having to toss a stumbling block in the works.

-Benjamin