Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

"Adrian Farrel" <> Sun, 18 March 2018 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 281BC1200FC; Sun, 18 Mar 2018 03:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ygpEulDgPquC; Sun, 18 Mar 2018 03:10:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3339F1200A0; Sun, 18 Mar 2018 03:10:22 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w2IAAJ1t001388; Sun, 18 Mar 2018 10:10:20 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id A815322042; Sun, 18 Mar 2018 10:10:19 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 923CE22044; Sun, 18 Mar 2018 10:10:19 +0000 (GMT)
Received: from 950129200 ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id w2IAAILV020742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Mar 2018 10:10:19 GMT
From: Adrian Farrel <>
To: "'Henderickx, Wim (Nokia - BE/Antwerp)'" <>, 'Robert Raszuk' <>
Cc: 'mpls' <>,,
References: <019501d3bd6b$657d7ef0$30787cd0$> <> <00a001d3be17$e0ec3ca0$a2c4b5e0$> <> <>
In-Reply-To: <>
Date: Sun, 18 Mar 2018 10:10:16 -0000
Message-ID: <003f01d3bea1$50714910$f153db30$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D3BEA1.50760400"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI9EwwhHSaTHIL3dWRwh0LHnm5F4wK3BYKFAd26oeEBOcFlUgHsKLpuosU3DZA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--16.574-10.0-31-10
X-imss-scan-details: No--16.574-10.0-31-10
X-TMASE-Result: 10--16.574100-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHMy6K24fisq3BRIrj8R47FGSqdEmeD/nW4QD+HVNBt0iVm CsIwjHGeeVCkVDoMfkaC9B6j4iFXW9+vpwtrIEoysyNb+yeIRAo026H7nOZLr/FJXtgF4GFLUZW kO5u2j/XOihJdFL9XuP1NFrRSsqci2HzzjwqZ3wKUa50su1E7W99sbK9F0hpIQGmQpWnG68Yuu9 HtoCYkWAEyVhfb3nwBdTwHtQCOr39u2c6eDqJklp4RyjTmGyy+guwtqyXlE6GHwGEm+CpYGfcBL yb5pFK2UHJXVJB9zhImgk2Ypl639nz5lEEBuvacMN+B8zdlz9GX/suzL1NqnBjQD3m2MCf7gW0g uPJuEMhdeiUYDGKnXqI6V7VNKY2VHdcZxZ9Z/dHx5KZMlKYS/ZnZ3QZNYH8l31GU/N5W5BC2f7P ECFH4/jFCiL3/pKwQjoY0sJMZaM2oJ7WEzBHHQMWUKBjERoYTN/BTU5ZfZRIOAHqXajwVGPiOuW 9Uv+JM9C9CMIwENAIGVpRcmx5zokLMcWGLKmhW5gCHftmwEMIITWV64m6h+/0TP/kikeqnfMrdD 3NIUvv6k6QmByFwrWut2Jy2mQp1iNCj8jDazVJNCH0Dib0S0d9WrDP4LKdpx7QfsswIVxXBGri2 x+GkHA7G7azt901XixYJ8/oaa/l1tKCSzroCgY9URkDgdlb5/RmmEswf7IeiXe5nNnUYt6BKM62 rmx9p8eoBfgDeEI7gXuUEZiH4rz8G3G/wjVDpcLw8nYQVLsggFyxci4S+VuRnWbJNcqgXKqHlxT J7eJUibp8py4XIryhHQrcMnybC1lfDCm9+EZWeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyL3PDiXO /tFSYVH0dq7wY7uVgaABuyCCQGiR2ktFVldDsbvrUGuBsykdkvBOgARBwMzwT3PkBWJbA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Mar 2018 10:10:25 -0000

Wim and Robert,
[Dropping SPRING at this point as (as previously discussed) we have taken / are taking SR out of this document]
I think that draft-ietf-bess-service-chaining is really important work: it expresses a technique that is implemented and shipping.
On the other hand, this approach is not fully consistent with RFC 7665. 
But it does describe an actual SFC technology. Whether it remains in the field or is a migration technology only time (and operators) will tell.
Now, if we want to support RFC 7665 and RFC 8300 and use a control plane to discover the SFFs and to which SFs they provide access and to install "forwarding state" for SFPs, then we also have draft-ietf-bess-nsh-bgp-control-plane.
That draft was originally written with RFC 8300 in mind, but with the addition of one sub-TLV to indicate the encoding, it also supports draft-farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc attempts to model RFC 8300 as much as possible.
And that brings us back to "Where do we end up, what transition tools should we have, and how many steps to transition are there?"
draft-farrel-mpls-sfc provides another transition tool on the migration to RFC 8300. It allows SFFs to be built as a minor mod to existing routers before there is forwarding plane support for the NSH.
But I want to reiterate that the discussion of wat encoding the SF supports is a red herring (certainly in the context of RFC 7665). An SF is either "SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support the SFC encoding (such as NSH) or it can't. But also, an SF is either locally attached to the SFF or not. A local attachment is (of course) easier to operate and allows "bump in the wire" proxies very easily. A remote attached SF is (IMHO) attached via a tunnel.
The question of "remotely attached SFs" is one that should concern all implementations of RFC 7665 because no one (as yet) has worked on a protocol to bind SFs to SFFs. Robert is right that providing bump in the wire proxy for remotely attached SFs means that it is hard to know/control what goes where. But that problem exists to some extent for any remotely attached SF. For that reason (among others) I would implement the proxy as part of the SFF.
From: Henderickx, Wim (Nokia - BE/Antwerp) [] 
Sent: 18 March 2018 07:26
To: Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List;;
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Indeed, this is exactly my point. If you want an interim solution you want to use what we have and draft-ietf-bess-service-chaining-04 is an example of how you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc requires an implementation change in the data-plane, whether we like it or not and an upgrade is required even in brownfield deployments. So, you better go directly to the final solution defined in IETF SFC WG. If we standardize draft-farrel-mpls-sfc we end up supporting both forever.
From: <> on behalf of Robert Raszuk <>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <>, mpls <>, SPRING WG List <>, "" <>, "" <>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Hi Adrian,
> That proxy may be a bump in the wire between the SFF and SF
I am not so sure about that ... If this would be just "bump in the wire" you would have zero guarantees that all packets which need to go via given function will actually hit that bump - so this is far from a reliable network service. 
There must be associated control plane component attracting traffic to such bump. 
That mechanism with basic MPLS (where labels by based MPLS architecture are of local significance) is available with L3VPN extensions as already progressing in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you state "interim" ? 
No one really addressed that question yet and I think it is a critical one to make any further judgement  as to the future of this individual submission. 
On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel < <>> wrote:
Hi Wim,

Thanks for reading the draft so carefully.

> Adrian, on replacement of NSH. You will have to change the SF with this proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which SF(s)
> support MPLS?

This is not about "replacing" the NSH. As you'll see from point 2, below, this is about providing an interim / migration technology.

Clearly (and I think you agree) in the case where an SF is not SFC-aware, a proxy must be used. That proxy may be a bump in the wire between the SFF and SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the first two options are available. In the case of a VNF, all three options exist.

Now, let us recall where we are starting from. There are PNFs and there are VNFs built to look like PNFs. These SFs do not support MPLS or NSH.

Similarly, there are routers that do not support the NSH.

Now, of course, we would all love to sell major upgrades so that every component of the network is SFC-aware. But we would also like to start deploying SFC into existing network infrastructure.

So your question misses the point. The question to ask is which brownfield routers and SFs support NSH?