Re: [Pce] Proposal for signaling ECMP or UCMP paths

"Mike Koldychev (mkoldych)" <mkoldych@cisco.com> Fri, 19 July 2019 15:51 UTC

Return-Path: <mkoldych@cisco.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED71206C6 for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 08:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=k4IdLPV3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=euqEkFVW
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 O1Guh0kipkpB for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 08:51:35 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3170120697 for <pce@ietf.org>; Fri, 19 Jul 2019 08:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20626; q=dns/txt; s=iport; t=1563551495; x=1564761095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ig4Rql+z/QAVQOKMZAsmXta+Z6nXk5kfVjNLro96VmI=; b=k4IdLPV3IyqvdE/rQwqIqSvYIBN3jQz6IuDxBwtdD/1HWDhrcXNKxxgT fj5HWs7Q7lrkdutbzFTt2AZZU+b6OcYLZS5SZHfpNLbKkMUVhdswyk2Bh UOu2Jk90N2CmM0/JusvrWkNYRgTrSriIjBvh5sXTnG+gT+CCAnpA2/Hqe c=;
IronPort-PHdr: 9a23:C7wXBRX+dWzw2S+D2ka5lwjbxOvV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank/H8NGWE5u/1mwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ByAAC45jFd/5pdJa1mHAEBAQQBAQcEAQGBVAYBAQsBgRQvUANtVSAECyqEHYNHA417gluJVIknhFWBLoEkA1QJAQEBDAEBGAEMCAIBAYRAAheCOyM1CA4BAwEBBAEBAgEGbYUeDIVKAQEBAQECAQEQEQoTAQEsCwEPAgEIEQQBASgDAgICHwYLFAkIAQEEDgUIEweDAYEdTQMdAQ6gQQKBOIhgcYEygnkBAQWBMgGDSA0LghMDBoE0AYteF4FAP4EQAUaCHi4+ghpHAQEBgTooJAcJglUygiaOeIR+iGuNRkAJAoIZhliJQIQPgi2HJY44hCKQW4F1jhMCBAIEBQIOAQEFgVICNCoagRRwFTuCbIJCg3GFFIU/coEpi3SCUQEB
X-IronPort-AV: E=Sophos;i="5.64,283,1559520000"; d="scan'208,217";a="587670522"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jul 2019 15:51:31 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6JFpVdl019855 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Jul 2019 15:51:31 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 10:51:30 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 11:51:30 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 19 Jul 2019 10:51:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J+PCrMqcsUkZdIIFdLR3VtqQbf+q4/1KvGwmF/7io03yU5ETtfKZQTxNV3VxTluAxmB0ut8ZlUvst50UUUQDRIThkL4bUh0Wx59J9mYUm+U8rjP/jpKJ5tjUP7/EFR1ttZi/Z1H//6GqRW/sXMKfdqskZCz4qc3MkeqHZqC17+bD9qpZqQe+0V2kT5Rf3Kmim75VGCEUcJrKYNcBWrbXVpzDpHxk6CvYJpqbNlNR+t7WPlQUv0KHqXXpgOv3eh5HUurlMCINitpX6Gk3VSEVgmgwrSCX/4fCRFZoI1s4Ae5/e2H33obF8KQ4rRhcXmK1+Rd9I7yNevyvJwxnAIzxDg==
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=Ig4Rql+z/QAVQOKMZAsmXta+Z6nXk5kfVjNLro96VmI=; b=Zh78DTzZtwvrY2InJAFMcerbhWsaiPDpZP8VJnzr3tGNlx1Va5RNrtt+LEoo528RPK5L5iqK9pUGNuBTGfdXiL3xMcZJXCE4HWmwFoyuk2cKPJgAn5ZPOEfcHkxagTRQq14tVDLtDw7EFqHELcno0+/XhKzZ2jQCoRRY8vUKCym2E43aE8T6/39ETBCM9ZrHow0GTAkgqkbX6mTqo3APNCAtG6zfhctylOL1rmcDAXlM+astsNft9qUSBxd3dzTIRleF6LKgXF8GDtELy6QgH3V5XeFQRji7VEsuGe6OYDmKVTs1NxB0sYMbuTU+qL5/rLFqY+PkTAeEZJqq/JgowA==
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=Ig4Rql+z/QAVQOKMZAsmXta+Z6nXk5kfVjNLro96VmI=; b=euqEkFVWLw3SKs/yqn+FU08Pgd/ow5TPS60ozreXTDfsV9+BpQ7emIdHOqFhYS7MCykwqujJZErEVa9LMfowZIg+lPU/n/XJU6oj6r7w9fr9LwfXXuDGPBduw3NcYjAFGEEqImJvTYSLfZ6OPGFp/0uJcJvTYn7foWQd2+76GhU=
Received: from BN6PR11MB0051.namprd11.prod.outlook.com (10.161.153.153) by BN6PR11MB3953.namprd11.prod.outlook.com (10.255.130.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 15:51:28 +0000
Received: from BN6PR11MB0051.namprd11.prod.outlook.com ([fe80::7972:d14b:4c60:adb2]) by BN6PR11MB0051.namprd11.prod.outlook.com ([fe80::7972:d14b:4c60:adb2%3]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 15:51:28 +0000
From: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
To: Cyril Margaria <cyril.margaria@gmail.com>
CC: "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Proposal for signaling ECMP or UCMP paths
Thread-Index: AdU49K/vyO4W8EA5RLe2JmFfCByyTQFQloeAAARryrA=
Date: Fri, 19 Jul 2019 15:51:28 +0000
Message-ID: <BN6PR11MB00512B2043AD08E058F9498FD3CB0@BN6PR11MB0051.namprd11.prod.outlook.com>
References: <BN6PR11MB0051E72151F46F5690CEAE9AD3F20@BN6PR11MB0051.namprd11.prod.outlook.com> <CADOd8-s9v9MT7t6tVhkv-HM7sM7ZQJNEiy4CTKGLg-i88Do0YQ@mail.gmail.com>
In-Reply-To: <CADOd8-s9v9MT7t6tVhkv-HM7sM7ZQJNEiy4CTKGLg-i88Do0YQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mkoldych@cisco.com;
x-originating-ip: [2001:420:2840:1250:f9ef:bdfe:66ff:5a09]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aae1811f-ada6-4e4a-fc7c-08d70c60f692
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR11MB3953;
x-ms-traffictypediagnostic: BN6PR11MB3953:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BN6PR11MB3953FEB42F705FB186088F90D3CB0@BN6PR11MB3953.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(189003)(199004)(8936002)(486006)(66446008)(8676002)(52536014)(64756008)(66946007)(66476007)(256004)(66556008)(316002)(6246003)(14444005)(81166006)(81156014)(5660300002)(68736007)(86362001)(7696005)(6116002)(7736002)(4326008)(76116006)(478600001)(99286004)(76176011)(25786009)(561944003)(6916009)(33656002)(46003)(6506007)(966005)(14454004)(9326002)(71200400001)(229853002)(71190400001)(236005)(74316002)(790700001)(6436002)(606006)(6306002)(54896002)(55016002)(11346002)(9686003)(53936002)(476003)(446003)(53546011)(102836004)(186003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB3953; H:BN6PR11MB0051.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 52uXJF+Q3kO/OlWyueq1SGJavTJJz/bz1FFvFOKbsqIK1E7Pi00DAllU3cN5dIyhYQl9VZ3vE5WC/mjpvxFmPCSzVy9kLuNuTysS+H/QQwQKt6t7p1pT5vklWF4Z6KNCnfcIiZns9S9GcxWBq2pZuFgpPafIaFZT1mKc5xv0IXdsU6GkaWH3VYEHxQ4/YoIP9+wI2sPXZHap2gRQ4j6uCpJm0icSB26Lw7vnwqlOfjstUZ5HRM9yQpjeayipiKyKWCACXhT1Hr9WoykP+6QJGSNXYdRTCww3l/LeeBxeiRxMZS6G/cuMi6x1LVx89SlDv1dhbj4bpGBuZQ+XyYaoEiJXZcoefCQ4AHelfGMMdANdMFH4yadOhV7ZYoQzPvXf0RUtlQRX1LWJ5XiFui9OoYBHewsrMYcHTjVN2OuXCFw=
Content-Type: multipart/alternative; boundary="_000_BN6PR11MB00512B2043AD08E058F9498FD3CB0BN6PR11MB0051namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aae1811f-ada6-4e4a-fc7c-08d70c60f692
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 15:51:28.8866 (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: mkoldych@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3953
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/n1RB7BL4nMmxllDgfMFPJ_InA-c>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2019 15:51:39 -0000

Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a single optimization objective resulting in multiple ECMP/UCMP paths. This is motivated by SR-TE Policy use case, where each Candidate Path represents a single optimization objective. The Candidate Path has a set of Segment Lists that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different optimization objectives and each ECMP path is mapped to a different objective. In that case Solution 1 is absolutely necessary and it would not have any of the down-sides, because the PCC knows in advance how many optimization objectives it has and can create that many PCEP LSPs. However for our problem, Solution 1 would introduce a lot of implementation complexity and protocol overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria <cyril.margaria@gmail.com>
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) <mkoldych@cisco.com>
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs scenarios. This can be used for computing a set of EROs for SR candidate paths, one case that can apply to the candidate path and explicitly mentioned by the RFC is "Two or more end-to-end diverse paths".  This does not cover the stateful PCE case directly, but there are similar situations to what RFC6007 in the form of path protection (primary/secondary/standby) for statefull PCE, which use the association mechanism. Those two existing mechanism exists to coordinate several paths and could be used to indicate how multiple paths are related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be an advantage as its less restrictive. Having the same restriction on a set of paths is easy, relaxing a restriction on the ERO #5 is more complicated (in term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
     a)  set of LSPs can be reported in the same message, it can be enforced by the document defining that specific association type.
     b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful for OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of the traffic does not need to be protected" cannot be expressed (it can be with solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should be disabled for that solution


Slide "Comparison of Solutions":
   - There are solutions to most of the points raised for solution 1
   - The database problem seems specific to one implementation, other implementation will have the problem for solution 2
   -  multi-PCE and multi-domain are not evaluated. Solutions and consideration are available for solution 1, not for solution 2. (experimental Inter-domain P2MP tree solutions exists).

Best Regards,
Cyril

On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) <mkoldych@cisco.com<mailto:mkoldych@cisco.com>> wrote:
Hi WG,

As per SPRING WG, SR Policy may contain multiple Candidate Paths and each Candidate Path may contain multiple Segment Lists. Existing SR standards in PCEP allow only a single ERO (one Segment List) for the SR Path in a stateful PCEP message. There is a need to signal multiple Segment Lists in PCEP for this as well as other load balancing use cases.

See the link that describes this, as well as list possible ways to achieve this. Please provide your feedback on the list or during the WG session.

https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf

Thanks,
Mike.

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