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:14 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 45A10130DE7; Wed, 26 Sep 2018 15:14:26 -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 UYO5NTokWIuD; Wed, 26 Sep 2018 15:14:24 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A04130DD5; Wed, 26 Sep 2018 15:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5346; q=dns/txt; s=iport; t=1538000064; x=1539209664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IfiDRXvcyBtFsQzb0z2Tb3hbIOfsWiM5rVbfOh9SmD8=; b=kNaBiL/clh1BoZPrm2SpEKP3h5PH36/2GWhIzdfnTo3OG/x0wygUppD3 rKQKUyBRy6HamhzhSiMz5GKk8vdrR713tSVFk9nSiG8MbqsYea9MSr8SF 3b+omJsTw/eiRzeepZjj5SgBgVz4fMKpSoSUEbRnyN9/fR+L3i31Smwnj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAADOA6xb/4QNJK1aDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGBXy9lfygKg2qIFYwwhUqTEhSBZgoBI4RJAheDZiE?= =?us-ascii?q?0GAEDAQECAQECbRwMhTkGIxFFEAIBCBoCJgICAjAVEAIEAQ0FgyEBggEPpAe?= =?us-ascii?q?BLoQzB4VZBYELiXAXggCBEQEnH4JMgxsCAQIBgSoBEgGDIDGCJgKISJQ/CQK?= =?us-ascii?q?GQYlqF4FGhFKJHIt7iG8CERSBJR04ZFgRCHAVOyoBgkGCJRcRiEmFBDpvAQG?= =?us-ascii?q?LEIEfgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,307,1534809600"; d="scan'208";a="461019935"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 22:14:22 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QMEMPw026079 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 22:14:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 18:14:21 -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:14:21 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "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/MqB8OEEacqxWymQeyxqUDIMOA
Date: Wed, 26 Sep 2018 22:14:21 +0000
Message-ID: <81633BAD-48C9-455B-9CF4-1DB6652E6BF5@cisco.com>
References: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com>
In-Reply-To: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com>
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: <8ECC173B6BEF504B86BFDCA386B121EB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6Es_3WV00WXjF4YM7AoeaW-D8iw>
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:14:26 -0000

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. 

Thanks,
Acee
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Can SID be expanded on first usage --
    https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it
    as "well known".  (It also doesn't appear to list "Segment Identifier" as
    one of the expansions.)
    
    This is basically the same thing I said for the IS-IS document that creates
    the MSD types registry, but I'm not sure I followed correctly the meaning
    of MSD type 1 for SR-enabled vs.  non-SR-enabled networks.  In particular,
    I still don't really understand why it's okay to use the same codepoint for
    the max SID depth in SR-enabled networks and for the max label depth in
    non-SR MPLS networks.  Why couldn't they just be separate MSD Type
    codepoints?
    
    Section-by-section comments follow.
    
    Section 2
    
                      If the Node MSD TLV appears in multiple Router
       Information LSAs that have the same flooding scope, the Node MSD TLV
       in the Router Information (RI) LSA with the numerically smallest
       Instance ID MUST be used and subsequent instances of the Node MSD TLV
       MUST be ignored. [...]
    
    Unless there is a sorting requirement I've forgotten about, shouldn't this
    be "other" rather than "subsequent"?
    
    Section 6
    
    Thanks for the updates in response to the secdir review; they help a lot.
    
       If the value is larger than supported - instantiation of a path that
       can't be supported by the head-end (the node performing the SID
       imposition).
    
    This is supposed to mean "(instantiation by the head-end) of a (path that
    can't be supported)", not "instantiation of a path (that can't be supported
    by the head-end)", right?