Re: [Pce] Proposal for signaling ECMP or UCMP paths
Cyril Margaria <cyril.margaria@gmail.com> Fri, 19 July 2019 16:23 UTC
Return-Path: <cyril.margaria@gmail.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 E67C0120854 for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 09:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fHCa_SS5_cz5 for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 09:23:32 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 73FB9120850 for <pce@ietf.org>; Fri, 19 Jul 2019 09:23:31 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id r12so189358edo.5 for <pce@ietf.org>; Fri, 19 Jul 2019 09:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=50HdY6mKruYAB/nROk014h+EqQP0ArWklAGJAZWFk38=; b=F8gZJk6kmnIgPaGiU9Se1n0eKD76rdxM6wDJO+IiJZLVIQ6B4H1zN7aCqvaSdR5bQ2 YHcE3BdM5xMT9N8ihFATtdfcOsEsDCA6yR4BAJw7tHx+hu6zmeH4f14Uhgn5/+pC0VdK 44JvPDWvJRTr1xvkM27u5Xj0W6GkWwcft+5w1T1teFqfuqDCuWu/Z3Nww0sCv0Ntnh53 R75ZdeM62vNqLTDVbqzF7UNr0WxJbgPE/W6TBAxW88908cGsJJvcf28oPjL/OLCVOpwU SEnFj0o78MAQqLlTIboqxKUXMpVVuPgAQi1kwcnQ3zdxiHno2ARk/hPqDOF49tSBhCrc y9rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=50HdY6mKruYAB/nROk014h+EqQP0ArWklAGJAZWFk38=; b=YTVSRMqodiFe2ZgxCfflKj7wb4072NSvNlagHtIQubGsxBzotYzJYZJKv/i+hxApEf XNNO64U7JroVgy6u5rpvdGPZDBv2np8PNu+2GmcTtNuCBaploTH2D3t6Va9nIoDbA73m sPwXGmzwkUmRbJsnRQ3ACNIs+vFTe0OiXRqmGQ1sNr6gZu9gXcn9zxxqDb4pBpcgu2Nd GLwY/q/bIo0f543pDJUn/7S2qmCj0pKtVtFLJldjteM+iOMk4kZA8VkOA2/QMidJMx4s WgiJv2KjZK60MHEJxyUWWWr1IRwSonKy1af3sl1D3G7uM1ufOQf1Pgw9uPZfqP08XvW7 trhg==
X-Gm-Message-State: APjAAAXLK6RXGGNNO5Xs7KtFjsNwyWb50L+/3JjeOM4aNAfzYfpYnHfn avolSE8PuH+zxG9KiHsngSFODVWGMPftj/AhkIw=
X-Google-Smtp-Source: APXvYqz2Y4J++mQFnLzuDXiw9IaxeR9hrpAvWEqwIBqqhhtrt/+/Jj731iytoehIwFPeh5oQAJ0yif5rG+N35/3AdIg=
X-Received: by 2002:a17:906:3e88:: with SMTP id a8mr41306091ejj.206.1563553409704; Fri, 19 Jul 2019 09:23:29 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR11MB0051E72151F46F5690CEAE9AD3F20@BN6PR11MB0051.namprd11.prod.outlook.com> <CADOd8-s9v9MT7t6tVhkv-HM7sM7ZQJNEiy4CTKGLg-i88Do0YQ@mail.gmail.com> <BN6PR11MB00512B2043AD08E058F9498FD3CB0@BN6PR11MB0051.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB00512B2043AD08E058F9498FD3CB0@BN6PR11MB0051.namprd11.prod.outlook.com>
From: Cyril Margaria <cyril.margaria@gmail.com>
Date: Fri, 19 Jul 2019 17:23:16 +0100
Message-ID: <CADOd8-sLi-CzGEd-bDQKzgp=VyOmCRQ42xFhvAvp9EwEF_iRbw@mail.gmail.com>
To: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
Cc: "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092a7bc058e0b25da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/85Pkg1332pUhKIzLW3JyDpy8zfA>
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 16:23:35 -0000
Hi Mike, One of my point is that one optimization is a peculiar case of n optimization. For the particuliar case of candidate path, it can be attached to a given association, each TE-LSP can have the same optimization criterias. I understand the argument for Option 2 as "I want to carry and manage my constraint (and candidate path) as one PCEP entity", the drawback is that it will become complicated in case of inter-domain and OAM which are per path. The case for option 1 is one path, one LSP, but as you pointed out it becomes complicated when there is one candidate path that desire a behavior similar to LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed. I think that option 1 is better in term of protocol reuse and will offer more flexibility, but that depends on how to deal with the PCE-managed number of paths. I will not attend the IETF meeting, Best regards, Cyril On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) <mkoldych@cisco.com> wrote: > 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> 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 > https://www.ietf.org/mailman/listinfo/pce > >
- [Pce] Proposal for signaling ECMP or UCMP paths Mike Koldychev (mkoldych)
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Cyril Margaria
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Mike Koldychev (mkoldych)
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Cyril Margaria
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Mike Koldychev (mkoldych)
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Mike Koldychev (mkoldych)
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Mike Koldychev (mkoldych)
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Jeff Tantsura
- Re: [Pce] Proposal for signaling ECMP or UCMP pat… Stone, Andrew (Nokia - CA/Ottawa)