Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

bruno.decraene@orange.com Thu, 24 February 2022 11:17 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279713A0EA5 for <spring@ietfa.amsl.com>; Thu, 24 Feb 2022 03:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 wyxOsOvZ2kHE for <spring@ietfa.amsl.com>; Thu, 24 Feb 2022 03:17:22 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50FE3A094B for <spring@ietf.org>; Thu, 24 Feb 2022 03:17:21 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4K49Nc0Nf8zys5 for <spring@ietf.org>; Thu, 24 Feb 2022 12:17:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645701440; bh=KnqQQ/2ISC14/jSqxcn04T4VyaJi7krH/ShaXojMjb8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=oWVSRapjY8OuOrtIkEergrx1LnmQzIEgSuBfDoDpEx5jPxXuK4A9Eam0eUDYREAT9 Pi9i8mW5hHDs1IFt3fjyhGv1USV6dLyMULDfv3jhV/nXCoiEh2zOCzalkJmWWaM7OT 7tzNuxLt2FP28X22Oag+x+1mJuxVuPtjE/90B6spikxHgPrskA6qzQLkRYkzx7PlzB 37V8gHcmrNm2PAZ95djU7cWPCsY1usIodE4kBgTF4sT5eIajPtZxlbmu6gwc1xhG+c IWHiPUt9YI8BKGgrDyxeVWyLe6QJLPzonIbm2XEQey/RjnkYxs+jTg4Yc3VIk4bkOc dGGkWCLQBPUvQ==
From: <bruno.decraene@orange.com>
To: SPRING WG <spring@ietf.org>
Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAhCCJgA
Date: Thu, 24 Feb 2022 11:17:19 +0000
Message-ID: <16252_1645701439_6217693F_16252_172_1_261dad9f8f154ff299920b2359f7d4d9@orange.com>
References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com>
In-Reply-To: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-24T11:17:16Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-24T11:17:16Z
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: e8585005-f643-4c48-b963-343668e6d7c5
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: [10.115.27.51]
Content-Type: multipart/alternative; boundary="_000_261dad9f8f154ff299920b2359f7d4d9orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/_e7gCFQSNcNE-JrVPIFuXxrradU>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2022 11:17:27 -0000

Dear WG,

Thank you for all comments received during this WG last call and for the detailed review of the document.

In term of requirement, there is support for the need to protect SR-Policy traffic from node failure both:
a) for the protection/FRR duration (from failure detection to the start of the IGP convergence)
b) during the subsequent IGP restoration (from the beginning of the IGP convergence in the routing domain to the end of the re-computation and installation of SR-policy on all ingress).

"a" is addressed by [2], with the exception of binding SIDs.

Regarding "b", in term of the solution, two aspects have been discussed:
I) the relation with the solution proposed in [2]
II) the IGP extension for Proxy Forwarding proposed in [1]

[1] https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-proxy-forwarding
[2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths

I) Regarding the relation with the solution proposed in [2]:
- there is a claim that [1] provides better benefits in terms of incremental deployment. During discussions it appeared to be true in some cases but that the increased benefit seems relatively limited
- there has been a claim that [2] already solves the problem. During discussions, it appeared that the solution proposed in [2] does not seem to work as claimed.
- problem space is twofold: a local fast reroute solution "a" and a global IGP rerouting solution "b". In principle, both may be described in a single or two documents.

II) Regarding the IGP extension proposed in [1], the discussion during this adoption call has not clarified the need to define a new IGP extension compared to re-using the existing Mirror SID defined in RFC 8402 (SR Architecture) and RFC 8667 (IS-IS extension).
Authors of [1] are suggested to dig on this point.
In the meantime, the need for a new IGP extension for Proxy Forwarding has not been demonstrated.


Coming back to "a", [1] also covers a solution for the FRR protection of binding SIDs.
The problem seems real for networks using binding SIDs. The document proposes to advertise them in IGP. However, during discussions, it appears that:
- main IS-IS PDU (hello, LSP) are not well suited for the requirements (scope of messages, capability of messages, scaling). During the call, the document has been changed to using CS-LSP which may not be well deployed and does not fully address the IGP scalability point.
- it seems debatable to choose to advertise the backup states in the IGP when the nominal states have not been installed by the IGP but through existing protocols extensions.

Authors of [1] are suggested to dig on this point and study in depth the existing configuration/signaling protocols used to install the nominal path and study how they can be used, including extended if needed, to address the need to install the backup states on the PLR.

In the meantime, the call for adoption of draft-hu-spring-segment-routing-proxy-forwarding is suspended.

Finally, there is the question of whether these different aspects are better addressed in one document or in two documents.
This will be further evaluated by chairs when we'll have a revised [1] document addressing the two requested points. However we note that [1] covers both a global IGP aspect (restoration) and a local restoration aspect (binding SID) hence having two documents based on this dichotomy would not even solve the interactions between the two documents. In addition,  _assuming that [1] does its homework and fully addresses the two above points_, if they wish so, authors of both documents may discuss and may come back with proposals on how to structure the whole solution space.

Yours,
--Bruno, Jim, Joel.



Orange Restricted
From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Dear WG,

This message starts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/

After review of the document please indicate support (or not) for WG adoption of the document to the mailing list.

Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on or review the document, please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on the document.

Thanks!
Bruno, Jim, Joel

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.