Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 29 August 2018 23:49 UTC
Return-Path: <ginsberg@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 330ED130DC8; Wed, 29 Aug 2018 16:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 zswdqiBSbRFq; Wed, 29 Aug 2018 16:49:54 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC20130DF4; Wed, 29 Aug 2018 16:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47378; q=dns/txt; s=iport; t=1535586593; x=1536796193; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o1pt/HYw+jtc5VrYNtFJclrjsCo0i5iaaRdqFFwE23w=; b=XsBoUSAN5Xq6hfenpJxDVQmOa42C9Tli5+Yr2a8ccukmWjOscXUlwN79 wiT/jHhastzlqw5cNahre/znuA4Cw+ftOyKhrf1Z0KacnyGyQ7PMWc2sD q0xwcPKb2gzTZ0J4Qtrf7UKj22PQSeqJ0bWMxndnpDK85wcK1gkxfPouv M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbAABxMIdb/5pdJa1ZGQEBAQEBAQEBAQEBAQcBAQEBAYJXeGV/KAqDaIgRjCqCDYhVjVOBegsfhE0CF4J0ITQYAQIBAQIBAQJtHAyFNwEBAQQjCj4OEAIBBgIOAwQBASEBBgMCAgIfERQJCAIEAQ0FCIMagR1MAxUPiEebS4Euhy4NgkkFihAXgUE/gREBgxKCVkUBAQOCBBCCS4JXAodwhSGFU4gqKwkChjGGMIMIH4E/hDSIXosjZIcqAhEUgSQdOIFScBWDJIsVhT5vi0yBHAEB
X-IronPort-AV: E=Sophos;i="5.53,305,1531785600"; d="scan'208,217";a="163917033"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2018 23:49:52 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w7TNnqdu015272 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2018 23:49:52 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Aug 2018 18:49:51 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1367.000; Wed, 29 Aug 2018 18:49:51 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Thread-Topic: AD Review of draft-ietf-isis-segment-routing-msd-13
Thread-Index: AQHUNNoQmHI5FO69m0uobgW9g1VMU6TBXRPAgBX+wYCAAB/yoA==
Date: Wed, 29 Aug 2018 23:49:51 +0000
Message-ID: <5e94badb2dd34848ba5afb5d4ce1480b@XCH-ALN-001.cisco.com>
References: <CAMMESsxptarNYpLnNHA3mB+QBzb=RV0si1NNScPZdNJw4UyLog@mail.gmail.com> <d2de842b864a4a7a98f646c748828fe6@XCH-ALN-001.cisco.com> <CAMMESswULKrB0Ge9GY04KT=E8=Avmat7VOoDHA5dvemac8itSg@mail.gmail.com>
In-Reply-To: <CAMMESswULKrB0Ge9GY04KT=E8=Avmat7VOoDHA5dvemac8itSg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.73.246]
Content-Type: multipart/alternative; boundary="_000_5e94badb2dd34848ba5afb5d4ce1480bXCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MG9Je68B_LQYL3m3FHj6lYe2B6M>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
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, 29 Aug 2018 23:49:56 -0000
Alvaro – I have posted V15 addressing your comments. Responses inline. From: Alvaro Retana <aretana.ietf@gmail.com> Sent: Wednesday, August 29, 2018 9:54 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; draft-ietf-isis-segment-routing-msd@ietf.org Cc: lsr@ietf.org; Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13 On August 15, 2018 at 6:51:39 PM, Les Ginsberg (ginsberg) (ginsberg@cisco.com<mailto:ginsberg@cisco.com>) wrote: Les: Hi! You and I had an off-line conversation about the topic of multiple advertisements. I’m replying with similar comments to close the loop with everyone else. There are also a couple more comments after that. Thanks! Alvaro. From: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>> Sent: Wednesday, August 15, 2018 1:53 PM ... ... 191 If there exist multiple Node MSD advertisements for the same MSD-Type 192 originated by the same router, the procedures defined in [RFC7981] 193 apply. [major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a node MSD sub-TLV), or both? [Les:] It really doesn’t matter. If you have two advertisements for the same MSD type from the same source then the procedures defined in RFC 7981 apply. It does not matter whether you find the advertisements in the same sub-TLV, in the same Router Capabilities TLV but different sub-TLVs, or in different Router Capabilities TLVs(sic). [major] The only relevant text I can find in rfc7981 is this: Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined. [Les:] Your searching skills are excellent. J RFC 7981 declined to define procedures for reasons which are explained in the three paragraphs prior to the one you have quoted. If you have a problem with that please raise it in the context of RFC 7981 – not in the context of this draft. I then don't know how to handle the multiple advertisements. Please point me in the right direction. ... 235 If multiple Link MSD advertisements for the same MSD Type and the 236 same link are received, the procedure used to select which copy is 237 used is undefined. [major] Does this text refer to multiple link MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a link MSD sub-TLV), or both? [Les:] As with node MSD, it does not matter. What matters is that you have duplicate advertisements for the same link and MSD type. Ohhh…and these advertisements are not in Router Capability TLV. J [major] Without a procedure "it is unlikely that multiple implementations of the specification would interoperate" [2]. [Les:] The issue is not interoperability but that you do not know which one is correct. So no matter which one you choose you might use a value that is either not supported by the advertising node or limits label imposition unnecessarily. I really don’t think there is an interoperability issue here. For the application in this document, I agree that there is really not an interoperability issue. I will leave it up to you if you want to add any text to (potentially) avoid related questions in the future — or we can wait for the questions, either way is fine with me. [Les:] I added some text. .. ... 258 5. Base MPLS Imposition MSD 260 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 261 labels a node is capable of imposing, including all 262 service/transport/special labels. 264 Absence of BMI-MSD advertisements indicates solely that the 265 advertising node does not support advertisement of this capability. [major] The MSD Types are applicable for both nodes and links, right? The description above only talks about nodes -- what about links? [Les:] This section is not specific to link advertisements or node advertisements. It is talking about what it means when there is no applicable advertisement of BMI-MSD. I think that the confusing part is that text says that the BMI-MSD is "the total number of MPLS labels **a node** is capable of imposing” — emphasis on node. Note that the definitions in §1.1 (Terminology) are not specific to links or nodes. For example, the BMI is defined as "the number of MPLS labels which can be imposed”, with no specific reference to nodes or links…and the MSD as "the number of SIDs a node or a link on a node”…. Suggestion: NEW> Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels which can be imposed in a node or link, including all service/transport/special labels. [Les:] I modified the definition to be the same as in Section 1.1. ... [Les:] Guidance for Designated Experts – at least for IS-IS codepoints – has been defined in RFC 7170. Would it be sufficient to refer to that document and state that it applies in this case as well?? (I sure hope so. J ) rfc7370 provides guidance that "applies specifically to the "IS-IS TLV Codepoints” registry”, and it focuses on early allocation. Even though the guidance is general... :-( My intent with asking for guidance was mostly to get you to think about any specific things that a DE should consider for MSD types. If there is nothing specific, then I just have one suggestion for the text you added in -14: OLD> Guidance for the Designated Experts is as defined in [RFC7370<https://tools.ietf.org/html/rfc7370>] NEW> General guidance for Designated Experts is provided in [RFC7370<https://tools.ietf.org/html/rfc7370>]. [Les:] Done. Thanx. Les
- [Lsr] AD Review of draft-ietf-isis-segment-routin… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Jeff Tantsura
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-isis-segment-ro… Alvaro Retana