Re: [spring] Comments on draft-ietf-spring-segment-routing-policy (ver 03)

Vishnu Pavan Beeram <> Fri, 26 July 2019 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A3C0120283; Thu, 25 Jul 2019 20:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vmMY-gUkoiHv; Thu, 25 Jul 2019 20:30:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23A2112028A; Thu, 25 Jul 2019 20:30:03 -0700 (PDT)
Received: by with SMTP id x3so36136778lfc.0; Thu, 25 Jul 2019 20:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <>
In-Reply-To: <>
From: Vishnu Pavan Beeram <>
Date: Thu, 25 Jul 2019 22:29:50 -0500
Message-ID: <>
To: Przemyslaw Krol <>
Content-Type: multipart/alternative; boundary="000000000000507c77058e8d28e6"
Archived-At: <>
Subject: Re: [spring] Comments on draft-ietf-spring-segment-routing-policy (ver 03)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

If the sub-candidate path is explicit, the specified weight translates to
the weight of the corresponding segment-list.


On Wed, Jul 24, 2019 at 1:23 PM Przemyslaw Krol <> 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 <
>> 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
> --
> Przemyslaw "PK" Krol |  Strategic Network Engineer ing |