Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT)

Jeff Tantsura <jefftant.ietf@gmail.com> Sat, 25 April 2020 22:37 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20CE3A0BF2; Sat, 25 Apr 2020 15:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 5smjR5_A3XVl; Sat, 25 Apr 2020 15:37:00 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 7CF743A0BF0; Sat, 25 Apr 2020 15:37:00 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id o15so6592758pgi.1; Sat, 25 Apr 2020 15:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=jfMSg7TwPbdbHLyPKGfiAU8C4ItUOQoJRIxInN+6RWM=; b=nLXW8eI0UCAP4GaaGHXUIiO+kDa7SKE+X7AokMqa+AwEb+9VS6c0KPNZ1IMXYm6Ocb b1E5E9W0VzlTY242ufcL5ZYm9CjMuTUvFSIqqrswltLPnV14taAndQIyHCp+ZID94nDV FqeWSaAfpD8Cl4Z0muoHf6BK2FN2GZ5POOWYFjf8x+dfG2XdAVpDqWTdwzUePhQ/9e+N 3r90oRRmjTGuq8eYG8LeoUK/EG1D71Xj8M2JUgPm2w2VVkrAdb8MrAbpCYzxjNcVD+Eh FSyafbSQZ0mQ6Z6Et5n/4H6qXr8zUKYb0dGM0F29Y978Sdg89DawoFCeNpEtybruabWV EV/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=jfMSg7TwPbdbHLyPKGfiAU8C4ItUOQoJRIxInN+6RWM=; b=fCojFkVR4p/NiUjbaeqTw+4eLtCCbTWHDtlL6rmFDxGq17Osm9HGbAwD+neHWK6T5v I6ctfSGpfZZvGU9udqS1zVb4WwY9PLqhkcy1yxpxU95bj8hWBz07OeQG+cTBOPm7L0Hn QDajulN3KZz/hJF3VkQTKNIw6r5H8N9ZirlGggNwRG9SU+S8CDHUK5vAwAs9AVETRtXW ++KD9EI0NyAN8859hh9TIhFZVDMqoPsLjr+rYbcgXhwYidwOM2f+nSfbTPMK7WpjPjYM djNUfQO0EPweLzKi5yKcj4XdkYicaqhSf06Q5Zw8HY7GG85wYETITWmzZVpv06v0gZok gC5w==
X-Gm-Message-State: AGi0PubmcAdkRjNbTCepSVIrl+NlsAl1uVqwBNsp5kjKUNDOVu4pEa1k HdUR67MRVvEM1Pq+1AlESPY=
X-Google-Smtp-Source: APiQypJwJpVz9pgGWa1U77WMf4RHu7jBN37cCbuHTt6X/AMowFgNDB7NID7PmchR2ks84HRDMQEFXg==
X-Received: by 2002:a62:cf06:: with SMTP id b6mr17484200pfg.9.1587854219924; Sat, 25 Apr 2020 15:36:59 -0700 (PDT)
Received: from [192.168.1.5] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id y186sm8706514pfy.66.2020.04.25.15.36.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 15:36:59 -0700 (PDT)
Date: Sat, 25 Apr 2020 15:36:52 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Martin Duke <martin.h.duke@gmail.com>
Cc: Martin Duke via Datatracker <noreply@ietf.org>, Susan Hares <shares@ndzh.com>, The IESG <iesg@ietf.org>, draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr@ietf.org, idr-chairs@ietf.org
Message-ID: <fa1723a1-87e7-4153-803f-a42b82f43abf@Spark>
In-Reply-To: <CAM4esxTYAXU=fR_=CA7HH--073ZfBZK1jh9e8R19RkZxYyNy0Q@mail.gmail.com>
References: <158774729288.14012.4297480673585471299@ietfa.amsl.com> <CAMMESsxX8kAwrYMfaevpxBg8VjmBx7Ds8iLgZAMX8MmvbumkaQ@mail.gmail.com> <CAM4esxTYAXU=fR_=CA7HH--073ZfBZK1jh9e8R19RkZxYyNy0Q@mail.gmail.com>
X-Readdle-Message-ID: fa1723a1-87e7-4153-803f-a42b82f43abf@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ea4bb89_501f9786_181f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs>
Subject: Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 22:37:03 -0000

Hi Martin,

Thanks for your comments.

Please note -  MSD value as such is opaque to the network carrying it and in no way influences routing decisions.
The end-goal is to provide this information to a controller that could use it to compute a path that could be instantiated on a node with particular HW contains.
In other words - the processing logic is really outside of IGP/BGP.

While RFC8491 has the following statement in the Node MSD section - "This value MUST represent the lowest value supported by any link configured for use by the advertising IS-IS instance”
it meant for the case where there is Node MSD only.

Later in the document, in the section "Procedures for Defining and Using Node and Link MSD Advertisements” it is stated:
"When Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD”
and that addresses exactly your use case.

To summarize:
it is allowed to advertise both, Node MSD and Link MSDs from the same node
it is upto the path computational logic to decide how to use these values

Hope this clarifies.

Many thanks and have a great weekend!

Cheers,
Jeff
On Apr 24, 2020, 12:16 PM -0700, Martin Duke <martin.h.duke@gmail.com>om>, wrote:
> Bummer! Thanks for the reply.
>
> > On Fri, Apr 24, 2020 at 11:55 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
> > > On April 24, 2020 at 12:54:53 PM, Martin Duke wrote:
> > >
> > >
> > > Martin:
> > >
> > > Hi!
> > >
> > >
> > > > This is not a DISCUSS-level concern, but I found it odd that the Node MSD TLV
> > > > must be the minimum of all configured interfaces without regard for the
> > > > presence of any Link MSD TLVs.
> > > >
> > > > For example, if all node interfaces have an MSD of 20 except one with an MSD
> > > > of 10, it would be much more compact to advertise a Node MSD of 20 and a
> > > > single Link MSD of 10. Section 5 says the Link MSD would take precedence, so
> > > > there would be no information loss. As I understand the spec, this would not
> > > > be allowed, and each link would have to be advertised separately to gain that
> > > > level of granularity.
> > > >
> > > > If this is not the intent, then in Section 3, extending a sentence to say
> > > > "Node MSD is the smallest MSD supported by the node on the set of interfaces
> > > > configured for use, [excepting links advertised with their own Link MSD TLV]"
> > > > would avoid the problem.
> > >
> > > This could have been a good optimization.
> > >
> > > However, this ship has sailed.  BGP-LS is a mechanism to carry
> > > topology related information to a central controller.  This
> > > information, as in this case, is obtained from the IGPs (OSPF or
> > > IS-IS).  IOW, BGP-LS is simply carrying the same information that
> > > IS-IS/OSPF generated...with the same semantics, which is what the
> > > controller is expecting.  The corresponding IGP specifications
> > > (rfc8491/rfc8476) contain the same language...if we change this
> > > document then we would have to change the IGP documents...and all the
> > > implementations. :-(
> > >
> > > Thanks!
> > >
> > > Alvaro.