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

"Bocci, Matthew (Nokia - GB)" <> Fri, 19 May 2017 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE388127599; Fri, 19 May 2017 07:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VHSSRet5SFao; Fri, 19 May 2017 07:20:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8325412700F; Fri, 19 May 2017 07:20:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QS/nP/SqgGMAhiu2eKxYjt5CxQMkYkhlyX45W07n8M0=; b=mEWOxXBNf3KGRIA7CMoneztE31s5icEnpj7gkw0lGfDh21Yb8wm8W9XAXyJ4Ik57FmzGKQnZ1wfYkpHohKfwI9PpbZ6Sdy/gGowy61p2OLNKxJzL3WSccJvGxMJrRChJw9/mLlG97Ox3zJll1wvsSFzL9W4IQz0zQJL4KPfRR3Y=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Fri, 19 May 2017 14:20:02 +0000
Received: from ([fe80::d934:270e:e6a2:4f43]) by ([fe80::d934:270e:e6a2:4f43%16]) with mapi id 15.01.1124.007; Fri, 19 May 2017 14:20:02 +0000
From: "Bocci, Matthew (Nokia - GB)" <>
To: Stewart Bryant <>, Eric C Rosen <>, "" <>, "" <>
CC: "" <>
Thread-Topic: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04
Thread-Index: AQHSyXyubno0L7diUE+waDh2NhVRQ6HvPNmAgAAnSoCADG+ngA==
Date: Fri, 19 May 2017 14:20:02 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/f.22.0.170515
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB4PR07MB316; 7:MYsR6Ma24jVd+Uy4vLdsozwKfh9nJU3AvyiROob02yNz6H4jnoo6+Qn4G63z7pbUAtoX5zgicSbJyLUDmKN7HXpTMjRAvSRXjQP17dK4NHllPwqcWDhkLHOWqacCPcazqDlK1xcp+PvbfY/YAht52NBIjiCn0Jm3vHjJk9murNQI7/agsUp6Gqjk0K8hwbl67c+jjdFh3w2MGYFWghVDCLJUMW6XisA37lFC+mpP2iChY/GJnNeAQnuUf5+RyKLk5FssgIxH/ggxjuEClV/uxxD71OYU1C8h4znV5HESaTLcRruxOcuMdRhYEK2Xu9IInF651sl2LF6eNoJVQwA9Mg==
x-ms-traffictypediagnostic: DB4PR07MB316:
x-ms-office365-filtering-correlation-id: d3252a4e-6897-432a-0937-08d49ec223d8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR07MB316;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(278428928389397)(138986009662008)(82608151540597)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148); SRVR:DB4PR07MB316; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB316;
x-forefront-prvs: 031257FE13
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(39860400002)(189002)(199003)(24454002)(377454003)(76176999)(8676002)(33656002)(50986999)(4001350100001)(54356999)(189998001)(36756003)(229853002)(7736002)(2906002)(2950100002)(2900100001)(3660700001)(478600001)(99286003)(3280700002)(81166006)(8936002)(6436002)(8666007)(6306002)(2201001)(230783001)(25786009)(6246003)(2501003)(1941001)(6512007)(54896002)(5250100002)(38730400002)(5660300001)(4326008)(53936002)(102836003)(3846002)(6116002)(6506006)(6486002)(86362001)(83506001)(39060400002)(53546009)(66066001)(83716003)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB316;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_E2F245601EAA4D30983A49314F976496nokiacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 14:20:02.6099 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB316
Archived-At: <>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 May 2017 14:20:09 -0000

Eric, Stewart

From: Stewart Bryant <>
Date: Thursday, 11 May 2017 at 18:25
To: Eric C Rosen <>et>, "Bocci, Matthew (Nokia - GB)" <>om>, "" <>rg>, "" <>
Cc: "" <>
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,