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

Cyril Margaria <cyril.margaria@gmail.com> Fri, 19 July 2019 13:37 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 3566F1201D9 for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 06:37:17 -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 2gZI4DcEwzZ1 for <pce@ietfa.amsl.com>; Fri, 19 Jul 2019 06:37:14 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 1B7671201D2 for <pce@ietf.org>; Fri, 19 Jul 2019 06:37:14 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id w20so34495249edd.2 for <pce@ietf.org>; Fri, 19 Jul 2019 06:37:13 -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=MKyErSCdpiFQkpMSiFUdKJzMRVS2lwmYwOPNxdOOBEA=; b=YGPo8xaTzWllC1kUapqCVJ9TvxNFAcSnOjzBIO9kNDQsya2MHmoUYd3H2j6/LKKR6T 5MHhReNQmCdJ67doTfj9hypLYcNZyjLAqaajhCIigGFxva19fdv+DFvkaU+fqPBF5Sw+ mriCKARHRn60ficB1aupmWeV/53d/4RRWHDb2Zsal98GjkUsEO0br4bqhVYXqjWMBD2z jHPttr2sjEYHwwOGb0h0E2tXjz6ItAwjZMVSGoXqZtrskjJUB+fNIDJNILMJG943EEik 46zFm9sf1fajZrjzkt1KJm40Lxiwxu5kF6CSce0KN2pYqMkgefq9rL+zaLRU8Q8VGues hgrw==
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=MKyErSCdpiFQkpMSiFUdKJzMRVS2lwmYwOPNxdOOBEA=; b=L30SglS9Sjf29jG872KVds/gZjotEWIwHVMjeqnQuZpx0wBcnApDXxL0gdGkvjWK9F BAWuvFQ8sT7/S7/7k3y4LIqaDIwILsNP1XqTCXT/yh1ByuDi5fQ6tWXKe3BzRq8rqQv0 Z13CgR/R7AQ1gV6eCMvidfmUivBI+dCkpwQBSwky7J8AvgCxsqj5n3JeDKbeJ7wjdS9o h5G/GNQknRG+XmMhsBBJfeCoxjUSf98DfGZMyZ5B3Fjh9RbWSDOurVhsY5mLhb6DPgi0 F9M43amcY8M97PU/BYtYhYAtK/oj/nvF+0eQG4N9e5ZyB7/KhOy0n1OADrY3yfplia3e p2+g==
X-Gm-Message-State: APjAAAWJuh+HyrEiIHCzKrJmvJKJkxDQlnd3t2ri5MB6saX7BfNL/XjS jyybE4CiLdsaWntxtFaPrwwRi3XVLAswTeYBwe4aNWd9WIjUlA==
X-Google-Smtp-Source: APXvYqw7T7FEgQHetrN6O42F8aR82wXlyJQ0q9EB7KJDtReBItOFP4Ax7vJYcynOd966BhiHO23yFhjUsq4KlHNqsh8=
X-Received: by 2002:a17:906:ad82:: with SMTP id la2mr41764545ejb.123.1563543432384; Fri, 19 Jul 2019 06:37:12 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR11MB0051E72151F46F5690CEAE9AD3F20@BN6PR11MB0051.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB0051E72151F46F5690CEAE9AD3F20@BN6PR11MB0051.namprd11.prod.outlook.com>
From: Cyril Margaria <cyril.margaria@gmail.com>
Date: Fri, 19 Jul 2019 14:36:59 +0100
Message-ID: <CADOd8-s9v9MT7t6tVhkv-HM7sM7ZQJNEiy4CTKGLg-i88Do0YQ@mail.gmail.com>
To: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
Cc: "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0d5aa058e08d2f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/h_7Td-R5IErQJpTJlBr7wdUEst0>
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 13:37:18 -0000

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
>