Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 09 November 2020 18:38 UTC

Return-Path: <vishnupavan@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 5AADC3A12BD for <spring@ietfa.amsl.com>; Mon, 9 Nov 2020 10:38:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 sHh_aIJFj7IC for <spring@ietfa.amsl.com>; Mon, 9 Nov 2020 10:38:15 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 BBD953A1250 for <spring@ietf.org>; Mon, 9 Nov 2020 10:38:15 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id n129so10869676iod.5 for <spring@ietf.org>; Mon, 09 Nov 2020 10:38:15 -0800 (PST)
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=nP9Lc44+mY/2ZdsBW4x2BChWx3V7356+HLOJzFLiyjQ=; b=WrQlw4BAANaETemReruocYcYwKiDehBc6/sJq9sOg1jWD7ShkxKrKCUQJ0y+kC8iV/ cRYqGL8IQ+XQuXi9k5Zg+WFVF6KiPf8YCA8opF55iXihnH1R1rKL0MaKyczsY0t0HtgT iIHT/qgcMbHznbpzTW5yh/Up/bsgWZRLKVxJaG3Lh1j9iBP9fAmNvAZhs/EMxCUZ2Ik6 +h4xavdQ2EKLaIJ0WBOckp+ep4AMDDz0DYyEITF8ir6uiM6T5Jd1y7dA8DxAY8uNZNbd Ik/SmNX4QPAxHEZ91Dmeok1asuxGGlmDfr3kPTxJszPuqhm+y9mdtDoJG7NZ4zk6K8VR NPyw==
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=nP9Lc44+mY/2ZdsBW4x2BChWx3V7356+HLOJzFLiyjQ=; b=X/fvlR/oUY2sRuiTHsRtFje5WUnALd3u2SVifqXx3o85ppEucYZ4avSnXkNuSWNskj YBILHj7Y4ybcFJ6YxDXIvSRdkit4kJXEGCQq0IxAI2PjQosJYxqIGc62mkfBISodKRBQ ioMnw2FXI0L9stPNgQl+7NlLVb2TJrvGHuEC9xLOgS61a/KpHcscHMFDq5X7Am/z8ZDP hci8GA3R286ZgRO2AYMUB5wqp6m17CJy/VZRL+7uiyhHG//9y8UpkDfsk44UDEaA/uyW mxAN1YPL1ONa/CaVJe6X63jZpo9ymBbNf9IfKL/38u2YhFPwVSzvPaYbp/MXFmlOHkWC 6hXg==
X-Gm-Message-State: AOAM531H/uymAXnkEWdqU/MU42+pIU4ak/WQhQmOBpmPqThSlQN+9QkS jx1vx7UnR0qqyN8aQZcGCjDjdPqCBC1LLSJG0cg=
X-Google-Smtp-Source: ABdhPJzoQRw7MhD2cDPKkdsSKmdFs2g0AL3zu4sK/j40vJFTvwJJAT6+oyYhdrCSJ7l6+ySnt5DnQe3UDmYiIxGKeS8=
X-Received: by 2002:a05:6602:2c92:: with SMTP id i18mr11337987iow.18.1604947094904; Mon, 09 Nov 2020 10:38:14 -0800 (PST)
MIME-Version: 1.0
References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <MW3PR11MB4570D65A1973363A1A6EF7AEC1100@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4570D65A1973363A1A6EF7AEC1100@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 09 Nov 2020 12:38:03 -0600
Message-ID: <CA+YzgTuqyGvFzx_SBSxx-4y0e0d8FvMhcPzx9b5tzq3F5ayL0A@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Cc: "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000079a4cf05b3b0dd34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/qMpc24j9qMH4y3kidGV5gkKdXJg>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt
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: Mon, 09 Nov 2020 18:38:18 -0000

Ketan,



Much Thanks for taking a stab at addressing the composite candidate path
use-case! We seem to be converging. However, I don’t understand why you
need to use additional SR policies (and unnecessarily burn additional
colors) to address this. Why can’t the composite candidate path just be a
grouping of explicit candidate paths and/or dynamic candidate paths?



Consider the following changes:



** Section 2.2

OLD:

   A composite candidate path acts as a container for grouping of SR

   Policies.  The composite candidate path construct enables combination

   of SR Policies, each with explicit candidate paths and/or dynamic

   candidate paths with potentially different optimization objectives

   and constraints, for a load-balanced steering of packet flows over

   its constituent SR Policies.  The following criteria apply for

   inclusion of constituent SR Policies using a composite candidate path

   under a parent SR Policy:



   o  the endpoints of the constituent SR Policies and the parent SR

      Policy MUST be identical



   o  The colors of each of the constituent SR Policies and the parent

      SR Policy MUST be different



   o  the constituent SR Policies MUST NOT use composite candidate paths



   Each constituent SR Policy of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11>
for details).  The default weight is 1.



NEW:

   A composite candidate path acts as a container for grouping of

   explicit candidate paths and/or dynamic candidate paths with

   potentially different optimization objectives and constraints.

   The composite candidate path construct enables load-balanced

   steering of packet-flows over a set of constituent candidate

   paths. The following criteria apply for constituent candidate

   paths under a composite candidate path:



   o  the preference of the constituent candidate path MUST be

      ignored.



   o  the constituent candidate path MUST NOT be a composite candidate

      path



   Each constituent candidate path of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11>
for details).  The default weight is 1.



**



** Section 2.11



OLD:

   When a composite candidate path is active, the fraction of flows

   steered into each constituent SR Policy is equal to the relative

   weight of each constituent SR Policy.  Further load balancing of

   flows steered into a constituent SR Policy is performed based on the

   weights of the Segment-List of the active candidate path of that

   constituent SR Policy.



NEW:

   When a composite candidate path is active, the fraction of flows

   steered into each constituent candidate path is equal to the relative

   weight of each constituent candidate path.  Further load balancing of

   flows steered into a constituent candidate path is performed based on

   the weights of each associated Segment-List.



**



** Section 2.13



OLD:

   The information model of SR Policy POL100 having a composite

   candidate path is the following:



   SR policy POL100 <headend = H1, color = 100, endpoint = E1>

        Candidate-path CP1 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 1>

            Preference 200

            Weight W1, SR policy <color = 1>

            Weight W2, SR policy <color = 2>



   The constituent SR Policies POL1 and POL2 have information model as

   described at the start of this section.  They are referenced only by

   color in the composite candidate path since their headend and

   endpoint are identical to the POL100.  The valid Segment-Lists of the

   active candidate path of POL1 and POL2 are installed in the

   forwarding.  Traffic steered on POL100 is flow-based hashed on POL1

   with a ratio W1/(W1+W2).  Within the POL1, the flow-based hashing

   over its Segment-Lists are performed as described earlier in this

   section.



NEW:

   The information model of SR Policy POL100 having a composite

   candidate path is the following:



   SR policy POL100 <headend = H1, color = 100, endpoint = E1>

        Candidate-path Comp-CP <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 1>

            Preference 200

            Weight W1, Candidate-path CP1

            Weight W2, Candidate-path CP2

        Candidate-path CP1 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 2>

             Weight W11, SID-List1 <SID11...SID1i>

             Weight W12, SID-List2 <SID21...SID2j>

        Candidate-path CP2 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 3>

             Weight W21, SID-List3 <SID31...SID3i>

             Weight W22, SID-List4 <SID41...SID4j>



   Comp-CP is a composite candidate path with two constituents, CP1

   and CP2. The preference is ignored for each of the two constituent

   candidate paths. The valid Segment-Lists of the two constituent

   candidate paths are installed in the forwarding. Traffic steered

   on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of

   W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent

   candidate path, the flow-based hashing over its Segment-Lists are

   performed as described earlier in this section.



**



** Section 5.3



OLD:

   A composite candidate path is specified as a group of its constituent

   SR Policies.



   A composite candidate path is valid when it has at least one valid

   constituent SR Policy.



NEW:

   A composite candidate path is specified as a group of its constituent

   candidate paths.



   A composite candidate path is valid when it has at least one valid

   constituent candidate path.



**



Regards,

-Pavan





On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=
40cisco.com@dmarc.ietf.org> wrote:

> Hello All,
>
> We have just posted an update for the draft and following is the summary
> of changes:
>
> 1) Introduction of the Composite Candidate Path construct to address a
> pending comment from the WG (Ref :
> https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/
> and
> https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
> 2) Based on offline feedback received, updated SRv6 segment types to
> include optional SRv6 SID and behavior instead of the new type that was
> introduced for it in the v08.
> 3) Clarification of handling of colors and BGP multi-path scenarios based
> on offline feedback received.
> 4) Clarification on considerations for TI-LFA for SR Policy as discussed
> in the WG (Ref :
> https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)
>
> Please let know your comments/feedback.
>
> Thanks,
> Ketan (on behalf of co-authors)
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of
> internet-drafts@ietf.org
> Sent: 02 November 2020 06:27
> To: i-d-announce@ietf.org
> Cc: spring@ietf.org
> Subject: [spring] I-D Action:
> draft-ietf-spring-segment-routing-policy-09.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Source Packet Routing in Networking WG of
> the IETF.
>
>         Title           : Segment Routing Policy Architecture
>         Authors         : Clarence Filsfils
>                           Ketan Talaulikar
>                           Daniel Voyer
>                           Alex Bogdanov
>                           Paul Mattes
>         Filename        : draft-ietf-spring-segment-routing-policy-09.txt
>         Pages           : 37
>         Date            : 2020-11-01
>
> Abstract:
>    Segment Routing (SR) allows a headend node to steer a packet flow
>    along any path.  Intermediate per-flow states are eliminated thanks
>    to source routing.  The headend node steers a flow into an SR Policy.
>    The header of a packet steered in an SR Policy is augmented with an
>    ordered list of segments associated with that SR Policy.  This
>    document details the concepts of SR Policy and steering into an SR
>    Policy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09
>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-09
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-09
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>