Re: [spring] Comments on SR policy

"" <> Tue, 18 August 2020 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05AC23A157A; Mon, 17 Aug 2020 18:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oizYGy1zX5pc; Mon, 17 Aug 2020 18:11:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E80333A1577; Mon, 17 Aug 2020 18:11:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=G3OryM8T3noEroOvc+JKNYbpd82mtLIeKuuR9WMx0H07DYS1fXe+7dPVoo6swxc+02SezXTtQqtHkwnWpfCBXIm43mSRdX6sdPc03OKdsHtdk51msleb07+4iYzYRzdnFIup8YEfAvBEZbfEY7ml+0Hp1pHWTNewC9hTF+Tb3NDa7OLHfux6sj9Fzt0w2q9Cg70RGoM5GJDuK7IxpgHykC8V6/1RxGtqaNTsdj5Ln0Btlw1fMUjIGumAyTDlshl4XCUL9LaJyapnWIhHjeaOiiPrP7ug7ycFnT1VRy/fs3FMWBF1uDCQKLkY3oD7rJX32gOcheeJ/T5bMub5rcrVpw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AyyzDPflMuq2GsD4r7d2SY78P5Ofe/JeRB5mBgpIB3E=; b=VMh6823y3ofaQTLACv2UOpJMQL22GLl1nwS2De/tUzp2dj5RDlyxKXNlV+pVXzA27IDJYOVtXq7uOKN+5gmv2nCycz8u2OWudOCsEvmfEq3VUYtoc17oh7JeupdiGqr2vPoQGzHt/LawvdlrfZn9p9zcgQPNR6dCoBS2yF7JBqOPzPmvfeo+iaCEMhLcVA/+8l99kZVjFXlKqTdpEjCdGCfFYms737ZZokzNcA7Z+vfqq6DJDkY9tHhvB1ECYyAoTyLGeJI4JpkYqpgyWMOnF0HeDwJWpisIeMx8I5dAxbbLKtbtX7yXXX5967K4U8zKEP7WHiGUJbMQtUKxYDB96w==
ARC-Authentication-Results: i=1; 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AyyzDPflMuq2GsD4r7d2SY78P5Ofe/JeRB5mBgpIB3E=; b=nv6XJalM1FSNVK/vL99VS18t8EGFbi5ehKzCWbIpyYniZjwWka1BqpWGt2LIobg6OoAuQu7NWJ2fgMROHDGewBh4ivqea4lbI2u7jIi7H8ui56GMj9QuCV+iP85VEuAvCIdClCTHTG8IiptJK4mIQwrn959e65/bTuDp12F87gcugZfyt6EGJ68V2sLWW4LXwIPr/SR4f1MPa2CXDXiukWTs7n5410sL6PccbGe7U9Cdi3B+thAhhyJN0QzPAByVcBcq7Z0kTDzzJF2BaKRkD46HEaQFiVWd/NlJGIKFX8063aaef/Kcq66EK0iYMl2me+FMIbKxXvBDEjgSK7FH2A==
Received: from (2a01:111:e400:7ebc::40) by (2a01:111:e400:7ebc::463) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Tue, 18 Aug 2020 01:11:35 +0000
Received: from (2a01:111:e400:7ebc::4f) by (2a01:111:e400:7ebc::348) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Tue, 18 Aug 2020 01:11:35 +0000
X-IncomingTopHeaderMarker: OriginalChecksum:D618F4242FA4955CF4AF27E3819B29D3E431F3A25A2AFB367D644B6793D96AEA; UpperCasedChecksum:CC4B3D9A5C2AB5CE13CCCA2A5A48FD430A4890B8202171ECE8A86C59824B2B96; SizeAsReceived:8889; Count:49
Received: from ([fe80::7c95:91ff:e747:fd8]) by ([fe80::7c95:91ff:e747:fd8%5]) with mapi id 15.20.3305.023; Tue, 18 Aug 2020 01:11:35 +0000
Date: Tue, 18 Aug 2020 09:12:09 +0800
From: "" <>
To: "Ketan Talaulikar (ketant)" <>, "" <>, draft-ietf-spring-segment-routing-policy <>
References: <>, <>
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart288175522243_=----"
X-ClientProxiedBy: (2603:1096:201:20::13) To (2603:1096:203:9d::21)
X-Microsoft-Original-Message-ID: <>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from cmcc-PC ( by (2603:1096:201:20::13) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3283.15 via Frontend Transport; Tue, 18 Aug 2020 01:11:34 +0000
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail[cn]
X-Microsoft-Original-Message-ID: <>
X-TMN: [QjSqWgWGvFb3IyPSxyb3j0UfiCG4tGUP]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 49
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 371e1421-c3b8-4310-e175-08d84313a658
X-MS-TrafficTypeDiagnostic: HK2APC01HT027:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: FlAI2V625PeDOrsC/ngNhOMikjIAwPstVmz2CH2QdOdeJqRygpP5eYUa8nOnVMSZxXIfWTaJ2Gn7DSQtznQhlcxnBL5ZnNhIJKZf3CMzuXo7Y9yguYwBTU4u/iwK8ldN2i8kG5S2/xswRNozyYzUbVOOPArHE9BNz7WVk6diBMmtb3JOqfelgRp33evR9AV4g9+TLwlLGR+QoT9TDoQRcio0LgahB6B9xdQGnMTyf1/5NVwTT+IosD8TLzuMArUD
X-Forefront-Antispam-Report: CIP:; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFS:; DIR:OUT; SFP:1901;
X-MS-Exchange-AntiSpam-MessageData: 0DEzLLiSBt3YkKYkMhObHsReuRqSWVj7Dbs01VB23GmR/S1RC7M59PWn3R1XwVnts1EEXOPjvpN0MYVZGE5xu4Y0pJN3EnKWL+UeuLkuEO1SwJg4eWspi3Q5fzA+X52zvsPMW9w+7IOkeX1nzN2LDg==
X-MS-Exchange-CrossTenant-Network-Message-Id: 371e1421-c3b8-4310-e175-08d84313a658
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 01:11:35.2324 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT027
Archived-At: <>
Subject: Re: [spring] Comments on SR policy
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Aug 2020 01:11:45 -0000

Hello Ketan,

Thank you for your response. 

For question No. 1, I can understand Type E and Type G can be used to present layer 2 interface. Howerver, the method introduced in RFC 8668 is different, in which SID is used to directly indicate the member link of a layer 2 link bundle. When using the segment defined in RFC8668, the headend doesn't need to resolve the IP address and the interface ID specified in Type E or G.

So I think it is better to add one more segment type to contain the segment defined in RFC8668 for layer 2 bundle members.

Best Regards,
Zhenqiang Li
From: Ketan Talaulikar (ketant)
Date: 2020-08-14 19:36
To:;; draft-ietf-spring-segment-routing-policy
Subject: RE: Comments on SR policy
Hi Zhenqiang Li,
Thanks for you review and sharing your comments. Please check inline below.
From: <> 
Sent: 05 August 2020 14:03
To:; draft-ietf-spring-segment-routing-policy <>
Subject: Comments on SR policy
Dear authors and all,
Please consider the following comments.
1. Do you think it is ok to add one more segment type for the segment list to incorporate the segment for Layer 2 bundle members? Please refer to rfc8668.
[KT] The Segment Type E covers Layer 2 Bundle Members :
         This type can also be
         used to indicate indirection into a layer 2 interface (i.e.
         without IP address) like a representation of an optical
         transport path or a layer 2 Ethernet port or circuit at the
         specified node.

2. For per flow steering to a policy, why do we limit the array index to 0 to 7?  I think this is implementation specific and the number of paths in an array depends on the application scenario. I am not sure whether or not 8 paths is enough for all scenarios.
[KT] The draft does not limit the Forwarding Classes to 8. The value 8 is more of an example and comes from Traffic Class [RFC5462] and the IP Precedence portion of DSCP [RFC2474]. The section starts with “Let us assume” and there is also the following text in the same section:    The array index values (e.g. 0, 1 and 2) and the notion of   forwarding-class are implementation specific and only meant to   describe the desired behavior.  The same can be realized by other   mechanisms. 
3. For protection in section 9.1, it is better to add some text like "the local protection may not satisfy the SLA requirements or the path constrains for the policy" when an SR Policy is built on the basis of TI-LFA protected IGP segments.
[KT] Sure. We can add this clarification in the next update.
Best Regards,
Zhenqiang Li