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

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Eric, Stewart

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




On 11/05/2017 16:04, Eric C Rosen wrote:
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 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