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

Jeff Tantsura <> Thu, 07 May 2020 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04EB13A08E4; Wed, 6 May 2020 23:30:14 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lwByGeKodSrW; Wed, 6 May 2020 23:30:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 754A63A0062; Wed, 6 May 2020 23:30:11 -0700 (PDT)
Received: by with SMTP id ms17so2191629pjb.0; Wed, 06 May 2020 23:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=7TXQ3TmjU9YZiLVUrQOcDMnjiawfMYvhIFGTHFQtr4s=; b=IsMEGVzMoVqONCIY5kOUSRpmpm4Z+kyDlM5mgoftzf8F25fTVL9TSDSzDOBNZKELAN I3gsjaSyYyozW7Exmy4JHAMfWTUkzgRVAEs2gUSpgFcT8H0JLqg4rx0STAnPqEVHgD7x s200Nw97wIT/e/VkVDIzjmG+Nwx/RlTVzJBr6baghzXvp3TzWNfNkOTM0h5yXjAEoZj4 6mknSuGMZk4BS29gcfVh48yrC50Ru5tEjhulV/71O/w+g3zh2qIiuxPX1X8uZ1eyYBpw lVZUWShoF0+W+TFjZKRorutkzhJVZhbeVFFCe6/WDH1Lq6TEyOfW6OyUkzi1GE7eZav2 elHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=7TXQ3TmjU9YZiLVUrQOcDMnjiawfMYvhIFGTHFQtr4s=; b=gLROEtpNVuns96FRvyBjEOLREV/gBJUUQdzcLfCniNrAPlN2LCRwm+GKYHFlNLttvN I8m25cnWgymU0/gkAw1HAOz2Nq78qOOmR211IoUwic13WR41jv76OoR4eMTdHVkHxQwP qBGQkbAVuDa/c+92DYKBasgsIzL+dmyL2aH+ehxl3ZGf/Unk/KvXqzQzUHiEYlEeqWV2 Y5YSlqN+cHTeIJ7JRiDLeiJHmSVfpoilM4+qttQzLB1gKRIOxBsFSJppKApgHKezU1RV bq1xRozJ84Twpt2NW6HgbUhLW0sy1mdxQ0duR3SXkAnVi96/we6hsXEQU9vMLUTur4rs JOGw==
X-Gm-Message-State: AGi0PuZaMoiVPjSNx9rY7yViaswkOEPXqurr/TH64mPODtZzCwc+UhW/ ApfWBMjeVB+rEnfjFKRp8p+KYbys
X-Google-Smtp-Source: APiQypLkjbrwQ2neJbZZ6AaTvVR2pYicXQpH1eA98veK6zcbZn4sdre3LlZAaVxFxcsiuG5TbdK20A==
X-Received: by 2002:a17:902:c193:: with SMTP id d19mr12288843pld.60.1588833010858; Wed, 06 May 2020 23:30:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id l6sm3829295pfl.128.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 23:30:10 -0700 (PDT)
Date: Wed, 06 May 2020 23:30:03 -0700
From: Jeff Tantsura <>
To: Alvaro Retana <>, Benjamin Kaduk <>
Cc: Susan Hares <>,,, The IESG <>,
Message-ID: <592e681f-eadc-4d74-9825-2e221a06d523@Spark>
In-Reply-To: <>
References: <> <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark> <> <> <>
X-Readdle-Message-ID: 592e681f-eadc-4d74-9825-2e221a06d523@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5eb3aaf0_38a5d054_2480"
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: Thu, 07 May 2020 06:30:15 -0000

Hi Ben,

It seemed that having in RFC8491 and RFC8476 the following text:
"When Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD. If a Link MSD-Type is not signaled, but the Node MSD-Type is, then the Node MSD-Type value MUST be considered to be the MSD value for that link.”, as well as placing "Node MSD is the smallest MSD supported” specifically in the Node MSD section,
e.g. - applicable in context of Node MSD only, provided clear guidance to the implementors (which is the case).
There’s a number of implementations that implement the behavior as the above, the authors of RFC8491 and RFC8476 have not received any questions or complains wrt inconsistency.

I really appreciate your comments, I believe we have a different intepretation of the text.

Many thanks!

On May 6, 2020, 2:33 PM -0700, Benjamin Kaduk <>, wrote:
> On Wed, May 06, 2020 at 02:22:45PM -0700, Alvaro Retana wrote:
> > On May 6, 2020 at 1:56:07 PM, Benjamin Kaduk wrote:
> >
> >
> > Ben:
> >
> > Hi!
> >
> > ...
> > > 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.
> That's what I expect, yes.
> But right now the document seems to be inconsistent, as the Node MSD is
> claimed to be "the smallest MSD supported" but can be other values.
> > 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).
> So the published documents are also inconsistent?
> It still looks like we are defining usage of a field that contradicts what
> that field is defined to carry. I am not sure whether the contradiction is
> across documents, within multiple documents, or only within this current
> document.
> If we're locked into the already-defined semantics that's fine (albeit
> unfortunate), but we shouldn't then claim that it's allowed to violate the
> already-defined semantics.
> -Ben