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

Stewart Bryant <> Thu, 11 May 2017 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CD7B129405; Thu, 11 May 2017 10:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v0PFWIbc_z32; Thu, 11 May 2017 10:30:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78786129418; Thu, 11 May 2017 10:25:22 -0700 (PDT)
Received: by with SMTP id l9so27122822wre.1; Thu, 11 May 2017 10:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=yHClJdmTYZRkEIedvJAIpvp3GQd0CAGV1+U15Y3Y8l4=; b=KZbGsARf1atC1Ser+ahMRIY1XrBT0SpFAVMBayhM/Ie1f9g7waSkeV2n2QhNh6wZnd n+mMFWaeFmWTJ18io9yOEiifE8G4CATxtIVgc7XN2+T5GRR+bROME/bjPmuAoODuMixr s5NkJ1LjD7fVsLSxNL/wcVptaEQCJRLo6XABdZ5nutmisQUcQkGYgN4Ndm0Nx5+uvFK1 AGXfc+pQ74c8zlS1uwvfDqEH/zuQa/As3H488Hmj5YOBgPkbXrnQXWYYMQyGIupzX2ki N7EoJaco9FOTM/ISZ3/isLYCSV8Q08ewg+CFfDsV1Tn4ZUlVTwnPKS4zqFEGdrSK/Xsk 9p9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=yHClJdmTYZRkEIedvJAIpvp3GQd0CAGV1+U15Y3Y8l4=; b=KhFSTjMvtsx2HNfcMpcw/jYoDfnDqlR7fiq0fYd8kY6BA4Yd/he0AR6MHWoFKbZ1Mn UcTg7mmtRL7N31UyZwTEi5qONlEkuNSrA8WebK4UeXDsZb5NPsyMFcXizgI+BgMq25gv YpoUQW8mQlt/m2QtH672TP2wd63ddx71AKy1YDUmy5pzoGSyscGLasXTwQG0OMuc1uVP lwPn3uSxzUbkpuw3ELJ7xjsfOmWWhfvat6nWgJivZ2+Vyx+0UpA1ngslNf3GW6EfMumo pBToHFOPqLg2j0SVS2jHIj4bHiRI9wDYfdfAJuIzWnI4wxPyynipmdAsNV+mKqzhWt5T W//g==
X-Gm-Message-State: AODbwcBKFyRE8Hp5iJRE2Tpc7/WVnbC+wjMe5sfi/rEzu+Pp4/cp6z6/ a2BiJ5jr8VP8qA==
X-Received: by with SMTP id 95mr179627wrb.150.1494523521054; Thu, 11 May 2017 10:25:21 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c184sm1734064wmd.2.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 10:25:20 -0700 (PDT)
To: Eric C Rosen <>, "Bocci, Matthew (Nokia - GB)" <>, "" <>, "" <>
References: <> <>
Cc: "" <>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 11 May 2017 18:25:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CE2F0227F6E5D29E1F1C2D1E"
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: Thu, 11 May 2017 17:30:43 -0000

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

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

- Stewart