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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 26 September 2018 22:26 UTC

Return-Path: <acee@cisco.com>
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 DBCDA130DCA; Wed, 26 Sep 2018 15:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.957
X-Spam-Level:
X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4plNUsIi2tWB; Wed, 26 Sep 2018 15:25:57 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B9130DC4; Wed, 26 Sep 2018 15:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5076; q=dns/txt; s=iport; t=1538000756; x=1539210356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uli1x464V+No4dMQzLqA2OplCN9uDQCGC0Vsre9+/+0=; b=UDnZsVLmkhnphnQCTXnq0dConQCqCiWxHbKuOPGQqlArE2OIFkvPDrKT i5gh2rR7A0DPoEb3yT+5BnG0ECEaxGRhWdDQpymiYsneh7PnX4ctpxlt+ 1G9TtUn1+dZu81t0lu0L9ViatRz6NJ3UVT2To8M6rSvIi5rn2mewo0kFc c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAApBqxb/4QNJK1aDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVKCDWV/KAqDapRFgg2DPZMSFIFmCyOESQIXg2YhNRc?= =?us-ascii?q?BAwEBAgEBAm0cDIU5AQUjETcOEAIBCBgCAiYCAgIwFRACBA4FgyEBggEPpAi?= =?us-ascii?q?BLoQzB4VZBYELiXAXggCBEQEnH4JMgxsCAQIBgSoBEgEfgwExgiYChiGCJ5Q?= =?us-ascii?q?/CQKGQYYYg1IXgUaEUokci3uIbwIRFIElHwE1ZFgRCHAVZQGCQYJNiEmFBDp?= =?us-ascii?q?vAYsRgR+BHgEB?=
X-IronPort-AV: E=Sophos;i="5.54,307,1534809600"; d="scan'208";a="454675439"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 22:25:55 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QMPtua001731 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 22:25:55 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 18:25:54 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 18:25:54 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)
Thread-Index: AQHUVeSQmU/MqB8OEEacqxWymQeyxqUDIMOAgABEsoD//76IAA==
Date: Wed, 26 Sep 2018 22:25:54 +0000
Message-ID: <B4852861-1A5B-4F21-B98C-7E56A9A5E642@cisco.com>
References: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com> <81633BAD-48C9-455B-9CF4-1DB6652E6BF5@cisco.com> <20180926222013.GT24695@kduck.kaduk.org>
In-Reply-To: <20180926222013.GT24695@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B70E737DE2D941499465AF91912C4111@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ETfyod-j_YqqTIo9blYIDtptX6o>
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:26:01 -0000

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.  

Thanks,
Acee 

    
    Thanks,
    
    Benjamin