[Teas] Generalizing the inter-domain SR-TE description in draft-ietf-teas-actn-poi-applicability-06

Italo Busi <Italo.Busi@huawei.com> Wed, 01 June 2022 16:59 UTC

Return-Path: <Italo.Busi@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 0A3B4C14F749 for <teas@ietfa.amsl.com>; Wed, 1 Jun 2022 09:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhbGlTkAQ7ky for <teas@ietfa.amsl.com>; Wed, 1 Jun 2022 09:59:39 -0700 (PDT)
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 6C795C14F741 for <teas@ietf.org>; Wed, 1 Jun 2022 09:59:39 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LCwMk0lvzz67ZtJ for <teas@ietf.org>; Thu, 2 Jun 2022 00:58:42 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 1 Jun 2022 18:59:35 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2375.024; Wed, 1 Jun 2022 18:59:35 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Generalizing the inter-domain SR-TE description in draft-ietf-teas-actn-poi-applicability-06
Thread-Index: Adh12KQJKk3XzUn8THuqPJ9pY8xQtw==
Date: Wed, 01 Jun 2022 16:59:35 +0000
Message-ID: <52ff58d47359421b8a2598e129cc316c@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.205.96]
Content-Type: multipart/alternative; boundary="_000_52ff58d47359421b8a2598e129cc316chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/CjulOXJK6jTG0JtDsSsWRUbyIBs>
Subject: [Teas] Generalizing the inter-domain SR-TE description in draft-ietf-teas-actn-poi-applicability-06
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 01 Jun 2022 16:59:42 -0000

Dear TEAS WG,

during the TEAS WG session in IETF 113, it has been proposed to generalize the inter-domain SR-TE description in draft-ietf-teas-actn-poi-applicability-06 to cover also other options for inter-domain TE.

In particular it has been suggested to generalize the description of the procedure identifying the few technology-specific attributes that are required.

The current draft is focusing on the inter-domain SR-TE because the operators actively contributing to the ACTN POI draft consider this a promising approach for future deployments.

It is worth noting that the procedure described in the draft-ietf-teas-actn-poi-applicability-06 is assuming that the TE tunnel model, under definition in draft-ietf-teas-yang-te, can be used, with SR-TE technology specific extensions, at the MPI to trigger the setup of SR-TE paths.

The authors/contributors are planning to generalize the procedure description, as suggested, to make it applicable to any technology to which the TE tunnel model, under definition in draft-ietf-teas-yang-te, applies at the MPI to trigger the setup of TE paths.

For intra-domain TE, the same procedure can be used, with few technology-specific differences, with SR-TE and RSVP-TE domains.

However, we have not found any packet technology, other than SR-TE, that could realistically use the TE tunnel model for inter-domain TE configuration.

Some implementation issues have been identified with using the TE tunnel model for configuring LSP stitching between two RSVP-TE domains:
- the BRs should be able to stitch between a static LSP segment and a dynamic LSP segment, but this feature is not (widely) available on IP routers;
- an alternative approach could be to setup an RSVP-TE session (with an IGP instance) between the adjacent BRs, but this approach is not practical in real network deployments.

Based on the feedbacks from the operators actively contributing to the ACTN POI draft, a more common deployment scenario applicable in today's network for inter-domain paths is relying on BGP-LU.

The authors/contributors think that this option for inter-domain TE is very cumbersome since it requires multiple loopbacks, BGP-LU, static routes, etc. and that the TE tunnel model, under definition in draft-ietf-teas-yang-te, is  not applicable in this scenario. Therefore, it seems not possible to generalize the procedure described in draft-ietf-teas-actn-poi-applicability-06 to cover also this scenario.

In order to avoid boiling the ocean describing too many options/scenarios within the same document, the authors/contributors would prefer to leave the description of the BGP-LU option outside the scope of this document and would appreciate feedbacks from TEAS WG about this proposal.

Italo (on behalf of co-authors/contributors)