Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

Alvaro Retana <aretana.ietf@gmail.com> Wed, 29 August 2018 16:53 UTC

Return-Path: <aretana.ietf@gmail.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 6F89D130E63; Wed, 29 Aug 2018 09:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eh9LVI7W1JT1; Wed, 29 Aug 2018 09:53:51 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E418D130DF2; Wed, 29 Aug 2018 09:53:50 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id 8-v6so10398639oip.0; Wed, 29 Aug 2018 09:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=B1JqwpPQt0kbbPCy/yZ6eYU8WPA97vX5M472NSM5FQ4=; b=UwRjfjBkhVmViYw5dyWX+f8tG9O5073Y+IMAu/1GC9RYQiiHwUtETdZ2MnIcPdgkfG Px+4o7gmHAya763BuFVX9flxr2PDWFaGU8kVN/5LBI6Bpz8PTVp8vLJYqsk6SVpFCUBj Ol4ZJdiK3Uja8Ut6a3KslT/qOhNz21VTqiwWEi6/Gvgs/uBIFoRZJIpEB8j5UUBQfajZ 72aLkwJLxPcwTZhbgtDXlfCN9ZRJIQXAKHeMkyjy6ZvTLBa6AsP2u+/+fXukUGJnAYwW 3gL1/XSYIF+GzH3XMEpjMP/nIzSb58PrFIXX0ooeH+y4AjkAEI9PReMMyTxUUsH97uNO 9Y+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=B1JqwpPQt0kbbPCy/yZ6eYU8WPA97vX5M472NSM5FQ4=; b=SNQtjHW0fDjR8kyiLsHBEZeZdU7m21zKkBEOdnsx5N+IiH6sPsXovcx2EL+MUIPhtb klwZNVlPVr9xZzkE/CavdUmYyda8HNEl4CKNAeDiMKlhWTSztWMb0m/8/2OiNpCjaGx2 EHgT0v/Prwqc1DVQ0cJMtFhvmtgK+PX9U4QJYhQtuQRPbvZaaEWFbdrdja6modD7q1Dp Ah4JnOpED8lksAy8EA3MHrjMco5zEzP/KeIolWW0QMDCPKPc5rxlyN52Eezq/9Opc0s5 DB8vkaW+wIH0Ho8GWi986ZA80krsHaOh0xtQNgw8RIFBf7R3sFvN9BbV6+q1ag3PJ5ra EETQ==
X-Gm-Message-State: APzg51DUFMqJun3td+Nv0FYtALzSjqdctzIxc9nM27gHBDzZlhsWPtNc 2Yd679rnt9xCpuHWfn6OQ3SteRolRtBvBYbjbXE=
X-Google-Smtp-Source: ANB0VdZMSeqmQGK4eRCJnARr093Om81RRUPF1egBnz1hCJlpp5o7hxWfvix5HkDZ4QtoR7j3tLHg1EmCQ9OMNS2XYNM=
X-Received: by 2002:aca:c0c1:: with SMTP id q184-v6mr3569750oif.61.1535561630168; Wed, 29 Aug 2018 09:53:50 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 29 Aug 2018 09:53:49 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <d2de842b864a4a7a98f646c748828fe6@XCH-ALN-001.cisco.com>
References: <CAMMESsxptarNYpLnNHA3mB+QBzb=RV0si1NNScPZdNJw4UyLog@mail.gmail.com> <d2de842b864a4a7a98f646c748828fe6@XCH-ALN-001.cisco.com>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Wed, 29 Aug 2018 09:53:49 -0700
Message-ID: <CAMMESswULKrB0Ge9GY04KT=E8=Avmat7VOoDHA5dvemac8itSg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.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>
Content-Type: multipart/alternative; boundary="0000000000007f3d2d057495cdcb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JC2bBPFNQZWWiToI_CK5A40Ijr8>
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 16:53:55 -0000

On August 15, 2018 at 6:51:39 PM, Les Ginsberg (ginsberg) (
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>
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.


..

...

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:] 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>].