Re: [spring] Comments on draft-ietf-spring-segment-routing-policy (ver 03)
Vishnu Pavan Beeram <vishnupavan.ietf@gmail.com> Fri, 26 July 2019 03:30 UTC
Return-Path: <vishnupavan.ietf@gmail.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 4A3C0120283; Thu, 25 Jul 2019 20:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 vmMY-gUkoiHv; Thu, 25 Jul 2019 20:30:03 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 23A2112028A; Thu, 25 Jul 2019 20:30:03 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id x3so36136778lfc.0; Thu, 25 Jul 2019 20:30:03 -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=dSvnCK7i1idhxU1ZGHS4/FMZAW261gYXQSJ0kn+/idE=; b=j3oONyiYnblYmCswZO2G9hAgEJx1CaVMUoecQlJ6e/hPjiTbFM9cXydd2yeI3sbCpz hMm+KHaqDzFaxa5/sJ00rZfJifJR8L2GNGtgDC2mV+aZIO0dD5sjPj15WSpB1rdpUvVK SDPsFc8rPwdVllOmchgU3Tzr3uLTgx8jtb+ByMKcr64/UyvzQTnGrOaNSH1L2LWD71m6 bOSq2SRUPv65LbKIShG58DtayOnmbZZ/BXaAEeyqT5xH+Bwu70QuajJLm1qTvir+9AdB 1GN96v6j0ynzeVXUJxdJiLgn/uiMqOFq0zyiFTeJizE1inMfMvYWwlizz1LEobgku4Sh uixg==
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=dSvnCK7i1idhxU1ZGHS4/FMZAW261gYXQSJ0kn+/idE=; b=MSbXaMGwR8Do/p5Jhn/N0BXZD2vpnrYgQ92fFXIAhS9byO/P7FQY+hgAV1Q7XG3Urk Re3UChSbSRdu4XoJzH5wxsfY6h+Gxkri4Xyk6SGUqJEUCOTi3lNw1OOqr19maswJ3dMf r43TIFWXd1dAv0c6QUuaYtyHN+R1n884Rinx9MdGN/qlaerLlDgEg9l4ZDPL5EUxh14f XKbArQ2DOuJidWoK7gyJZrz8AhKWzBcrAwHEUmGIyLiWTLv5GT9UvTcQ3C3dG5NOBm6k QD3t4TDNXJh3yxVr9X++E+OPY4Usg7NHTbYafNLGgLd4D6dvBYR8t+7wAKgi4UiOD37p vjbA==
X-Gm-Message-State: APjAAAVeO9C2Cupp3SpSQ8GwtIQn5FDYCawn03eGpPqgAIOfGqWFHWkN qcrJMoQDEsEzAKs0h7HpMAd1tcWGr+1UOzrYsw0=
X-Google-Smtp-Source: APXvYqy/6tYhNQ/Byrv6QnedH6n0O0jkLygaphV3/XbxpUVZxBZP9n/mgf+gT/c0rSzcUnJ6DtS6Wx7q4+cIO0kJ3WI=
X-Received: by 2002:ac2:4c84:: with SMTP id d4mr641729lfl.1.1564111801446; Thu, 25 Jul 2019 20:30:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAMoPOhk9vgMas6p8TxLTgXHV5_03hHX7XnE=N+7EEFaxFctfKg@mail.gmail.com> <CACH2EkVwNrL7=dqUbBZW2Z+Z9VS-tE5VXyCZ--0-faibOxr08w@mail.gmail.com>
In-Reply-To: <CACH2EkVwNrL7=dqUbBZW2Z+Z9VS-tE5VXyCZ--0-faibOxr08w@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan.ietf@gmail.com>
Date: Thu, 25 Jul 2019 22:29:50 -0500
Message-ID: <CAMoPOhkngEHYezRpGZmOwZTOCxpPorTzNjqWM8JvsTQjTxZnfw@mail.gmail.com>
To: Przemyslaw Krol <pkrol@google.com>
Cc: draft-ietf-spring-segment-routing-policy@ietf.org, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000507c77058e8d28e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws>
Subject: Re: [spring] Comments on draft-ietf-spring-segment-routing-policy (ver 03)
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: Fri, 26 Jul 2019 03:30:08 -0000
I synced up with PK in-person this morning and clarified his questions. I'm reproducing my response here on the list to keep record. The weights are specified per sub-candidate path. If the sub-candidate path is dynamic, the specified weight is distributed across the set of segment-lists as dynamically computed by the compute-engine. So for example, if the specified weight for the dynamic sub-candidate path is 3 and the computation result yielded 3 equal cost segment-lists, then the weight associated with each segment-list would be 1. If the sub-candidate path is explicit, the specified weight translates to the weight of the corresponding segment-list. Regards, -Pavan On Wed, Jul 24, 2019 at 1:23 PM Przemyslaw Krol <pkrol@google.com> wrote: > Hi Vishnu, > > Clarification question, if I may. > Are you envisioning weights to be normalized for all sub-candidate-paths > (regardless of the candidate-path they belong to), or rather propose to > have a 2-level split: > - weight for candidate-path grouping specific sub-candidate-paths defining > "global" share of traffic, in comparison with other candidate-paths > - weight for specific sub-candidate-path defining "local" share of the > traffic within specific candidate-path, in comparison with other > sub-candidate-paths in that particular candidate-path > > thanks, > pk > > On Wed, Jul 24, 2019 at 6:42 AM Vishnu Pavan Beeram < > vishnupavan.ietf@gmail.com> wrote: > >> Authors, Hi! >> >> There are some use-cases where the candidate-path (multipath) needs to be >> constructed in such a way that a part of the multipath (a set of >> segment-lists) uses one set of constraints, while the other part (another >> set of segment-lists) uses another set of constraints. Consider the >> scenario where the traffic needs to be steered onto a policy in such a way >> that a specified portion of it uses paths that traverse only blue links >> while the rest uses paths that traverse only red links. >> >> The current semantics of a candidate-path as defined in Section 2.2 of >> version 3 preclude such use-cases. It should be possible to let the >> semantics be a tad more flexible than they currently are and cater to the >> above scenario (and the likes of it). >> >> There are a few different ways of addressing this, but I would like to >> propose one that seems least disruptive. >> >> In addition to the currently specified semantics: >> -- A candidate path may comprise of a set of sub-candidate paths where >> each each sub-candidate path is either dynamic or explicit. The >> sub-candidate path is the unit of signaling of an SR policy between a >> headend and a controller.. >> >> Regards, >> -Pavan >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > > -- > Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com >
- [spring] Comments on draft-ietf-spring-segment-ro… Vishnu Pavan Beeram
- Re: [spring] Comments on draft-ietf-spring-segmen… Przemyslaw Krol
- Re: [spring] Comments on draft-ietf-spring-segmen… Vishnu Pavan Beeram