Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09

Jeff Tantsura <jefftant.ietf@gmail.com> Sat, 29 February 2020 01:17 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 66D753A0874; Fri, 28 Feb 2020 17:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 URsMZElCzite; Fri, 28 Feb 2020 17:17:43 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 6A2E13A0873; Fri, 28 Feb 2020 17:17:43 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id y8so1889343pll.13; Fri, 28 Feb 2020 17:17:43 -0800 (PST)
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=ZWvq+jFdsnea//mUxKbLZNpeXJnmoS8lJOBYwQglqtU=; b=XEfXS1PcWzMV++/LVphp2meMm8V5EICOdD09PWk7iWLzyABDfG1ezpnbyjp+tjlxv3 Q0bOLqvXPlxHqnD2SWe+8CCITBTbD8JW6yHA7Yhtmn5TB7fTiKsoUNN023pGbxu959rI Q+z89Wua6dzXjsvet9fS+yTaOqmXf9h3jSMo1Yfq3FX0sr1s7YBToD0J3sfnrYx/g3ny MvYZX5mF88pZMdLIUHJr0RL7LcSwyraaAxNo7fRmpnbvj0qj+k48mJ2yWBNhPhMyUGGg fcw5rAVj58lOj9vz0twbzbMtSq2PoIFuoWLEZ8p6d0nbV9R/IDjfwZ6TXQK4kQg656KG Wb9Q==
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=ZWvq+jFdsnea//mUxKbLZNpeXJnmoS8lJOBYwQglqtU=; b=kzXzP8blNGrQGomfzbGi1v1hetyMYzjc/K3TTy4VTIPP9QJVf785Ka8JEU9u8XniNd giCP+Nn12kLa5lv4wdfG5NcGMgLJOqyfS5Mb760hqiIO8eQcq0lBG9q413Ff2GKsC2hf Vifgl0uh0ks+dp96KeheL5xkiANktk8nB63z3qKoU2pdoiA7MhaIoEUUJit9USi+EyuA agWwbtNH037pWwbl7R6h6WgIiXaAbl78CPpoUhj46RLdBLu53X5L0roxm6xclORWK/yU X+kVrFXFZA329+qvcC5F0Ep85rUOjCCjHP7lPGWFWqjrZr3HvYNz4iWS3DTQfdVqXH2c pNdw==
X-Gm-Message-State: APjAAAXE/qWWeyX6OVm2n412NbLfseHrNJw1IW57E9e4+FunOgM2omfl OznovX0ikpmUDzI1oI+d5pRSKJRw
X-Google-Smtp-Source: APXvYqw2YnIBTv/niMGmXYIFB9R1Foll+KOKDBc8yaJsvPCZA/7jpALoJOh5jMWp98h5xSPxhBprTg==
X-Received: by 2002:a17:90a:a10f:: with SMTP id s15mr7116379pjp.40.1582939062263; Fri, 28 Feb 2020 17:17:42 -0800 (PST)
Received: from [2601:640:102:57a9:400a:1e01:70:0] ([2601:640:102:57a9:3d6a:60c0:a092:3242]) by smtp.gmail.com with ESMTPSA id 199sm13281890pfv.81.2020.02.28.17.17.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 17:17:41 -0800 (PST)
Date: Fri, 28 Feb 2020 17:17:33 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, Alvaro Retana <aretana.ietf@gmail.com>
Cc: Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, "=?utf-8?Q?idr=40ietf._org?=" <idr@ietf.org>
Message-ID: <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark>
In-Reply-To: <CAMMESszb=kVw+9Yw=ozk+k+32_Bz-06G-_xTmikgHJPtoiaUmw@mail.gmail.com>
References: <CAMMESszb=kVw+9Yw=ozk+k+32_Bz-06G-_xTmikgHJPtoiaUmw@mail.gmail.com>
X-Readdle-Message-ID: 66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5e59bbb2_5f5e7fd0_ba8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CtGiet07qvRzNTI1ClBAahuhps0>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09
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, 29 Feb 2020 01:17:46 -0000

Dear Alvaro,

Many thanks for your thorougful review!
Please see inline

Cheers,
Jeff
On Feb 26, 2020, 2:19 PM -0800, Alvaro Retana <aretana.ietf@gmail.com>om>, wrote:
> Dear authors:
>
> This is my review of draft-ietf-idr-bgp-ls-segment-routing-msd-09.  I
> have put some comments in-line below which should be easy to address.
>
> This document, like many other BGP-LS specifications to carry
> IGP-derived information is written with that assumption: that the
> information will come from the IGPs.  However, §2 reads:
>
>     The BGP-LS speaker may also advertise the MSD information for the local
>     node and its links when not running any link-state IGP protocol e.g. when
>     running BGP as the only routing protocol.
>
> This case (no IGP) is not fully explained in the text.  Borrowing from
> the IGP RFCs, two clear pieces of information that are missing are:
>
>    (1) A definition of what the Node/Link MSDs are.  I borrowed from rfc8476
>    and made suggestions for §3 and §4 of this document (in-line).
>
>    (2) "Procedures for Defining and Using Node and Link MSD Advertisements",
>    similar to §4 (in both rfc8476/rfc8491).  Suggestion: simply include the
>    text from rfc8476 after §4 of this document.
[jeff]Ack
>
>
> The text in §2 is also not specific on how this local information
> should be advertised using BGP-LS.  Should the Direct Protocol
> Identifier be used, or, because of "running BGP as the only routing
> protocol" should it be BGP?  Please add details to the specification.
[jeff] Ack, it is BGP
>
> One more related point.  The deployment model for collecting
> IGP-derived information is that "BGP-LS is configured on a small
> number of nodes" [rfc8491], but the model for advertising local
> information is different.  Please include some text about that too.
>
>
> I will wait for a revised document to primarily address this text from
> §2 (and the in-line comments marked as [major]) before starting the
> IETF LC.
>
> Thanks!
>
> Alvaro.
>
>
>
> [Line numbers from idnits.]
>
> ...
> 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-
> 15                                 State
>
> [minor] s/Border Gateway Protocol Link-State/Border Gateway Protocol -
> Link State/g
> That is the form used in rfc7752 -- in the only place where BGP-LS is expanded.
[jeff]Ack
>
>
> ...
> 79 1.  Introduction
>
> 81   When Segment Routing (SR) [RFC8402] paths are computed by a
> 82   centralized controller, it is critical that the controller learns the
> 83   Maximum SID Depth (MSD) that can be imposed at each node/link on a
> 84   given SR path.  This ensures that the Segment Identifier (SID) stack
> 85   depth of a computed path doesn't exceed the number of SIDs the node
> 86   is capable of imposing.
>
> [nit] s/learns/learn
[jeff]Ack
>
>
>
> ...
> 93   However, if PCEP is not supported/configured on the head-end of a SR
> 94   tunnel or a Binding-SID anchor node, and controller does not
> 95   participate in IGP routing, it has no way of learning the MSD of
> 96   nodes and links.  BGP-LS [RFC7752] defines a way to advertise
> 97   topology and associated attributes and capabilities of the nodes in
> 98   that topology to a centralized controller.  This document defines
> 99   extensions to BGP-LS to advertise one or more types of MSDs at node
> 100   and/or link granularity.
>
> [nit] s/to advertise/to expose
> For consistency with the OSPF/ISIS documents.
>
>
> [minor] Including the last sentence above makes the text not flow
> well: it first says that extensions "to advertise one or more types of
> MSDs" are defined here...and then it talks about other types of MSDs.
> Suggestion:  Move that sentence to be the first one in the last
> paragraph.
[jeff]Ack
>
>
>
> 102   Other types of MSD are known to be useful.  For example,
> 103   [I-D.ietf-ospf-mpls-elc] and [I-D.ietf-isis-mpls-elc] define Readable
> 104   Label Depth Capability (RLDC) that is used by a head-end to insert an
> 105   Entropy Label (EL) at a depth that can be read by transit nodes