Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 10 November 2020 10:04 UTC

Return-Path: <ketant@cisco.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 7FACB3A0E82 for <spring@ietfa.amsl.com>; Tue, 10 Nov 2020 02:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D66a4w4O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sgO1EqUm
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 Jf2mfM2mv-5v for <spring@ietfa.amsl.com>; Tue, 10 Nov 2020 02:04:20 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFE13A0E7E for <spring@ietf.org>; Tue, 10 Nov 2020 02:04:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81526; q=dns/txt; s=iport; t=1605002660; x=1606212260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=D66a4w4OJ7kpmB89fpH//iKmCozozq2ayARwYHoF0Aofj+zFjH+IXelX ZH/qMLkJIzLV2sOsQ7oTbXsECMGDfrSCtffVjDLkUyDjb3Z0HtB8Wje3X X6IByOfVpNWqyBhjAoqjWUAz2qQUjUoNGeEn3kWQVYPqDiiem3Y8MuR+/ I=;
X-IPAS-Result: =?us-ascii?q?A0B6BwBOZKpffZFdJa1iHQEBAQEJARIBBQUBgg+BIy8jL?= =?us-ascii?q?ntZLy4KhDODSQONVIoVjm2CUwNPBQsBAQENAQEYAQwIAgQBAYQGRAIXgXsCJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGDwglDIVyAQEBBAEBEBEKEwEBI?= =?us-ascii?q?wkLAQsEAgEIEQEDAQEhAQYDAgICHwYLFAMGCAIEDgUIGoMFgX5XAy4BDqI9A?= =?us-ascii?q?oE7iGh2gTKDBAEBBYEzAQMCDkGDCQ0LghAJgTiCc4JlTkKGVxuBQT+BEUOCT?= =?us-ascii?q?z6CG0IBAQIBARWBSAUHHwkCBoJZM4IskCyDOoccjA2QSlQKgm2JDYxwhTWDG?= =?us-ascii?q?IEqiGuSFIIzlVCIe4Juji+EMgIEAgQFAg4BAQWBQSohgVlwFRohgjUBATIJR?= =?us-ascii?q?xcCDYE0jFAbDBeDToUUhUR0AjYCBgEJAQEDCXyMOwGBEAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3AX7S+1BEvCY5+hCqhvwBHz51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208,217";a="585542443"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 10:04:18 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AAA4Ig9012582 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 10:04:18 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 04:04:18 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 04:04:17 -0600
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 05:04:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MWVh4bKBZR7T8y1C+0AopQVBtxDf4TjgzlX6pfD0jugNa/mOb8UnZ3wPbXlwJYpmxPJd7Xsyc/PgV8nyZJEWOsDflArdSG1vcGBtwtiO3RQ9FN401S7j12LDh2uhk3BTOjgER2va1d8Evz3PHX9Mg3asD8/jM2jmtOjo+N7DMM/bEzu/aZpjFTlI56uTzPuyvntUnhvsyQldzKtn9jFpq6fee2qemXNxlSxoPbZJ9z/xxik1/DSoTmAhnB69D1jJCGtIzqcmUXh07NZxajXm5aHHZ/LNtjYR5N2q7UCq1KxmBEA5UHyERqM7k16NYFVNJqFVq5jRHqhIYrkLB11KxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=JSsqirpwDT6qStj7C9aNh4ZW/bwjCEvQ8BKAoeG4IAY/dJlvr8dbVINtVYzaqUgP1UOTT2d1pAMyou6Uy7bwGsUbCaMWjfqXYLMZsOMWVBbDyxlX1q0c39CsvvdvFr21PpFX5MeyaTCr6usr7qmrI5iUdVRyarOurdxovghIijLQYmBSVWA/SUo1XN2PSDQIEqV+W02wrNec6jckCZlij20hPIzxDNrr3wx4iapmVBIQjAlsbQ/32XJPDp4bMZX2UxSPEGAZNG3ebObvc57b4g6kCQqLLlZfkfuire6bKWIgK1sDIpvGKWseZn8cZWLIL65dc5yy2i7BsFLpXSpABg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YytYpgfEPgwdhyfgjKXH/XAp/FgPCopCXfSV1b7Kjco=; b=sgO1EqUmTrtU3w+YYv1c9tOfI7+2beVHeTv373k02zURzBlpC0pmhWNk3vnkNPjaNhKt4K2Jeoh9T3kloimU+q7IPu7Rwpu7NDORxNNKCytwZCyGJsfjcxw3oWCBOsebd6vwjuXb1whzJz0tM8LgEdYtXmW2IlPOUR5PCDRt/Kc=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Tue, 10 Nov 2020 10:04:16 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 10:04:16 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt
Thread-Index: AQHWsLNAvqgyg1iaMU6IIe6qxgFXrqm0BXfggAwoDICAAP2ogA==
Date: Tue, 10 Nov 2020 10:04:16 +0000
Message-ID: <MW3PR11MB4570D601ADC0D8E24B6B2675C1E90@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <MW3PR11MB4570D65A1973363A1A6EF7AEC1100@MW3PR11MB4570.namprd11.prod.outlook.com> <CA+YzgTuqyGvFzx_SBSxx-4y0e0d8FvMhcPzx9b5tzq3F5ayL0A@mail.gmail.com>
In-Reply-To: <CA+YzgTuqyGvFzx_SBSxx-4y0e0d8FvMhcPzx9b5tzq3F5ayL0A@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 784b889f-d97c-4ae2-79a6-08d8855ffbaf
x-ms-traffictypediagnostic: MW3PR11MB4570:
x-microsoft-antispam-prvs: <MW3PR11MB4570CA6F5EA329B0936749C7C1E90@MW3PR11MB4570.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nGUjOqOmL4PgLx/sP1WMfn9KyNBOCQjrXfsTXdf++s6SP+iZUS4x7yIDiYMq14BZAOPfQoHZsmKAxIPkHBglSYO2MftO9zQJeMlvSvss2XFrP0+F7g+WUShMEzGPMBef7Tk4YAUc7sMlqMORogcL7xu0spJ2MOa/Sh4hC9SZdrwu1nc7RJjea0qzvTGJyncWhTC/kTuOnLNxobUG0bOvuBXvRTKsQG6ft1PvbpiNgGP6wQcvMGepjRLmQT59aZ3JGt2z1kVnB1XcV+ZSMSBbGfxUCYUCM7N+LlxRhoIrymNtefjH1oF4uP5572hjl4piszU0nKnwglo3ql1swXe9u/moxnh3GjygMGzWQ5S0OslAFmZNPxpVn3+2+hZI8XnGMdapW1hwsRnsPQZM9nhp7w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(376002)(39860400002)(136003)(366004)(6506007)(53546011)(66446008)(64756008)(76116006)(26005)(16350225007)(86362001)(66476007)(8676002)(55016002)(166002)(71200400001)(66556008)(9686003)(186003)(316002)(66574015)(2906002)(66946007)(478600001)(5660300002)(7696005)(9326002)(6916009)(4326008)(52536014)(966005)(33656002)(8936002)(83380400001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: YfmAwOsy43nqonzbWVFZUOq2rrsVMWIx/yJcRGjoqqmyMV6aR1lLGea+DQUeCkhv8Tl6ri3s6dmsILjEKxKp9kHY1Vpyn18YW/5tocXBCQomJ/VMEYDp1CJvsZBVWg3j9QmuJYr4qVF3PRbV3FlRZiJYpyfdjmNDY/+xy9XntBg16480zos4F/Y/x5N/H2DGooZA7c+rMT2S2w6WD12kIMfeP16l5tSupjivk/G+rRActWDvbwUMY9qLIUj5cibs5NDHEoIk3UIfIykKxr2OC0aSWImwzKKBLxd4sGTEAJkcYHVWc1uHdc60Z37URIVtXET8RGv4OaNLAkSNC0DQZGaRvzSbVmDNlZ53aahCs9IqQRAOi7dT2A5IP396w5fp47R87rjwf7RJ+NOFwgF9F5f76r+gGlffV23q240B5lu1s9g+wRQKt50cu2oZg6/q0Pgax1Zz0RLIS+1VEy5hhKgo/gP8i7WuYgTbA5G1VkMrpppcrVRsBjYsss7vIhczYLzYpev3UwGoc3igKLNNdS7+fx/JE4a5q69tFAUFZQXoC6UVbvUrwNZCf4fySbCaZWneZzKNp7fAoRfchpm+5M7A/7h2wksbaqnN/s5hB+sfltDUus5xAfgpH758HDlC6y6zNTYQlaC1dG9tPGupeOnEWR2BCNykBDw4KqOhrQ0ZSqJHnqQCZ0yiXcMmaXXbvKMZu5FPdqOXd0e/7HVrg/TKZZxrg8Wx1olruH9Pjd0nBKRlTcmQvQj6712ZHpO9urdM5jyfiZ+VtGW5lta6lJsbzx76fOgbxzDppK+Pc0SMHdlBn1ALzN8MlxmVFXUGiY5sGPBO1Ajj8jkd3D/ZkOhKuOGF+rJVSiOT273xd1MlO9YcFytiPQIrFaD8C313cKXu/GeVWMzTbAhZxAtBEg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570D601ADC0D8E24B6B2675C1E90MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 784b889f-d97c-4ae2-79a6-08d8855ffbaf
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 10:04:16.3206 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8EjO4nzSg6StsNWBljeUbJQaPFvyWwQc3C7iAX0/mBxxDQxTgVFH0PPGLEgmpVO976GtOO+6LFoMN9lO0nUZNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4570
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/KseUPF2xrm7rijw7-hDifeJ8Psw>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt
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: Tue, 10 Nov 2020 10:04:24 -0000

Hi Pavan,

Please check inline below.

From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Sent: 10 November 2020 00:08
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: spring@ietf.org
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Ketan,

Much Thanks for taking a stab at addressing the composite candidate path use-case! We seem to be converging.
[KT] Thanks for that feedback and confirmation that the proposal in the draft does address the use-case. I believe we are now discussing the mechanics of how this is achieved within the current SR Policy framework.

However, I don’t understand why you need to use additional SR policies (and unnecessarily burn additional colors) to address this.
[KT] I do not follow what you mean by “burn additional colors”. Color is just a 32 bit number that indicates the “intent” and is not really a scarce resource. Assigning a color to “a composite intent” seems like a seamless way to integrate with existing mechanisms for Steering over SR Policies. This gives the flexibility for say some BGP services to be steered over the constituent explicit/dynamic intent while others can steer over a composite intent that includes those individual explicit/dynamic intents.

Why can’t the composite candidate path just be a grouping of explicit candidate paths and/or dynamic candidate paths?
[KT] This is because in the SR Policy framework, there is only a single active CP – it may be explicit or dynamic. Now we’ve added another Composite CP type to cover this specific use-case. Your proposal will result in 3 candidate paths being active within the same SR Policy – one each of the explicit and dynamic CP and then additionally the Composite CP. This breaks the existing rules for selection of CP based on preference and mechanisms like fallback between CPs. While the current proposal in the draft provides a way to address the new use-case with a backwards compatible extension to the SR Policy framework.

Thanks,
Ketan

Consider the following changes:

** Section 2.2
OLD:

   A composite candidate path acts as a container for grouping of SR

   Policies.  The composite candidate path construct enables combination

   of SR Policies, each with explicit candidate paths and/or dynamic

   candidate paths with potentially different optimization objectives

   and constraints, for a load-balanced steering of packet flows over

   its constituent SR Policies.  The following criteria apply for

   inclusion of constituent SR Policies using a composite candidate path

   under a parent SR Policy:



   o  the endpoints of the constituent SR Policies and the parent SR

      Policy MUST be identical



   o  The colors of each of the constituent SR Policies and the parent

      SR Policy MUST be different



   o  the constituent SR Policies MUST NOT use composite candidate paths



   Each constituent SR Policy of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.



NEW:

   A composite candidate path acts as a container for grouping of

   explicit candidate paths and/or dynamic candidate paths with

   potentially different optimization objectives and constraints.

   The composite candidate path construct enables load-balanced

   steering of packet-flows over a set of constituent candidate

   paths. The following criteria apply for constituent candidate

   paths under a composite candidate path:



   o  the preference of the constituent candidate path MUST be

      ignored.



   o  the constituent candidate path MUST NOT be a composite candidate

      path



   Each constituent candidate path of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.



**



** Section 2.11



OLD:
   When a composite candidate path is active, the fraction of flows
   steered into each constituent SR Policy is equal to the relative
   weight of each constituent SR Policy.  Further load balancing of
   flows steered into a constituent SR Policy is performed based on the
   weights of the Segment-List of the active candidate path of that
   constituent SR Policy.



NEW:
   When a composite candidate path is active, the fraction of flows
   steered into each constituent candidate path is equal to the relative
   weight of each constituent candidate path.  Further load balancing of
   flows steered into a constituent candidate path is performed based on
   the weights of each associated Segment-List.


**



** Section 2.13



OLD:
   The information model of SR Policy POL100 having a composite
   candidate path is the following:

   SR policy POL100 <headend = H1, color = 100, endpoint = E1>
        Candidate-path CP1 <protocol-origin = 20, originator =
   100:1.1.1.1, discriminator = 1>
            Preference 200
            Weight W1, SR policy <color = 1>
            Weight W2, SR policy <color = 2>

   The constituent SR Policies POL1 and POL2 have information model as
   described at the start of this section.  They are referenced only by
   color in the composite candidate path since their headend and
   endpoint are identical to the POL100.  The valid Segment-Lists of the
   active candidate path of POL1 and POL2 are installed in the
   forwarding.  Traffic steered on POL100 is flow-based hashed on POL1
   with a ratio W1/(W1+W2).  Within the POL1, the flow-based hashing
   over its Segment-Lists are performed as described earlier in this
   section.



NEW:
   The information model of SR Policy POL100 having a composite
   candidate path is the following:

   SR policy POL100 <headend = H1, color = 100, endpoint = E1>
        Candidate-path Comp-CP <protocol-origin = 20, originator =
   100:1.1.1.1, discriminator = 1>
            Preference 200
            Weight W1, Candidate-path CP1
            Weight W2, Candidate-path CP2
        Candidate-path CP1 <protocol-origin = 20, originator =
   100:1.1.1.1, discriminator = 2>
             Weight W11, SID-List1 <SID11...SID1i>
             Weight W12, SID-List2 <SID21...SID2j>
        Candidate-path CP2 <protocol-origin = 20, originator =
   100:1.1.1.1, discriminator = 3>
             Weight W21, SID-List3 <SID31...SID3i>
             Weight W22, SID-List4 <SID41...SID4j>

   Comp-CP is a composite candidate path with two constituents, CP1
   and CP2. The preference is ignored for each of the two constituent
   candidate paths. The valid Segment-Lists of the two constituent
   candidate paths are installed in the forwarding. Traffic steered
   on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of
   W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent
   candidate path, the flow-based hashing over its Segment-Lists are
   performed as described earlier in this section.


**



** Section 5.3



OLD:
   A composite candidate path is specified as a group of its constituent
   SR Policies.

   A composite candidate path is valid when it has at least one valid
   constituent SR Policy.



NEW:
   A composite candidate path is specified as a group of its constituent
   candidate paths.

   A composite candidate path is valid when it has at least one valid
   constituent candidate path.


**



Regards,

-Pavan



On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hello All,

We have just posted an update for the draft and following is the summary of changes:

1) Introduction of the Composite Candidate Path construct to address a pending comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
2) Based on offline feedback received, updated SRv6 segment types to include optional SRv6 SID and behavior instead of the new type that was introduced for it in the v08.
3) Clarification of handling of colors and BGP multi-path scenarios based on offline feedback received.
4) Clarification on considerations for TI-LFA for SR Policy as discussed in the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

Please let know your comments/feedback.

Thanks,
Ketan (on behalf of co-authors)

-----Original Message-----
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: 02 November 2020 06:27
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : Segment Routing Policy Architecture
        Authors         : Clarence Filsfils
                          Ketan Talaulikar
                          Daniel Voyer
                          Alex Bogdanov
                          Paul Mattes
        Filename        : draft-ietf-spring-segment-routing-policy-09.txt
        Pages           : 37
        Date            : 2020-11-01

Abstract:
   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path.  Intermediate per-flow states are eliminated thanks
   to source routing.  The headend node steers a flow into an SR Policy.
   The header of a packet steered in an SR Policy is augmented with an
   ordered list of segments associated with that SR Policy.  This
   document details the concepts of SR Policy and steering into an SR
   Policy.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-09


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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