Subject: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 10 May 2017 11:00:48 +0000

Hello authors and WG,

I am an MPLS-RT reviewer assigned to review draft-bryant-mpls-sfl-framework-04.

I have reviewed the draft and found that it is well written and coherent, and is a potentially useful solution.

However, I have a concern with the following text in section 4 describing ECMP and EL/ELI:

“  2.  The operator can elect to use [RFC6790] Entropy Labels which, in
       a network that fully supports this type of ECMP, results in the
       ECMP decision being independent of the value of the other labels
       in the label stack.”

I don’t think you can assume that intermediate LSR implementations only use the EL when spraying packets. Although RFC6790 does mention this as one option, I believe the more common case is to take into account other labels in the stack including the EL. The EL is effectively saying “all other things being equal, here is some additional information to distinguish flows”. It is in addition to, but not an alternative to the rest of the label stack. If the SFL value for packets on a given flow differs, but the EL is the same, then the LSR would still spray the packets because the label stack would be different.

I don’t think that it is reasonable to mandate that LSRs only consider the EL and ignore all other labels in the stack given the impact on the deployed base for just a few end-to-end applications.

I don’t think this draft should be both defining SFLs and trying to solve the general ECMP problem for applications of SFLs. Instead, it should focus on the SFL itself. My suggestion would be to change section 4 to say that ECMP considerations should addressed by an application of SFL if ECMP is a concern for that application.

Best regards

Matthew

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 11 May 2017 11:04:39 -0400

On 5/10/2017 7:00 AM, Bocci, Matthew (Nokia - GB) wrote:
> The EL is effectively saying “all other things being equal, here is 
> some additional information to distinguish flows”. It is in addition 
> to, but not an alternative to the rest of the label stack.

Do you think there is any situation in which (a) one has given the same 
EL value to two packets, but (b) one would be perfectly happy to see the 
packets delivered out of order?   Or to put it another way, once an 
ingress node has assigned a particular EL value to a particular set of 
packets, is there any advantage to including other fields in the ECMP hash?

> I don’t think that it is reasonable to mandate that LSRs only consider 
> the EL and ignore all other labels in the stack given the impact on 
> the deployed base

Certainly one cannot mandate the deployed base to be other than it is, 
but it would be interesting to know whether the common implementation is 
really the preferred behavior.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 11 May 2017 18:25:17 +0100

On 11/05/2017 16:04, Eric C Rosen wrote:
> Do you think there is any situation in which (a) one has given the 
> same EL value to two packets, but (b) one would be perfectly happy to 
> see the packets delivered out of order?   Or to put it another way, 
> once an ingress node has assigned a particular EL value to a 
> particular set of packets, is there any advantage to including other 
> fields in the ECMP hash?

I think not, and thus was surprised when I found out that EL did not of 
itself define the flow to the forwarders. Clearly I should have read RFC

>
>> I don’t think that it is reasonable to mandate that LSRs only 
>> consider the EL and ignore all other labels in the stack given the 
>> impact on the deployed base
>
> but it would be interesting to know whether the common implementation 
> is really the preferred behavior.
>
>

As we do more with MPLS it seems to me that we would like the EL to set 
the path for the flow, with other labels being ignored. Aborting the 
hash calculation on finding an ELI and just using the next label is 
simple operation, simpler than for example skipping the SPLs, and in the 
case of an extended SPL and the label that follows.

- Stewart

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Fri, 19 May 2017 14:20:02 +0000

Eric, Stewart

From: Stewart Bryant <[email-masked]>
Date: Thursday, 11 May 2017 at 18:25
To: Eric C Rosen <[email-masked]>, "Bocci, Matthew (Nokia - GB)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04

The EL is effectively saying “all other things being equal, here is some additional information to distinguish flows”. It is in addition to, but not an alternative to the rest of the label stack.

Do you think there is any situation in which (a) one has given the same EL value to two packets, but (b) one would be perfectly happy to see the packets delivered out of order?   Or to put it another way, once an ingress node has assigned a particular EL value to a particular set of packets, is there any advantage to including other fields in the ECMP hash?

I think not, and thus was surprised when I found out that EL did not of itself define the flow to the forwarders. Clearly I should have read RFC

MB> I’m not entirely sure of that. One could envisage situations where duplicate flows are assigned the same EL value but sent on different LSPs over the same path or subset of a path. However, there is no reason to maintain the order of the packets between the different flows with the same EL value. Of course, this doesn’t break the SFL application and so maybe that is not relevant to this draft.

I don’t think that it is reasonable to mandate that LSRs only consider the EL and ignore all other labels in the stack given the impact on the deployed base

Certainly one cannot mandate the deployed base to be other than it is, but it would be interesting to know whether the common implementation is really the preferred behavior.

As we do more with MPLS it seems to me that we would like the EL to set the path for the flow, with other labels being ignored. Aborting the hash calculation on finding an ELI and just using the next label is simple operation, simpler than for example skipping the SPLs, and in the case of an extended SPL and the label that follows.

MB> I agree it doesn’t seem arduous at all, but the other behaviour is allowed by RFC6790. Perhaps you could update the text in Bullet 2 of Section 4 to explicitly state that SFL applications require that the intervening MPLS network MUST load balance solely based on the entropy label (so that’s stricter than the current text in Section 4.2 of RFC 6790).

Best regards,

Matthew

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 19 May 2017 12:55:58 -0400

On 5/19/2017 10:20 AM, Bocci, Matthew (Nokia - GB) wrote:
> One could envisage situations where duplicate flows are assigned the 
> same EL value but sent on different LSPs over the same path or subset 
> of a path.

I suppose that if two flows have different ingress nodes, they might by 
coincidence get assigned the same EL value.  then if their paths 
intersected downstream, the EL itself might not provide enough entropy.  
Is that the sort of situation you're thinking of?

Of course, if the EL is computed by the ingress as, say,  a hash of the 
TCP header, one could minimize the probability of that by including the 
ingress node's address (or even some random value) in the hash.