[Teas] Comments on draft-zzhang-teas-network-slicing-with-flex-te \\RE: draft-xie-idr-bgpls-sr-vtn-mt

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 10 August 2020 10:01 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9DA463A0C3D; Mon, 10 Aug 2020 03:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hUoWOmIwNzHw; Mon, 10 Aug 2020 03:01:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 21FE73A0C0C; Mon, 10 Aug 2020 03:01:18 -0700 (PDT)
Received: from lhreml726-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 71FC0F81E6A1986EDE19; Mon, 10 Aug 2020 11:01:16 +0100 (IST)
Received: from dggeme704-chm.china.huawei.com ( by lhreml726-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 10 Aug 2020 11:01:15 +0100
Received: from dggeme754-chm.china.huawei.com ( by dggeme704-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 10 Aug 2020 18:01:13 +0800
Received: from dggeme754-chm.china.huawei.com ([]) by dggeme754-chm.china.huawei.com ([]) with mapi id 15.01.1913.007; Mon, 10 Aug 2020 18:01:13 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
CC: "idr@ietf. org" <idr@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "'licong@chinatelecom.cn'" <licong@chinatelecom.cn>, "'xiechf@chinatelecom.cn'" <xiechf@chinatelecom.cn>, Lizhenbin <lizhenbin@huawei.com>
Thread-Topic: Comments on draft-zzhang-teas-network-slicing-with-flex-te \\RE: draft-xie-idr-bgpls-sr-vtn-mt
Thread-Index: AdZu/N0+WXjTmM9lQlavMPIhKF+47Q==
Date: Mon, 10 Aug 2020 10:01:13 +0000
Message-ID: <b0b06a08e1ba48a093775bb984474167@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/vuDunh4429GyoEQk26lpnIi3pzA>
Subject: [Teas] Comments on draft-zzhang-teas-network-slicing-with-flex-te \\RE: draft-xie-idr-bgpls-sr-vtn-mt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 10:01:23 -0000

Hi Jeff, 

Thanks for your information about the Flexible TE draft. 

After reading it, my understanding is only the edge nodes are allowed perform per-algo SPF, and for consistent forwarding, only adj-SIDs can be used for the SR path. 

I have a few questions and comments about this document, and I'd appreciate your reply and clarification on them, thanks.

1. Are the link admin-groups configured on links in the network? Or they are provisioned on the controller first, then distributed only to the edge nodes?

2. With the proposed mechanism, will IGP still be used for the distribution of Flex-Algo definition, the link admin-group information and the algo-specific SIDs? And are per-algo SIDs still needed? 

3. After an edge node performs per-algo SPF and builds an SR-TE path, does it generate a SR policy locally for the SR-TE path? 

4. It proposes to use BGP-LS with RT for targeted distribution of FAD and link-state information from controller, as discussed in IDR meeting, some reasons about why BGP-LS or BGP is suitable for this would be needed. 

5. In the IGP extensions, a router originates LSAs/LSPs with other node's link-state information, this is different from the traditional IGP mechanism. Also with IGP flooding, there is no control of the target nodes to receive and keep such information. Are these IGP extensions comply to the concept of the per-algo SPF on edge nodes or selected nodes?  

Best regards,

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
> Sent: Saturday, August 1, 2020 3:24 AM
> To: 'licong@chinatelecom.cn' <licong@chinatelecom.cn>cn>;
> 'xiechf@chinatelecom.cn' <xiechf@chinatelecom.cn>cn>; Dongjie (Jimmy)
> <jie.dong@huawei.com>om>; Lizhenbin <lizhenbin@huawei.com>
> Cc: idr@ietf. org <idr@ietf.org>rg>; teas@ietf.org
> Subject: RE: draft-xie-idr-bgpls-sr-vtn-mt
> Oops the draft that I was referring to at the end of this email should be
> draft-zzhang-teas-network-slicing-with-flex-te.
> Jeffrey
> Juniper Business Use Only
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: Friday, July 31, 2020 11:11 AM
> To: 'licong@chinatelecom.cn' <licong@chinatelecom.cn>cn>;
> 'xiechf@chinatelecom.cn' <xiechf@chinatelecom.cn>cn>; 'Dongjie (Jimmy)'
> <jie.dong@huawei.com>om>; 'lizhenbin@huawei.com'
> <lizhenbin@huawei.com>
> Cc: idr@ietf. org <idr@ietf.org>rg>; teas@ietf.org
> Subject: [Teas] draft-xie-idr-bgpls-sr-vtn-mt
> [External Email. Be cautious of content]
> Hi,
> About the following:
> 4.  Scalability Considerations
>    The mechanism described in this document requires that each VTN has
>    an independent topology, and for inter-domain VTNs, the MT-ID used
> in
>    each involved domain is consistent.  While this brings the benefits
>    of simplicity, it also has some limitations.  For example, it means
>    that even if multiple VTNs may have the same topology attribute, they
>    would still need to be identified using different MT-IDs in the
>    control plane.  This requires that for each VTN, independent path
>    computation would be executed.  The number of VTNs supported in a
>    network may be dependent on the number of topologies supported,
> which
>    is related to the control plane computation overhead.
> As I mentioned after Cong's presentation in IDR, Flexible TE (Flexible
> Algorithm + SR-TE + Targeted Distribution) addresses the above scaling
> concerns. I also have some further thoughts on advertising other
> attributes, to be published in later revisions of my
> draft-zzhang-teas-flexible-te draft.
> Would like to hear your thoughts.
> Thanks.
> Jeffrey
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas_
> _;!!NEt6yMaO-gk!U5ARee2LojrOjDlBuFV-m1hPriQ0KLGu4zNhkpLmgjTnuC0y
> 9n3kUr13t4g7CEZN$