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

Chongfeng Xie <chongfeng.xie@foxmail.com> Thu, 04 March 2021 13:03 UTC

Return-Path: <chongfeng.xie@foxmail.com>
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 4CABC3A1AB4 for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 05:03:55 -0800 (PST)
X-Quarantine-ID: <8yiSKIPj_loG>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.116
X-Spam-Level:
X-Spam-Status: No, score=-1.116 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, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.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 8yiSKIPj_loG for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 05:03:52 -0800 (PST)
Received: from qq.com (out203-205-221-239.mail.qq.com [203.205.221.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A053A1AB0 for <lsr@ietf.org>; Thu, 4 Mar 2021 05:03:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1614863028; bh=S19GPtF085db4oNwMjANO7nUYSMTsxRW4utrBiMfJYE=; h=Date:From:To:Subject:References; b=noeJePz3On2DCu0VcJjVACZOpHVm/nU0tyYxpAKoZ9JruIimvpRj5sQd2qXsG8waW pGxWf8YLz/fpNMlZmdXJrs92H464Ok7FJOYDUaPKJn2qAgKVLQzLdVZ6We/AVmgxAS j+XJdkbB8uFeijHV1mwBe92VlGELGJKMdJ/YlALw=
Received: from DESKTOP-UGG3TED ([61.149.109.53]) by newxmesmtplogicsvrszc7.qq.com (NewEsmtp) with SMTP id E629A8C; Thu, 04 Mar 2021 21:03:38 +0800
X-QQ-mid: xmsmtpt1614863018tdv2soggc
Message-ID: <tencent_3C953C8542F9D6D71B80231C6066D5B17208@qq.com>
X-QQ-XMAILINFO: NRN3UPsLzYKV7eB4/oFiqWbdt8UA2bEbKl6K7t47/D3neymzNgPduUxbgfKLdd u9px2Md0pO+T8r2SnPIz6WCrlSNFt+Oow5SgEhUymAyXxyKqaGHUWBLxrV/TNyyla8FN5zyiRfcf zuC4kR7LN6XWOg+Ge1jxs8Y2W9/VJ7CFZi75J4lznr16QWsqy4j4Oz64D4tQBrcXRpwNq1JVG/os 95flC+PHHZxUiX3OfOT2HEre65zIemmiJiVJGHmZMR5S/v+/8jrG/YGYLHMEFh9QgKCeZz2kZzkL CeIaPt5vMVOtu72hXpbgT8826pyEpLvBl9jRS8IXo9EJ9kpRn9mSVox3G10RpiybsbOeGzLv47Uq hs7Kzr84KQ+Ekpbs7zkAOohwM+GMBxcjZKD4U+VvoC9Bolt9X4g4uCHgD1EEl258DWvIT7pZHOOb tUr0xQQgoNLeAxbCsZhDgPaRJDpfRVqUlQ49Xgy5KJZlUTsPBbZYlVZGuKRjpzra8S2Zpzqre2TT D9F0Mnctdf/UyuUtUSHd5REX+Zqqy+ClZHZ9yrJr5EOK9RqSLbn2221aCXO0ES8wsTA/QsH3dLnO Hkm2nqAwDv6zH5GXCvjJs6RRxf5dwAtFj+tV0+mv3dCwg02rsXeVSqGhvsr4O+T9Zs26cX5aCbgW l16tchEHTc8iDUYrm4MAMiLK6vWngoB8iRxq9YTP0r257XdN7ZWCyPUdVYsad0s+40NLPIkAgfDH I+0Kqs/OQDKhv7FdhS358s16TH3fFycMJsGJ9mrNvEGtSdUN2zCN+txk7uodfThC6qZBfOMb7FWa attnzE3r+XF6jgkkq4QxrvWry32srdSZeEBfQ7qlCauBzq6DTo4Rf44HuLScZb1/N0It6IwAG03R J8ClXGZ/wwvjAPEUAbcc6sZt0hVATNGVn3mfqm0j1q2fwLYQHAkbGv/Tfys536qQ==
Date: Thu, 4 Mar 2021 21:03:38 +0800
From: "Chongfeng Xie" <chongfeng.xie@foxmail.com>
To: "Les Ginsberg \(ginsberg\)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Acee Lindem \(acee\)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
References: <6413094C-F1D8-4DBF-B365-E943473FDDE4@cisco.com>, <BY5PR11MB433727F6D0A365B26896625DC1979@BY5PR11MB4337.namprd11.prod.outlook.com>
X-Priority: 3
X-GUID: B08FA136-5BA8-4357-9075-4B79E4AF7152
X-Has-Attach: no
X-Mailer: Foxmail 7.2.18.111[cn]
Mime-Version: 1.0
Message-ID: <2021030421033728661450@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart774765063583_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ZxQSr3bmTCZZw3hckHAq4tVhGbQ>
Subject: Re: [Lsr] =?utf-8?q?WG_Adoption_Poll_for_=E2=80=9CUsing_IS-IS_Multi-?= =?utf-8?q?Topology_=28MT=29_for_Segment_Routing_based_Virtual_Transport_N?= =?utf-8?q?etwork=E2=80=9D_-_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: Thu, 04 Mar 2021 13:03:55 -0000

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\)
发送时间: 2021-03-04 11:52
收件人: Acee Lindem (acee); 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