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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 10 November 2020 18:56 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 E29343A0E4D for <spring@ietfa.amsl.com>; Tue, 10 Nov 2020 10:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 Pt1JSB_UWbvH for <spring@ietfa.amsl.com>; Tue, 10 Nov 2020 10:56:35 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 8E1BC3A0E45 for <spring@ietf.org>; Tue, 10 Nov 2020 10:56:35 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id o11so15385108ioo.11 for <spring@ietf.org>; Tue, 10 Nov 2020 10:56:35 -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=zMMFcItTidhuFLRoqaxu8JIIjg90psYMRgeWCbu8UpU=; b=TfBhBmkvJUWIs9aImSt1L+0DlvIaR0I9MnLwJYCp3WNLiCa4JuCHKMIgTyEH5th4dA BiyO8h21IkjWr4GthTkb8S6v5AvhDBbfcB/42fRDbdJxsmrghmlY/hxcTBIYhJeGX+Nq lDK2oTta3FainuW/lfwDNoBzeV/aMa55eorcf2nbuTUwyDRhO9S9rQDg8nMOeTl7b/DM JmWHVqN1rmNwqqQi7K6rN/nBkCzHXnZdPuBn1QNa/AQXFqXStALQBZ3Zbih4rgVI9JIT jg5+9kaYvM7f8IKiZ/JAYdjWzy7e9GFcHKFleWR9j0vLFuhTaB+69aq43VUgfRSZCLkA zMIQ==
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=zMMFcItTidhuFLRoqaxu8JIIjg90psYMRgeWCbu8UpU=; b=ixnLI4N6u/oO6PT7iKSsKo6a2UHGfJrBU6N+JtFF/tAQv6YByh/0t/ZOfkPcoOOODm 3wAe9Ef+XwCRf3NXFBUeJD62dh7WA2kzKSg7ervu0smRHnPzZ4cN0F0fulp6gzs3Z5EX cy+T2nnYUcjbu+OpsQ8DW9fb8dcO5Lzz5t+pZCajaCOsYP3/cwLaSlYrtSn8nNMqWXjh fa9DaLCP2crhU0UrujEPyIpR8+QcigJO+eddCUuC1Trbh6Yun19bUqgUy9wL2wKK1Sbx o1kSDdsgDwCvhsaDArUTf9d5xsT3eyZaG78w9QHAcwb/z+pMS9D5rJdKgux/CycKefMi kqqw==
X-Gm-Message-State: AOAM531OPqKg0zFtWg63Qx3/i7gEGlw64OYC+15qDxWl3Lf9Bxms8CRE NVUXRh/PJ2rVWeXkgvm5NsP3KWmfG+o1Tg2z3Sk=
X-Google-Smtp-Source: ABdhPJz19hd0tlaPY6xW6zgkfiVVoLlSLu3v3O+5Aqh9NO/JcXCKCqrVF/4iT+fz1Sgt/PyDtc87gGVfvxstlLa6D/w=
X-Received: by 2002:a5d:9d48:: with SMTP id k8mr15298085iok.62.1605034594821; Tue, 10 Nov 2020 10:56:34 -0800 (PST)
MIME-Version: 1.0
References: <160427863467.23607.17022367772306047140@ietfa.amsl.com> <MW3PR11MB4570D65A1973363A1A6EF7AEC1100@MW3PR11MB4570.namprd11.prod.outlook.com> <CA+YzgTuqyGvFzx_SBSxx-4y0e0d8FvMhcPzx9b5tzq3F5ayL0A@mail.gmail.com> <MW3PR11MB4570D601ADC0D8E24B6B2675C1E90@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4570D601ADC0D8E24B6B2675C1E90@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 10 Nov 2020 12:56:22 -0600
Message-ID: <CA+YzgTsptfe7j83_A9G5v9PpkH-i5+CzgOKssuD=b6BXPxRqtg@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e06af405b3c53c8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/mSE121cimkxWhV08pcDsz6aadLg>
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: Tue, 10 Nov 2020 18:56:39 -0000

Ketan, Hi!

Please see inline for responses (prefixed VPB).

Regards,
-Pavan

On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Pavan,
>
>
>
> Please check inline below.
>
>
>
> *From:* Vishnu Pavan Beeram <vishnupavan@gmail.com>
> *Sent:* 10 November 2020 00:08
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* spring@ietf.org
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-segment-routing-policy-09.txt
>
>
>
> Ketan,
>
>
>
> Much Thanks for taking a stab at addressing the composite candidate path
> use-case! We seem to be converging.
>
> *[KT] Thanks for that feedback and confirmation that the proposal in the
> draft does address the use-case. I believe we are now discussing the
> mechanics of how this is achieved within the current SR Policy framework.*
>
>

>
> However, I don’t understand why you need to use additional SR policies
> (and unnecessarily burn additional colors) to address this.
>
> *[KT] I do not follow what you mean by “burn additional colors”. Color is
> just a 32 bit number that indicates the “intent” and is not really a scarce
> resource. Assigning a color to “a composite intent” seems like a seamless
> way to integrate with existing mechanisms for Steering over SR Policies.
> This gives the flexibility for say some BGP services to be steered over the
> constituent explicit/dynamic intent while others can steer over a composite
> intent that includes those individual explicit/dynamic intents.*
>

[VPB] The “flexibility” that you are referring to is undesirable for this
use-case. For the traffic-split use-case, we don’t want any other services
to be directly steered over the constituents when they are part of a
composite candidate path. The current proposal in the draft would have been
acceptable if the constituent SR Policies were uncolored – but that would
violate the current rules imposed by the draft.


>
> Why can’t the composite candidate path just be a grouping of explicit
> candidate paths and/or dynamic candidate paths?
>
> *[KT] This is because in the SR Policy framework, there is only a single
> active CP – it may be explicit or dynamic. Now we’ve added another
> Composite CP type to cover this specific use-case. Your proposal will
> result in 3 candidate paths being active within the same SR Policy – one
> each of the explicit and dynamic CP and then additionally the Composite CP.
> This breaks the existing rules for selection of CP based on preference and
> mechanisms like fallback between CPs. While the current proposal in the
> draft provides a way to address the new use-case with a backwards
> compatible extension to the SR Policy framework.*
>

[VPB] The proposal in my previous email is backwards compatible and does
not intend to break any existing rules for deeming a candidate path active.
As per the rules that are outlined in Section 2.9, only the composite
candidate path is “active” given its preference. The constituent candidate
paths will never be active on their own. If it is necessary, we can add a
statement in Section 2.9 to explicitly state that the candidate path
selection criteria does not apply to the constituent candidate paths.


>
> *Thanks,*
>
> *Ketan*
>
>
>
> 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
>
>