Subject: [mpls] I-D Action: draft-ietf-mpls-sfl-framework-01.txt

From: Balaji venkat Venkataswami <[email-masked]>
Date: Mon, 29 Jan 2018 20:20:31 +0530

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 uses
   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.

   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.

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 29 Jan 2018 16:38:47 +0000

On 29/01/2018 14:50, Balaji venkat Venkataswami wrote:
>     Cost Multipath (ECMP).  This is turn may invalidate the certain use

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.

> Bryant, et al. Expires August 2, 2018 [Page 7]
> Internet-Draft MPLS FI January 2018
>

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

> independent of the SFL label in place and the MPLS payload, so that 
> the path of the

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Tue, 30 Jan 2018 01:04:45 +0530

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 <[email-masked]>
wrote:

> What this is saying is that you could set up monitoring at for example PW
> or VPN
> Bryant, et al.           Expires August 2, 2018                 [Page 7]Internet-Draft                   MPLS FI                    January 2018
>
> This is an alternative to point 1. Use the EL system (always) and require
> a strict implementation