Return-Path: <balajivenkat299@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 4CC1813175A
 for <mpls@ietfa.amsl.com>; Mon, 29 Jan 2018 11:34:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_PASS=-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 4h_Tun1grc2O for <mpls@ietfa.amsl.com>;
 Mon, 29 Jan 2018 11:34:48 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com
 [IPv6:2a00:1450:400c:c09::230])
 (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 09BB612FB10
 for <mpls@ietf.org>; Mon, 29 Jan 2018 11:34:48 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id b21so35956542wme.4
 for <mpls@ietf.org>; Mon, 29 Jan 2018 11:34:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=vyb9I2AVkdBnHlIoEszSuR5Dm8ryXBrHPUyL9Xyoskc=;
 b=PBKOkKxt8m87/9KLEy9MnqlDmoTbcljq7O5FHU1gYynbsAJ1Vwn9rQ6uxegr2ocrqm
 ST0ST+C+sxYviXs+1ixmE6u0ezT/kNju4OIwoHWHN9fQ9eVrJKZ6xB+9DKPBuedYOCRZ
 ZWOyk2xW6zCf7JtDTp6G72TCiZmnVS/65S1ImJHgSwFLpVb+Woy2eONPpjGQg9EcJaFk
 x7oPZXpFequ4LqtHhY2W8tEVm/se+vcTd+eF5eWw5nMwAVnC5I35XZV1PA6k2YkvL0XS
 S5VXZR6152Ke9TB0LoaSVAu6F1isTiadTIMzVeB1Au+3ceqxvpLoMEnOShLkWgvNldmR
 NRgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=vyb9I2AVkdBnHlIoEszSuR5Dm8ryXBrHPUyL9Xyoskc=;
 b=qrmufIxDfZQDDBNCeVmQhUZT2xNMgoNYGA3ccfWDNC1o6wJiYplj1bbPtyZlLzGdjG
 I5JNrC5Z67SbwI9X17jvb6U+Xx/fROVGPdg7DyASYDjiYEwvV1a6NYbyskg0kND6EulO
 3tmBbhhzEU54WGkYaFlf7KSnR5ZQhX2ScAcKVMZXXzHviCeN1mCcBkzHlSC5WBDiX+vl
 tulH+TuydAPuIXyI1ddc97m6WQClSGrk5YHy2XBAg6JbWSYOJTiNcYRaXYi1v1jXXa58
 B9YfRo/qMpdONWbcPEj6Hpf9VK7kUUv4k1KUi2aloMSbWyCE8bRmjIQG4VfJUr89dQf8
 SCag==
X-Gm-Message-State: AKwxytcIzP0IaWvfNF3tiWDcPd/7Sytoqlcmf67KzQZmymA+HE9RTUlY
 cT/81hWwFt1hIKAeRLPcHTW1RnoFJ0DS0/DF5mw=
X-Google-Smtp-Source: AH8x224Xj72RITyStSICh2Xpv9TDkjrYAv6FzFDRWNTsHUWgUXj9S6skLaxO38qX/3csaWWRMmnq4KkphdB0RvX+d1Y=
X-Received: by 10.28.126.138 with SMTP id z132mr14865197wmc.139.1517254486507; 
 Mon, 29 Jan 2018 11:34:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.167.77 with HTTP; Mon, 29 Jan 2018 11:34:45 -0800 (PST)
In-Reply-To: <88650e7a-5fbb-1a99-dbc0-19650db99146@gmail.com>
References: <CAHF4apONg86UYSK9qJN_-bkcw0TcdFXMjgad+gSoxwDmsFbOmA@mail.gmail.com>
 <88650e7a-5fbb-1a99-dbc0-19650db99146@gmail.com>
From: Balaji venkat Venkataswami <balajivenkat299@gmail.com>
Date: Tue, 30 Jan 2018 01:04:45 +0530
Message-ID: <CAHF4apPJ9zboZ9AteFB=VmjNteak3AON_s9ONEjGu_-emaDTvg@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mach.chen@huawei.com, mpls@ietf.org
Content-Type: multipart/alternative; boundary="001a1141e94ab3c6e00563ef56d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/C9VcSD7oRSE46Whdmk_LzXS3KvI>
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-sfl-framework-01.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>,
 <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
 <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 19:34:50 -0000

--001a1141e94ab3c6e00563ef56d2
Content-Type: text/plain; charset="UTF-8"

Hi Stewart,

I get it now. In order to avoid midway changes to the ECMP path once the
flow has begun
the draft advises to use the SFL label always from PW or VPN creation time
to the end of the
flow to get it to take one ECMP path throughout the lifetime of the flow
consistently. Replacing the SFL
with the original application label may cause it to take a different path
midway.

The rest is very clear.

Thank you for your kind explanation.

thanks and regards,
balaji venkat

On Mon, Jan 29, 2018 at 10:08 PM, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

>
>
> On 29/01/2018 14:50, Balaji venkat Venkataswami wrote:
>
> Hi Authors,
>
>
> In the current version of the draft, this follows in section 5.
>
>
>
>
>    The introduction to an SFL to an existing flow may cause that flow to
>    take a different path through the network under conditions of Equal
>    Cost Multipath (ECMP).  This is turn may invalidate the certain use
>
>    of the SFL such as performance measurement applications.  Where this
>    is a problem there are two solutions worthy of consideration:
>
>    1.  The operator can elect to always run with the SFL in place in the
>        MPLS label stack.
>
>
> What this is saying is that you could set up monitoring at for example PW
> or VPN
> creation and always run with that extra label. This is not ideal but the
> ECMP issue goes away. In other words always run with the SFL in place.
>
>
>
>
>    2.  The operator can elect to use [RFC6790] Entropy Labels in a
>        network that fully supports this type of ECMP.  If this approach
>        is adopted, the intervening MPLS network MUST NOT load balance on
>        any packet field other than the entropy label.  Note that this is
>        stricter than the text in Section 4.2 of [RFC6790].  In networks
> Bryant, et al.           Expires August 2, 2018                 [Page 7]Internet-Draft                   MPLS FI                    January 2018
>
>        in which the ECMP decision is independent of both the value of
>        any other label in the label stack, and the MPLS payload, the
>        path of the flow with the SFL will be congruent with the path
>        without the SFL.
>
>
>
> This is an alternative to point 1. Use the EL system (always) and require
> a strict implementation
> of it in which the only packet characteristic taken into account when
> selecting the ECMP path
> is the value of the EL.
>
> The text seems clear, but if you have any changes in mind please let me
> know.
>
> Best Regards
>
> - Stewart
>
> Question ?
>
> You dont seem to be considering the consequences of point 1 in the
> explanation given.
> Or are you trying to say that if point 1 is what is followed, the ECMP
> decision should be
> independent of the SFL label in place and the MPLS payload, so that the
> path of the
> flow with the SFL in place will be congruent with the path without the SFL
> ?
>
> Are you specifying something in point 2 that also applies to point 1 ?
>
> Please clarify.
>
> thanks and regards,
> balaji venkat
>
>
>

--001a1141e94ab3c6e00563ef56d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Stewart,<div><br></div><div>I get it now. In order to a=
void midway changes to the ECMP path once the flow has begun</div><div>the =
draft advises to use the SFL label always from PW or VPN creation time to t=
he end of the</div><div>flow to get it to take one ECMP path throughout the=
 lifetime of the flow consistently. Replacing the SFL</div><div>with the or=
iginal application label may cause it to take a different path midway.</div=
><div><br></div><div>The rest is very clear.</div><div><br></div><div>Thank=
 you for your kind explanation.=C2=A0</div><div><br></div><div>thanks and r=
egards,</div><div>balaji venkat</div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Mon, Jan 29, 2018 at 10:08 PM, Stewart Bryant =
<span dir=3D"ltr">&lt;<a href=3D"mailto:stewart.bryant@gmail.com" target=3D=
"_blank">stewart.bryant@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
    <p><br>
    </p>
    <br>
    <div class=3D"m_1569555598927038898moz-cite-prefix">On 29/01/2018 14:50=
, Balaji venkat
      Venkataswami wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <pre>Hi Authors,

</pre>
            <pre>In the current version of the draft, this follows in secti=
on 5.


</pre>
            <pre>
  =C2=A0The introduction to an SFL to an existing flow may cause that flow =
to
   take a different path through the network under conditions of Equal
   Cost Multipath (ECMP).  This is turn may invalidate the certain use</pre=
>
          </div>
        </div>
      </div>
    </blockquote>
    </span><blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <pre>   of the SFL such as performance measurement applications=
.  Where this
   is a problem there are two solutions worthy of consideration:

   1.  The operator can elect to always run with the SFL in place in the
       MPLS label stack.</pre>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What this is saying is that you could set up monitoring at for
    example PW or VPN<br>
    creation and always run with that extra label. This is not ideal but
    the<br>
    ECMP issue goes away. In other words always run with the SFL in
    place. <br><span class=3D"">
    <br>
    <br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <pre>
   2.  The operator can elect to use [RFC6790] Entropy Labels in a
       network that fully supports this type of ECMP.  If this approach
       is adopted, the intervening MPLS network MUST NOT load balance on
       any packet field other than the entropy label.  Note that this is
       stricter than the text in Section 4.2 of [RFC6790].  In networks

<span class=3D"m_1569555598927038898gmail-m_ftr">Bryant, et al.           E=
xpires August 2, 2018                 [Page 7]</span>
<span class=3D"m_1569555598927038898gmail-m_hdr">Internet-Draft            =
       MPLS FI                    January 2018</span>

       in which the ECMP decision is independent of both the value of
       any other label in the label stack, and the MPLS payload, the
       path of the flow with the SFL will be congruent with the path
       without the SFL.</pre>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    This is an alternative to point 1. Use the EL system (always) and
    require a strict implementation<br>
    of it in which the only packet characteristic taken into account
    when selecting the ECMP path<br>
    is the value of the EL.<br>
    <br>
    The text seems clear, but if you have any changes in mind please let
    me know.<br>
    <br>
    Best Regards<span class=3D"HOEnZb"><font color=3D"#888888"><br>
    <br>
    - Stewart</font></span><span class=3D""><br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>Question ?<br>
          <br>
        </div>
        <div>You dont seem to be considering the consequences of point 1
          in the explanation given.<br>
        </div>
        <div>Or are you trying to say that if point 1 is what is
          followed, the ECMP decision should be<br>
        </div>
        <div>independent of the SFL label in place and the MPLS payload,
          so that the path of the <br>
        </div>
        <div>flow with the SFL in place will be congruent with the path
          without the SFL ?<br>
          <br>
        </div>
        <div>Are you specifying something in point 2 that also applies
          to point 1 ?<br>
          <br>
        </div>
        <div>Please clarify.<br>
          <br>
        </div>
        <div>thanks and regards,<br>
        </div>
        <div>balaji venkat<br>
        </div>
      </div>
    </blockquote>
    <br>
  </span></div>

</blockquote></div><br></div>

--001a1141e94ab3c6e00563ef56d2--

