Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)

Alvaro Retana <> Wed, 06 May 2020 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 613F13A0B63; Wed, 6 May 2020 14:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L4X7coWp2MnL; Wed, 6 May 2020 14:22:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 294273A0B65; Wed, 6 May 2020 14:22:48 -0700 (PDT)
Received: by with SMTP id r26so4386012wmh.0; Wed, 06 May 2020 14:22:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=J+mnyqnfK/rUXMV6Bi7sdgDmNjdiFgqtfd/08HZccbw=; b=UDqX8MnmFdKP1/lzCVoScuFr5ySoTSw//ZIzrkd00G7AQ4J39k7CJHvqfdNO4o3X4r GlGMKMj/e7cuBgxJraAxYdY9gPXQijS+q4Otpg4+AmglG7pvRvgjhfTpd5wb9emeZiBx pidBkvgVwPD3dhHSvOVQ+0OkdmgU+CWvawsU8wZNnDj5H/ewciS5F8qoN1nZ5/y2wpo+ LuOwxinfSw7gL5ZBJqT/51OY5oIRBFQoLKd8fbAlFgXC5MpyyqsJi3ST1Dg6Awjn6W49 UnyAt3QGl/wo3MPowUZQay125sT2Qn2u9EUtLfS9kHGkhi7ljQuf3sDp18gaq9gyafRl aCjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=J+mnyqnfK/rUXMV6Bi7sdgDmNjdiFgqtfd/08HZccbw=; b=mozxKDrLbYLRsh4qdl/yp6WGzTuJZCr+ZFfX5jFmnhHY+B/vEeRkC9jeqmpQrAKnQ/ wflxviSm/1qlmXMHrkyaLQ2Q621oOlp4pccjgdHsts1hvTXiNUTHkHZtlQnJtQy7YQQM c1qjMpibjq86nJqehde4SaRlzzaM+8IKOzH2f37JT1RBTfsgGakQmOcDpdIk0rUdBPm+ eaLZPqOe4/scQVKG1X/zbgmRZjwrMb9uf2LMLVoaN04Fcvgi4rEjftA/52d+yb6rq2Qw Z0ISvqbQup60Scm0/ofT+zmCwiw9IfIwE9oetuEeSkgh1u3VG4mFcGm6pmq6nJPstTHu obDQ==
X-Gm-Message-State: AGi0PuYjW+Z32ndcL7oprznCDz37bv5dyFgcogvptIFzsGLnmCdT4GOg MxGV7yrANBOYKPsCgOUJt9dN4siikr1Si5uYUgE=
X-Google-Smtp-Source: APiQypJVo8MARpyEu58mmTIz88MD0nxrcbOCaqlPKmDkxUtL2cgXj7IcQGhDkQKNHWhojaPcTzKv89RmsPkok673eg8=
X-Received: by 2002:a7b:c755:: with SMTP id w21mr6423136wmk.120.1588800166529; Wed, 06 May 2020 14:22:46 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 6 May 2020 14:22:45 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark> <>
MIME-Version: 1.0
Date: Wed, 06 May 2020 14:22:45 -0700
Message-ID: <>
To: Benjamin Kaduk <>, Jeff Tantsura <>
Cc: Susan Hares <>,,, The IESG <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 May 2020 21:22:57 -0000

On May 6, 2020 at 1:56:07 PM, Benjamin Kaduk wrote:



> It sounds like you are intending this to work the way that I was hoping it
> would work, which is reassuring. That said (and this relates to a later
> comment as well), I think we may want to double-check the wording in one
> spot: in Section 3 we define the "Node MSD is the smallest MSD supported by
> the node on the set of interfaces configured for use." This definition
> seems to disallow advertising a Node MSD that is larger than any specific
> Link MSD for that node. My question here was about whether a receiving
> node was expected to enforce this (surprising) aspect of the definition.
> If, instead, the definition should be changed to say only that the Node MSD
> is the MSD to be used for interfaces on this node in the absence of an
> interface-specific value, then there is no longer any enforcement needed.

§5 does say this: "When Link MSD is present for a given MSD-type, the
value of the Link MSD MUST take precedence over the Node MSD."

Is that what you're looking for.

Keep in mind that the expectation of BGP-LS is to simply transport
information; the rules around that information and how the consumer
should process it come form the IGP documents.  IOW, in this case
we're bound by what those published documents already say (see RFC8491
and RFC8476).