Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Robert Raszuk <robert@raszuk.net> Sat, 06 March 2021 11:10 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFD23A197B for <lsr@ietfa.amsl.com>; Sat, 6 Mar 2021 03:10:22 -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, 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=raszuk.net
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 6C9WkDkDXK8X for <lsr@ietfa.amsl.com>; Sat, 6 Mar 2021 03:10:20 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 086CB3A197A for <lsr@ietf.org>; Sat, 6 Mar 2021 03:10:19 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id k9so10302427lfo.12 for <lsr@ietf.org>; Sat, 06 Mar 2021 03:10:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IQhIT5FIFaaoic4wK3lWdCHHvCeXavvUjvE31V6h3Qo=; b=O82xT2+2IWtImcoT11qV4Gfp/EizY2RA076+FN3ElCwoqAjIFPBVqZ2T6sBnq1YLAr UkVyheaqHs9RsSHG6bKoPJUXgC+M1XPnQAjy7/XbS+jVEOIFCAvfFqt3LoNPo1g1hM3H wi7qcyEdGRP2YpUGnZFA9LqANHuCqw7ZD/4mbQgNA7xAKuNmmv09JwKIeN2oedxbLsJ1 MZ6S5RXztusM69pASM977EPNak4j+BOuD4jhJ+09FggopNGXKl7FxXIPowJt4nQ7KovA 0lsh3FuVp0Bc3s1hDoYM1Hdu4ebDQ14DiBrJhLLayyigc8/9Bi+NDk123qXJOy6clj8c +N2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IQhIT5FIFaaoic4wK3lWdCHHvCeXavvUjvE31V6h3Qo=; b=VlY9tK20q4oeWr0La3KRmwseL3whYeYgNrqkkzYiINKWJ3CCiSYG01ziPUVrJ5RKyb GOgVWVtNds20eW0MRN7nKiF+6cbBNVGfhqBPtW4g3W2b6GttoWo4nJCHmJgDvqzc2HeN SblmDIZcwqvluHZk1BWxfBVPvRgLyvvlXalVqn+NgFoOqzi+9AddsVRqgYnIfEJYR4D2 TYVKCStHZ6+4RlVqOYM3qTzt5hq4AEMI1aQ+ku/NaWOr6HscZBthbpz5NTdKrSVcRxUA EoK89BOXiDeWSTlDY7xLWBWZJUsg2Vqk+osaIGVc4oNwm703kUT8GJESL4xFDDp1BqsQ vLaA==
X-Gm-Message-State: AOAM532uXTDUS5R0+4npEWxwoWnNkedl6BRb0Atj5/UesIHlDe4uV/ti XsGIEngmW5SXpuQhX3GxtQdB1mdn3vRJTao9hjfbpw==
X-Google-Smtp-Source: ABdhPJyx1taHxWAMjZ3TR+Rpe38+QRF3wpGgercCBPdGebOguIM0w0SdlsCrndcTi/KcdTWhkdo1i2GC+Up4ZJqKIoY=
X-Received: by 2002:a19:c14c:: with SMTP id r73mr8868291lff.581.1615029017066; Sat, 06 Mar 2021 03:10:17 -0800 (PST)
MIME-Version: 1.0
References: <6413094C-F1D8-4DBF-B365-E943473FDDE4@cisco.com> <BY5PR11MB433727F6D0A365B26896625DC1979@BY5PR11MB4337.namprd11.prod.outlook.com> <2021030421033728661450@foxmail.com> <BY5PR11MB43378320E0607268CA22A900C1979@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43378320E0607268CA22A900C1979@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 06 Mar 2021 12:10:06 +0100
Message-ID: <CAOj+MMHL4ritC6x_STU4YqaXCqaWPnOZqAS8XSXiDzEGjfb35w@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Chongfeng Xie <chongfeng.xie@foxmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd51cf05bcdc3e4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zkngSimwIbAzMHtRvW1oLoT8zws>
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 11:10:23 -0000

Hello,

I agree with Les that this draft may not be a fit for LSR WG.

Typically this type of effort (essentially describing use cases) is much
better to be put in slides and present on various operators forums.

That said I think perhaps we are indeed missing LROW WG (Local Routing
Operations WG) where just like in GROW WG where mainly (Global) BGP
operational aspects are discussed there could be good place to discuss
operational aspects of link state protocols deployment and use cases. In
fact perhaps it would also free some LSR bandwidth to really focus on
protocol extensions.

Thx,
R.



On Thu, Mar 4, 2021 at 5:18 PM Les Ginsberg (ginsberg) <ginsberg=
40cisco.com@dmarc.ietf.org> wrote:

> Chongfeng –
>
>
>
> Just to clarify my position…
>
>
>
> IMO there is no substantive content in this draft that warrants it
> becoming an RFC – Informational track or otherwise. It is simply a set of
> pointers to other documents/registries.
>
>
>
> If the authors find the content in some way helpful, I think the more
> suitable path for you is to publish a white paper and post it on whatever
> web site seems appropriate to you.
>
> I just do not see any content in the draft that warrants a standards body
> like IETF producing a new document.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
> *From:* Chongfeng Xie <chongfeng.xie@foxmail.com>
> *Sent:* Thursday, March 04, 2021 5:04 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Acee Lindem (acee) <
> acee@cisco.com>; lsr@ietf.org
> *Subject:* Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology
> (MT) for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
>
>
>
>
> Hi, Les,
>
>
>
> Thanks for the review of this document.
>
>
>
> As the current document type is informational, it does not introduce new
> TLV to IS-IS. While it describes the mechanisms of using existing TLVs to
> distribute the information of SR based VTNs, which can have customized
> topology and a set of dedicated network resources. It also describes the
> forwarding behaviors based on the SIDs and the resources allocated to each
> VTN.
>
>
>
> IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple
> logical topologies and perform independent path computation for each
> topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by
> the MT TLVs “if traffic engineering or some other applications are being
> applied per topology level later”. While it does not specify what the
> topology-specific TE attributes mean, and how traffic in different
> topologies are forwarded on a shared outgoing interface. These are
> described in section 3 and section 4 of this document.
>
>
>
> RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR
> SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs
> and Locators are not specified, especially when the SIDs are associated
> with different set of network resources.
>
>
>
> Section 5 gives the analysis about the scalability of this mechanism, and
> talks about a case where two VTNs have the same logical topology, but with
> different set of resources.
>
>
>
> IMO the value of this document is that it provides an option to build SR
> VTNs with no IS-IS protocol extensions, which could be useful for some
> network scenarios.
>
>
>
> Best regards,
>
> Chongfeng
>
>
> ------------------------------
>
> chongfeng.xie@foxmail.com
>
>
>
> *发件人:* Les Ginsberg \(ginsberg\) <ginsberg=40cisco.com@dmarc.ietf.org>
>
> *发送时间:* 2021-03-04 11:52
>
> *收件人:* Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org
>
> *主题:* Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for
> Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
> I oppose WG adoption for this draft.
>
>
>
> I note that the authors – following significant comments received on V0 -
> have removed much of the material that was considered confusing and/or
> inappropriate – notably discussion of L2 bundle link members.
>
> I also note the draft has moved from Standards track to Informational
> track.
>
>
>
> Let’s consider what content remains (ignoring boilerplate sections):
>
>
>
> Section 2 notes that MT TLVs (RFC 5120) can support:
>
>    o Topology specific SR-MPLS SIDs (defined in RFC 8667)
>
>    o Topology specific SRv6 Locators and SIDs (defined in
> draft-ietf-lsr-isis-srv6-extensions)
>
>
>
> Section 3 notes that MT TLVs can also support link attribute
> advertisements (defined in RFC 5305 and RFC 8570)
>
>
>
> Also note that the IANA registries:
>
>
>
>
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> and
>
>
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237
>
>
>
> also clearly document what is discussed in Sections 2 and 3.
>
>
>
> Section 4 notes that topology specific forwarding entries can be installed
> in the forwarding plane based on topology specific routing calculations –
> something which was discussed in RFC 5120.
>
>
>
> Section 5 notes that two different MTIDs could operate on the same
> physical topology - something clearly discussed in RFC 5120.
>
>
>
> All of this adds nothing new to our understanding of the protocol. The
> only “new” content is the statement that VTNs could map to MTIDs.
>
> But the substance of VTN and how it might be used is better discussed in a
> number of other drafts including:
>
>
>
>    draft-ietf-spring-sr-for-enhanced-vpn
>
>    draft-ietf-teas-enhanced-vpn
>
>    draft-dong-lsr-sr-enhanced-vpn
>
>
>
> The last draft is most notable because it proposes new IGP protocol
> encodings in support of VTN. Whether the encodings in that draft are
> accepted as currently defined or evolve to something different – it would
> be the authoritative draft on VTN IGP extensions.
>
>
>
> The end result is that there is no meaningful content in
> draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in
> existing RFCs or will be stated authoritatively in whatever
> draft-dong-lsr-sr-enhanced-vpn  evolves to (if indeed this work on VTNs is
> adopted by the WG).
>
>
>
> Let’s please not waste WG time on this draft.
>
>
>
>    Les
>
>
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, March 02, 2021 3:28 PM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
> for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
>
>
> This information draft describes how MT could be used for VTN
> segmentation. The authors have asked for WG adoption.
>
>
>
> This begins a three week LSR Working Group Adoption Poll for “Using IS-IS
> Multi-Topology (MT) for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF
> next week. Please register your support or objection on this list prior to
> the end of the adoption poll on 3/24/2020.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>