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

Alvaro Retana <> Fri, 06 March 2020 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B86613A0B19; Fri, 6 Mar 2020 09:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 INkTz1KOLy7t; Fri, 6 Mar 2020 09:11:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A4253A0AEC; Fri, 6 Mar 2020 09:11:08 -0800 (PST)
Received: by with SMTP id g19so3322324eds.11; Fri, 06 Mar 2020 09:11:08 -0800 (PST)
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=uYw37GI9wk9v+PZx2wXlvhyWu1o6uv+ParZg6mYTJ0c=; b=rH6LJeZvZjzrvvbjLmAtSZUN/oitol30+kNDMhh+rbq8jscxmRLRuH9xHMtSL8j1vH xiis71VvT+aPnXlVB352SWLfFjeE4nJ34cGJInRmpYZXzxEsneGQsJTTjIV9pe4OmFeT bw18D5lv6VrlEiNTK/kF0B/+6yM4fqWtG6y1FE64DQjh4gisQPBkdU/yppQS9fVX3SbZ TOTeCH+3Or7MfOEw8yS9pSOxsiVY8PgqKSjZdVjTzkgEdtc3Ir4V3pyhTYUAwSFA8Kn4 +3XUL76eDHYTqPLK+gUmmrZm2sgVL+aoXWDpqDB0PbUSeM+j3KqudtMvJCva0EpDLT5O ouYA==
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=uYw37GI9wk9v+PZx2wXlvhyWu1o6uv+ParZg6mYTJ0c=; b=lw3WUWMOhgfXW1yJOg+wfrAu7sIGZ1bDgOnjjyNdrUKhjOiurvYlkdoMfnHipDS2Jh VdERUjVQwEnBwwo7tnqhrq3zDJO6EZV3jaB0eADZLxL/pRWMGYbmOQuOD2qkuiZEVZYS nGHcdBa9WjVkECozYiISJtimNBsET6xuKmk0BDS+8+szKXaJjMPGwpHLnFdbl1NUQjUs ilusMQUBC0CyH6e8lO+/qGDs6aLJ+htaD7x+lmrR+h4f5fgkHejJbXdGsatxEd+aHNyB vmHebdcIQwBcPQa9OzQIBAJz7rTnW36P2aprk+IJreQIw6X6BpPtyGlXws7lQoV/dnlq WcYg==
X-Gm-Message-State: ANhLgQ2k/o3KNVvFNTbyrTCSQmbOiH74C/6xaNB3o2Vf81OZMWRBR7RJ c+83t5ntmO7ZzdmCx693eXK64eVJSeBb2GhKnB6eg/ha
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtCsQsO0LCJLNpE6+3MfzwGjK/3uBAHiJBdw0uE?= =?utf-8?q?JjoSC1tPJutKUp45lvpQCg0wC31ZX3SDvgL+ko9rwNZ3XwI=3D?=
X-Received: by 2002:aa7:df0a:: with SMTP id c10mr4294960edy.238.1583514666663; Fri, 06 Mar 2020 09:11:06 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 6 Mar 2020 09:11:05 -0800
From: Alvaro Retana <>
In-Reply-To: <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark>
References: <> <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark>
MIME-Version: 1.0
Date: Fri, 6 Mar 2020 09:11:05 -0800
Message-ID: <>
To:, Jeff Tantsura <>
Cc: Susan Hares <>,, "idr@ietf. org" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09
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: Fri, 06 Mar 2020 17:11:11 -0000

On February 28, 2020 at 8:17:42 PM, Jeff Tantsura wrote:



Thanks for the updated text -- I looked at -13.

I think that including BGP, in this document, as one of the sources of
the MSD is not the right thing to do.  Please see the details below.

That is the only major item remaining.  Please take a look at idnits
as there are a couple of unused references left:



> On Feb 26, 2020, 2:19 PM -0800, Alvaro Retana , wrote:
> > 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

As far as I can tell, this is the first BGP-LS-related document that,
while defining how to carry IGP information, tries to talk about
collecting that information in a BGP-only network.  See below.

> > 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.

The related text from §2 is this:

   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.  The Protocol-ID
   field should be set to BGP since the link and node attributes have
   BGP based identifiers.  Deployment model for such case would be: a
   limited number (meeting resiliecy requirements) of BGP-LS speakers
   exposing the topology to the controller, full-mesh/RouteReflectors
   for iBGP(Internal Border Gateway Protocol) or regular eBGP(External
   Border Gateway Protocol) connectivity between nodes in the topology.

[major] Suggestion: remain consistent with other BGP-LS documents and
focus on carrying IGP-originated information.  We can let a different
document (like draft-ketant-idr-bgp-ls-bgp-only-fabric) deal with the
BGP-only details.

Note that this is my personal suggestion.  I didn't see a specific
discussion on the list about this topic.  If we need to reconfirm
consensus then we should ask the WG.  I'll rely on the

Note 1: I you follow this suggestion, then you need to remove the
extra information you added in the new §5.

Note 2: If you don't follow the suggestion, then there are some other
issues we need to deal with as follows:

[major] "The Protocol-ID field should be set to BGP..."  Shouldn't
this statement be Normative?  Why would the protocol-id not be set to
BGP?  IOW, should it be a MUST?

[major] "The Protocol-ID...set to BGP"  Please add a Normative
reference to draft-ietf-idr-bgpls-segment-routing-epe, which is where
the BGP Protocol-ID is defined.

[major] " and node attributes have BGP based identifiers."
Because we're talking about a BGP-only network, these attributes
(similar to the ones collected from the IGPs) should represent the
topology of the network so that the controller can do its magic.
Where is that defined?  It seems to me that the only document that
defines it is draft-ketant-idr-bgp-ls-bgp-only-fabric, so we'll need a
Normative reference to it too.

[major] "Deployment model for such case would be..."  Those deployment
models don't work in this case because BGP doesn't propagate the
topology information.  IOW, connections to all the routers are needed.