Re: [Teas] question on the topology filter draft

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 22 November 2021 11:46 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483133A0882 for <teas@ietfa.amsl.com>; Mon, 22 Nov 2021 03:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 uklsKf95cehT for <teas@ietfa.amsl.com>; Mon, 22 Nov 2021 03:45:56 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21C03A0881 for <teas@ietf.org>; Mon, 22 Nov 2021 03:45:55 -0800 (PST)
Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HyQRq4xBMz6H84q; Mon, 22 Nov 2021 19:44:55 +0800 (CST)
Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Mon, 22 Nov 2021 12:45:52 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Mon, 22 Nov 2021 19:45:50 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2308.020; Mon, 22 Nov 2021 19:45:50 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
CC: Loa Andersson <loa@pi.nu>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] question on the topology filter draft
Thread-Index: AQHX1ZNW8VkBVVI/wEe//eKs5WZBKqv8KkIAgAJb/YCAAGRKAIAQkGWw
Date: Mon, 22 Nov 2021 11:45:49 +0000
Message-ID: <6ae36666fdd641398a78d72ab155b83b@huawei.com>
References: <1ac0bf22-f0a9-a3d6-8188-63e006e85834@pi.nu> <CA+YzgTu+tfY+aCkHNof7h=JOm2QDBM5wTB2Qi0SyMquq9uyX1A@mail.gmail.com> <cdcb36f2622643d2a4af9b2164af47fc@huawei.com> <CA+YzgTtFZKb7nrv8OCbVscOwfKE7pKpejLF7K4hCHZyosGAfLQ@mail.gmail.com>
In-Reply-To: <CA+YzgTtFZKb7nrv8OCbVscOwfKE7pKpejLF7K4hCHZyosGAfLQ@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/alternative; boundary="_000_6ae36666fdd641398a78d72ab155b83bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1IiljhbTEBAsPuUfaCuxZz5Ko_8>
Subject: Re: [Teas] question on the topology filter draft
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, 22 Nov 2021 11:46:01 -0000

Hi Pavan,

Thanks for your reply. Please see some further inline with [Jie #2].

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, November 12, 2021 2:24 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: Loa Andersson <loa@pi.nu>; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] question on the topology filter draft

Jie,

Please see inline [prefixed Pavan]

Regards,
-Pavan

On Thu, Nov 11, 2021 at 12:11 PM Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> wrote:
Hi Pavan,

Please fine some comments about topology filter and its usage inline:

From: Teas [mailto:teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>] On Behalf Of Vishnu Pavan Beeram
Sent: Wednesday, November 10, 2021 8:23 PM
To: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Cc: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] question on the topology filter draft

Loa,

Please see inline (prefixed VPB)

Regards,
-Pavan


On Tue, Nov 9, 2021 at 11:57 AM Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> wrote:
WG, Pavan, authors,

I was cut off at the end of the queue in the wg discussion. I had a
fairly simple question,

Where the topology filter(s) defined

[VPB] The term “topology filter” is being introduced in draft-bestbar-teas-yang-topology-filter (not aware of any other document where it is defined). As per this data model draft, a “topology filter” is a data construct that can be applied on either a native topology or a customized topology to produce a filtered set of topological elements. The native or customized topology referred to here is a TE aware topology [RFC8795].

[Jie] Since the term “topology filter” is newly introduced in this YANG model draft, it would be useful to state in the document “who” is the consumer of this information. More specifically, who will use the topology filter in path or route computation.


[Pavan] The consumer depends on the use-case; The to-be-added use-case section is expected to  have sufficient details to address this.

[Jie #2] OK, would like to review the use case section when it is available.
and what benefits do we get from
using them?

[VPB] There are a couple of use-cases that are being targeted with this construct.

(a) Specification of topology related constraints for TE path computation (any setup type):
A few examples:
- Compute a path within a specific topology
- Compute a path within the topology associated with a specific IGP domain
- Compute a path within the topology learnt from a specific TE Information Source
- Compute a path within the topology defined by the application of one or more topology-filters
** Say, a topology with elements that are learnt via ISIS Level-2 and include resource-affinity red
** Or, a topology with elements associated with ISIS Flex-Algo 128 and do not include resource-affinity blue

[Jie]  In the last case, why use Flex-Algo with an additional rule of include-affinity blue? The include rule can be defined as part of the Flex-Algo.

[Pavan] Good question (was expecting someone to ask this; brownie points are in order)! Yes, you could always place as many constraints as you want in your Flex-Algo definition (FAD). But we are talking about TE path computation profiles here -- the number of TE path computation profiles used in a network need not be "limited" by the number of FADs deployed in it. When a Flex-Algo ID is passed in as part of the computation profile of an SR path to a path compute engine, an implementation may merge the constraints in the associated FAD with "other" specified constraints and then come up with an appropriate path (the SIDs of the Flex-Algorithm are used where applicable to compress the resultant path).

[Jie #2] Thanks for your explanation. My understanding is FAD is defined for the network nodes to perform constraint based path computation in a distributed manner. While the merge of constraints in FAD and “other” specified constraints can only be used for centralized TE path computation, as the merged constraints cannot be used for distributed computation by the network nodes which only take the constraints in FAD in consideration of the computation, this means the computed TE path can only be a strict explicit path. Is my understanding correct? IMO this loses the major benefit of the Flex-Algo mechanism and does not need to be based on Flex-Algo.


And what does “resource-affinity” mean in a topology filter?

Resource Affinity == Admin group ([RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!Wf63bNr9BsYF3NyuMHU51LlImOftv9m46EjW6Sl_v-ePYK0WjHXlEnRjb6z3fYS2$>], [RFC5329<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5329__;!!NEt6yMaO-gk!Wf63bNr9BsYF3NyuMHU51LlImOftv9m46EjW6Sl_v-ePYK0WjHXlEnRjb9gfGNqM$>], [RFC5305<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5305__;!!NEt6yMaO-gk!Wf63bNr9BsYF3NyuMHU51LlImOftv9m46EjW6Sl_v-ePYK0WjHXlEnRjb33V9PD-$>] and [RFC7308<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7308__;!!NEt6yMaO-gk!Wf63bNr9BsYF3NyuMHU51LlImOftv9m46EjW6Sl_v-ePYK0WjHXlEnRjb01y_A-E$>]).

[Jie #2] Understood, in this case Admin group maybe be a better term.



(b) Specification of filter-topology associated with a Network Resource Partition

[Jie] Topology-filter and filter-topology sounds confusing to me. How about simply say “specification of the topology associated with a Network Resource Partition”?


[Pavan] Ok. I was specifying a use-case using a term that is currently specified in draft-ietf-teas-ietf-network-slices-05; We will address terminology policing comments (if any) after the use-case section is published in the draft.

[Jie #2] OK, and agree that terminology policing and alignment is needed.

Best regards,
Jie

Best regards,
Jie

/Loa
--

Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>
Senior MPLS Expert                          loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas