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
>