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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 04 May 2020 22:38 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 761563A123E; Mon, 4 May 2020 15:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 NQ3vfLfdlTJB; Mon, 4 May 2020 15:38:36 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4B4533A0A78; Mon, 4 May 2020 15:38:36 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id s20so374466plp.6; Mon, 04 May 2020 15:38:36 -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=+8mjjlN6UYi4vJ84UvwBXTagYv5q6zCD0hVOP6sxw3Y=; b=UjKO4MldzIA6yKRiC1kOurs9u8Rwv9VwBfYnUd8KfwPSKWWHMvZUFZ5JFvF27iZ2Bv rnqWABMBHTfSiuEEHmX3+5cp3H7LNaEHOD7tDaDxCVxTQQHfBRDr93cKc5l7176GR89k /3tu0mUyEy+f9k0oBNiwCFjuutDalJE8BEujF4fRugj5HDJZwh39zJh1UUqGsv6eHoih +fT0I8hB4VKD5b9dXKmRAYBorxPPxnkbE0/ed3+1zbm53yGJZCMqTyOAajPlG13QY5sx U00x8CWyAt4he/n1tqtarFsS0pxXlBMp01kWLDRckA5+oE/s5hEPse9gVPr6Mqu/2Z2X F2ww==
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=+8mjjlN6UYi4vJ84UvwBXTagYv5q6zCD0hVOP6sxw3Y=; b=B+qT/htf4DLIE4DTjC/gXlQismDh//N6LZKpVChtteYlkxoBMZiXQKIlLy8gL+WO+P NzxEnpCNK63czrtqo/6i10ZZJpfJZmnHkJnE1Urgr3dvGCo4Kh/hnGS4JA8wQdt7M1B7 V7UaCavdfv8YRfPvfxNZeTipTwF+PpNyPK4VRLqpAHMCyo0+GUCFpPMwbqQYOPTeC+/E mqLkD8Y6+wmbqoJ8Vsh9I0IfmpYeXd/B2oLB8MJclfPl3P3ZEYL3UCzMnZWCvBLX3T60 X/VA8Erg6eR3OiHDPRfH9vWZn3xnAFhh8DOBk2BF/pnU+ni4OEsrJukha6tpWGzH/Hoz JzBA==
X-Gm-Message-State: AGi0PuZxxm3+7Egszp1yINVcyWEAxnEHFmwSVkObgFRnqXOVBvLVAbgA ItuM9Bl+OT2XmLQXPNwZOeS+ryOp
X-Google-Smtp-Source: APiQypJy0UEP5WIJIHE7ZQw24TL172NiCrhA7zpug1TYpCtHMITDj4k17L9qpju16PgTGRs8tw2AiQ==
X-Received: by 2002:a17:90a:df15:: with SMTP id gp21mr9609pjb.2.1588631915090; Mon, 04 May 2020 15:38:35 -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 t188sm104114pgc.3.2020.05.04.15.38.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 15:38:34 -0700 (PDT)
Date: Mon, 4 May 2020 15:38:24 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com
Message-ID: <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark>
In-Reply-To: <158862918074.23288.8494237048042781894@ietfa.amsl.com>
References: <158862918074.23288.8494237048042781894@ietfa.amsl.com>
X-Readdle-Message-ID: 7534cbdd-a370-4d40-b49e-a30158d46a44@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5eb09966_3fa62aca_2480"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bCLXpW70IDQiDuCL7cmEELPdl_4>
Subject: Re: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (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: Mon, 04 May 2020 22:38:39 -0000

Hi Ben,

Many thanks for your comments!
Please see inline

Cheers,
Jeff
On May 4, 2020, 2:53 PM -0700, Benjamin Kaduk via Datatracker <noreply@ietf.org>rg>, wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-idr-bgp-ls-segment-routing-msd-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Not a whole lot of interesting comments on this one; it seems like a
> pretty straightforward codepoint allocation with relevant (security and
> other) considerations covered in other documents. I do appreciate the
> discussion in the security considerations section; it looks good.
> [jeff] thank you!
>
> This document talks about the MSD as being the depth of a stack that a
> given node can "impose". Is there a similar consideration (or protocol
> element) for what a given node can read/process? (I think I remember
> such a document going by, but don't have enough keywords to search for
> it efficiently.)
>
> [jeff] The drafts talking about Readable Label Stack Deepth Capability (RLSDC) are
> draft-ietf-isis-mpls-elc/draft-ietf-ospf-mpls-elc (subcase in RFC8662)
>
> Is there a specific error-handling behavior to use when a Node MSD TLV
> is received with a value larger than the value of a Link MSD TLV
> associated with that node (for the same MSD-type)? Is that one of the
> things "left to the consumer of the BGP-LS information" by Sectoin 7?
>
> [jeff] the rule is that most specific (Link MSD) always wins,
> e.g if there’s a Node MSD of 5 and Link MSD of 3 for interface-3 and a router with 3 interfaces -
> interface-1 and interface-2 will use the value signaled through Node MSD (5), while interface-3 would use the value from Link MSD
> In general - the logic is indeed left to the consumer of this information. Advertising different values in Node and Link MSD is not an error.
>
>
> Section 1
>
> In the future, it is expected that new MSD-Types will be defined to
> signal additional capabilities, e.g., ELs, SIDs that can be imposed
> through recirculation, or SIDs associated with another data plane
> such as IPv6. MSD advertisements may be useful even if SR itself is
> not enabled. For example, in a non-SR MPLS network, MSD defines the
> maximum label depth.
>
> It's slightly interesting that we still call it "MSD" even though there
> are potential uses in a broader scope. Perhaps just a historical legacy
> and we need to remain consistent with the name in common use...
> Though, perhaps the terminology section in this document does not need
> to be quite so constrained by the past.
>
> [jeff] we have adopted all new use cases to refer to MSD, so far works OK.
> Indeed, there’s quite some history
>
> Section 3
>
> identified by the corresponding Router-ID. Node MSD is the smallest
> MSD supported by the node on the set of interfaces configured for
> use. MSD values may be learned via a hardware API or may be
>
> It is a shame that the semantics are already locked in (as was noted by
> a previous review that I can't find right now?) and the efficient
> encoding of "large per-node value with smaller per-link values for
> exceptions" is not admissible.
>
> [jeff] please see my response to Martin - https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/
>
> Section 5
>
> MSD-type is not supported. The correct interpretation MUST be
> specified when an MSD-type is defined in [RFC8491].
>
> Is this "is defined in the registry defined in [RFC8491]" or "is defined
> according to the procedures in [RFC8491]" or something else? The
> current text doesn't scan properly, as it implies that a future new
> MSD-type will be defined in RFC 8491, an immutable document.
>
> [jeff] This doesn’t read correct, thanks!
> RFC8491 states: "The correct interpretation MUST be specified when an MSD-Type is defined"
> The correct interpretation MUST be specified when an MSD-type is defined, as described in [RFC8491] seems like a better text, would that be OK?
>
>
> Section 7
>
> Specifically, the malformed attribute tests for syntactic checks in
> the Fault Management section of [RFC7752] now encompass the new BGP-
> LS Attribute TLVs defined in this document. [...]
>
> Interestingly, the referenced section of 7752 does not seem to
> explicitly say that other invariant properties of TLV lengths (e.g.,
> that they must be a multiple of 2 as for the ones defined by this
> document) should be checked.
>
> [jeff] RFC7752 is being updated as we speak (draft-ietf-idr-rfc7752bis), would a good addition.
> IDR WG is CCed in this email.
>
> [RFC7752]. The MSD information introduced in BGP-LS by this
> specification, may be used by BGP-LS consumer applications like a SR
> path computation engine (PCE) to learn the SR SID stack handling
>
> https://www.rfc-editor.org/materials/abbrev.expansion.txt lists "PCE" as
> having a well-known expansion to "Path Computation Element" (not
> "engine") that can be used directly in abbreviated form without any
> expansion given.
>
> [jeff]ack, this is a typo, thanks and changed
>
> Section 8
>
> issues when propagating the TLVs into BGP-LS. The advertisement of
> the node and link attribute information defined in this document
> presents no additional risk beyond that associated with the existing
> node and link attribute information already supported in [RFC7752].
>
> I'd suggest hedging to "no significant additional risk", though I do not
> have an example of additional marginal risk at hand.
> [jeff] ack, added
>
>
>