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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 30 March 2020 22:13 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 7790E3A0CB2; Mon, 30 Mar 2020 15:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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, 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 q0M8khZQOYt2; Mon, 30 Mar 2020 15:13:27 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 BAC603A0D1F; Mon, 30 Mar 2020 15:13:27 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id z3so206807pjr.4; Mon, 30 Mar 2020 15:13:27 -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=bOUul5qz1Pul12LPzBqsvP6T8KRS3QTtAUcdwSVLQxk=; b=FJYeI+JOccCt9kIyTgxQAWVdbRzK6GjuD7AgFvdSL2cNkrYY0f8Ael/KZQL0EZgEOw cbe/5YWhKhCOus/0g3jCk8IUXYA4ek4GetbaxrCL3CNWTSzZQPMmHvsAfDxk05ZCR6+6 do58iDKqBgl1owL5wdNPzFcsbu2O70ZgU/FWsGtRz4x+ae0MH0pG4EkyNdX1PCdsxV9q Ghln/A9ZOgFtPqnQCpl+KwpakP/v34lx5aD35WdEqIP7k3g68BoZR/jtI5zz8h0KiEl/ U9uImrCvpTPTvBk9ijPQV5tgKMKGA0NuXTN5eUmWSXJoYwIbRItpqLuHgNSy5eAPw3XM Lvrg==
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=bOUul5qz1Pul12LPzBqsvP6T8KRS3QTtAUcdwSVLQxk=; b=IvYki7mbzuvTI6AFgTiTL5DFvSXgWrkwRlHjcmJcghjld+N+6AOpUmPScseG6Eb4Os 9mT+fqkhtOoJwDTmDAxWCik3yVsblk0TmGYDISKIZPMJdQedQRG7CsNHQxuYCMRrAd2e tAQlzlYHFg/l1+bZmLbg8Ve6gRHTxgnvwXsv292siCphVGZ+bvuW2fOxHAyHfaBBasJd w3mKgje0oPSl1uetnRRZC+xhnkqIzc9kVVHonXpe+e9vuCOLHxX9zALumO49E5wbyA2W VIutQ8oFULhifcxlhPyA6gMtOhy262Nym5mnX07CDeYGIy2VhUkrjfS5oRbYv4quGZ6g 6A+w==
X-Gm-Message-State: AGi0PuaW/I4eSMadYeHFoE9ejTtZzgiuc4WT5HC91FCgvnL/r+KzLDw2 ZaOz+hkF8be/LSGY/3V0MASKPF6J
X-Google-Smtp-Source: APiQypLoxD0hln137ycwdYmhMJWiW6MGygbd5FQEAI7uvpfYkpfqGS5V5T7c/PnUTUMbxZkC1ZT1Ag==
X-Received: by 2002:a17:90a:f48c:: with SMTP id bx12mr302838pjb.64.1585606407152; Mon, 30 Mar 2020 15:13:27 -0700 (PDT)
Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id j26sm9486251pfi.192.2020.03.30.15.13.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2020 15:13:26 -0700 (PDT)
Date: Mon, 30 Mar 2020 15:13:19 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <d41252bc-42b2-4adb-8ad8-5d40a48c2a0b@Spark>
In-Reply-To: <MW3PR11MB4570D21EA2E607E636325768C1CB0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <CAMMESszb=kVw+9Yw=ozk+k+32_Bz-06G-_xTmikgHJPtoiaUmw@mail.gmail.com> <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark> <CAMMESsyHtp4NkxYiDn9NctPP0k3h647r-01fYO0jcDNdNonWng@mail.gmail.com> <MW3PR11MB4570D21EA2E607E636325768C1CB0@MW3PR11MB4570.namprd11.prod.outlook.com>
X-Readdle-Message-ID: d41252bc-42b2-4adb-8ad8-5d40a48c2a0b@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5e826f04_272a9914_16f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MrehWB5ujjGysp_2pH9hdmtw294>
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: Mon, 30 Mar 2020 22:13:30 -0000

Hi Alvaro,

As communicated by Ketan, the authors have decided to address  MSD in BGP-only networks someplace else.
v16 has been published to reflect this change.

Many thanks for your help!

Cheers,
Jeff
On Mar 30, 2020, 5:51 AM -0700, Ketan Talaulikar (ketant) <ketant@cisco.com>, wrote:
> Hi Alvaro,
>
> I see that the point of inclusion of advertisement of MSD in BGP-only networks is the only outstanding point to be addressed from your AD review. You have suggested that the aspects related to advertisement in BGP-only networks are better covered via draft-ketant-idr-bgp-ls-bgp-only-fabric.
>
> As a co-author of both the concerned drafts, I am ok with removing the BGP-only network aspects from the MSD draft and taking it up in the draft that covers aspects of BGP-only networks.
>
> Would like to take inputs of the WG as well on the same and we can plan to move the draft-ketant-idr-bgp-ls-bgp-only-fabric for adoption.
>
> Thanks,
> Ketan
>
> -----Original Message-----
> From: Alvaro Retana <aretana.ietf@gmail.com>
> Sent: 06 March 2020 22:41
> To: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
> Cc: Susan Hares <shares@ndzh.com>; idr-chairs@ietf.org; idr@ietf. org <idr@ietf.org>
> Subject: Re: AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09
>
> On February 28, 2020 at 8:17:42 PM, Jeff Tantsura wrote:
>
>
> Jeff:
>
> Hi!
>
>
> 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:
> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-bgp-ls-segment-routing-msd-13.txt
>
>
> Thanks!
>
> Alvaro.
>
>
>
> > 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)