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

peng.shaofu@zte.com.cn Tue, 09 March 2021 02:52 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 D16033A0B3F for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 18:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.917
X-Spam-Level:
X-Spam-Status: No, score=-6.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 UQph1EMmxruC for <lsr@ietfa.amsl.com>; Mon, 8 Mar 2021 18:52:36 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 EBD7C3A0B17 for <lsr@ietf.org>; Mon, 8 Mar 2021 18:52:35 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id A64E5E07615B3349FD05; Tue, 9 Mar 2021 10:52:33 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 1292q1nw072983; Tue, 9 Mar 2021 10:52:01 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Tue, 9 Mar 2021 10:52:00 +0800 (CST)
Date: Tue, 09 Mar 2021 10:52:00 +0800
X-Zmail-TransId: 2af96046e2d09c81eaf4
X-Mailer: Zmail v1.0
Message-ID: <202103091052008812087@zte.com.cn>
In-Reply-To: <3b76b906532b4931800a58620dc996cc@huawei.com>
References: 6413094C-F1D8-4DBF-B365-E943473FDDE4@cisco.com, BY5PR11MB433727F6D0A365B26896625DC1979@BY5PR11MB4337.namprd11.prod.outlook.com, 2021030421033728661450@foxmail.com, BY5PR11MB43378320E0607268CA22A900C1979@BY5PR11MB4337.namprd11.prod.outlook.com, CAOj+MMHL4ritC6x_STU4YqaXCqaWPnOZqAS8XSXiDzEGjfb35w@mail.gmail.com, CA+wi2hOcWh0UFJB4BMta6X9_Kv9c0Dpu3ZUbGQV324p5UYu7oA@mail.gmail.com, CABNhwV2MJoJdS8VKSfQXb5t6BNs19DOPpWF_y70kw1UP+Kk+NA@mail.gmail.com, cce9bf49158e439f8e6ae868cf16ec0f@huawei.com, 54882636-246F-4609-805D-AFE9FCC5A249@juniper.net, 3b76b906532b4931800a58620dc996cc@huawei.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: jie.dong@huawei.com
Cc: tsaad@juniper.net, hayabusagsm@gmail.com, tonysietf@gmail.com, ginsberg=40cisco.com@dmarc.ietf.org, chongfeng.xie@foxmail.com, acee@cisco.com, robert@raszuk.net, lsr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 1292q1nw072983
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RrMWYEKwLRiz2m1OdVcM7KxXmCg>
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: Tue, 09 Mar 2021 02:52:40 -0000

Hi Jie,






Now that you mention VTN-ID, I have to point out that the VTN-ID in draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in draft-peng-teas-network-slicing, just a new name. That can be seen from the evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/





I'm glad to see that the idea in draft-peng-teas-network-slicing and draft-bestbar-spring-scalable-ns have been generously adopted by you.




Regards,

PSF









原始邮件



发件人:Dongjie(Jimmy)
收件人:Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人:Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert Raszuk;lsr@ietf.org;
日 期 :2021年03月09日 00:31
主 题 :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


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

 

Hi Tarek,


 


Your understanding about the scalability implication of this MT based VTN mechanism is correct, this is also described in section “scalability considerations” of this draft. The value of this mechanism is that it reuses several existing TLVs together to provide the required function.


 


As for the mechanisms which can provide better scalability, you could refer to draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is introduced, and multiple VTNs can be associated with the same topology. Further discussion about that draft and its relationship with draft-bestbar-lsr-spring-sa could happen in a separate thread.


 


Best regards,


Jie


 




From: Tarek Saad [mailto:tsaad@juniper.net] 
 Sent: Monday, March 8, 2021 10:44 PM
 To: Dongjie (Jimmy) <jie.dong@huawei.com>; Gyan Mishra <hayabusagsm@gmail.com>; Tony Przygienda <tonysietf@gmail.com>
 Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Chongfeng Xie <chongfeng.xie@foxmail.com>; Acee Lindem (acee) <acee@cisco.com>; Robert Raszuk <robert@raszuk.net>; lsr@ietf.org
 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




 


Hi authors,


 


My understanding is the draft is proposing a separate MT topology (unique MT-ID) to identify a forwarding treatment to be enforced on a shared resource.


While this may work for limited number of MT topologies (i.e. forwarding treatments), as described in RF5120 there is overhead with creating/advertising and managing and running separate SPF for each of the MT topology. This will restrict the scalability of such approach (number of forwarding treatments to be realized) using this approach.


 


In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID (associated with the forwarding treatment) independent of the topology ID. This allows the # of forwarding treatmentst to be independent of the # of MT topologies that need to be managed by IGP; and hence, allow it to scale. Your feedback on this approach is welcome.


 


Regards,


Tarek


 


 


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <lsr-bounces@ietf.org on behalf of jie.dong@huawei.com> wrote:




 


Hi Gyan,


 


Thanks for your comments. 


 


As you mentioned, both MT and MI can provide separate topologies and the topology based computation, and MI can provide separate LSDBs at some additional cost (separate adjacencies, etc.). In this document, the resource of VTN mainly refers to the forwarding plane resources, thus MT is chosen as it can provide the required functionality with less overhead. 


 


Hope this helps.


 


Best regards,


Jie


 




From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Gyan Mishra
 Sent: Monday, March 8, 2021 7:29 AM
 To: Tony Przygienda <tonysietf@gmail.com>
 Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Chongfeng Xie <chongfeng.xie@foxmail.com>; Acee Lindem (acee) <acee@cisco.com>; Robert Raszuk <robert@raszuk.net>; lsr@ietf.org
 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




 


 


Dear Authors 



 


Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT instances has separate topology but not separate LSDB where MI Multi instance RFC 6822 has a separate LSDB for resources isolation and I think would be a better fit for VTN underlay provisioning.



 


MI



https://tools.ietf.org/html/rfc6822



 


Thanks 



 


Gyan



 


On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda <tonysietf@gmail.com> wrote:



 


Robert ruminated: 


 


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. 



 



 


+1



 


IGPs grew a zoo of horns and bells by now and no'one tells the operators which spines are poisonous ;-)






 


--- tony






_______________________________________________
 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr




--





Gyan Mishra


Network Solutions Architect 


M 301 502-1347
 13101 Columbia Pike 
 Silver Spring, MD



 












 


Juniper Business Use Only