IETF Logo Mail Archive

[spring] SID Related Algorithm in draft-peng-idr-segment-routing-te-policy-attr

liu.yao71@zte.com.cn Wed, 30 March 2022 09:04 UTC

Return-Path: <liu.yao71@zte.com.cn>
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 A81863A17C3; Wed, 30 Mar 2022 02:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 qkq-IzsIlYEC; Wed, 30 Mar 2022 02:04:17 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694243A17A3; Wed, 30 Mar 2022 02:04:17 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4KT0qM3qvZzBvnwv; Wed, 30 Mar 2022 17:04:15 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 22U93oDH077063; Wed, 30 Mar 2022 17:03:50 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 30 Mar 2022 17:03:50 +0800 (CST)
Date: Wed, 30 Mar 2022 17:03:50 +0800
X-Zmail-TransId: 2afb62441cf6fffffffff91-b3731
X-Mailer: Zmail v1.0
Message-ID: <202203301703500769671@zte.com.cn>
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: spring@ietf.org
Cc: idr@ietf.org, ketant.ietf@gmail.com
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl1.zte.com.cn 22U93oDH077063
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62441D0F.001 by FangMail milter!
X-FangMail-Envelope: 1648631055/4KT0qM3qvZzBvnwv/62441D0F.001/10.30.14.238/[10.30.14.238]/mse-fl1.zte.com.cn/<liu.yao71@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62441D0F.001/4KT0qM3qvZzBvnwv
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NHsissUWbak5EqRhswutqLWiwr4>
Subject: [spring] SID Related Algorithm in draft-peng-idr-segment-routing-te-policy-attr
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: Wed, 30 Mar 2022 09:04:29 -0000

Hi all,

We presented https://datatracker.ietf.org/doc/draft-peng-idr-segment-routing-te-policy-attr  on IDR's session last week. 
This document defines two kinds of new Segment Sub-TLVs to carry SID related algorithm when delivering SR Policy via BGP. One is for SR-MPLS adjacency with algorithm, another kind is defined for carrying the algo along with the SR-MPLS or SRv6 SID value.

While we believe that the former kind is necessary, considering draft-ietf-lsr-algorithm-related-adjacency-sid complements that in scenarios where multiple algorithm share the same link resource, the algorithm can be also included as part of an Adj-SID advertisement for SR-MPLS. 
We'd like to request the WG's opinion especially about the delivering SR-MPLS or SRv6 SID value with optional algorithm. (Thanks for Ketan's suggestion about this.)
Segment Sub-TLVs carrying SID value with optional algorithm are defined in this draft because we think it may benefit the scenarios below:
Scenario 1: For verification purposes. The headend can check if the SID value and the related algorithm received can be found in its SR-DB if requested to do so.
Scenario 2: The headend may not know about the SID-related algorithm especially in the inter-domain scenario.  Providing the algorithm  info benefits troubleshooting and network management.

Any comments and suggestions are welcome.

Thanks,
Yao

v2.23.0 | Report a Bug | By Email