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

"UTTARO, JAMES" <> Mon, 19 March 2018 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E221D126D74; Mon, 19 Mar 2018 06:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rT5T6KATxs7x; Mon, 19 Mar 2018 06:47:52 -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 6CD281242F5; Mon, 19 Mar 2018 06:47:52 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w2JDa8QI004598; Mon, 19 Mar 2018 09:47:51 -0400
Received: from ( []) by with ESMTP id 2gtdwjrwjx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 09:47:50 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id w2JDlmPA002235; Mon, 19 Mar 2018 09:47:49 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2JDlib9002128; Mon, 19 Mar 2018 09:47:45 -0400
Received: from ( []) by (Service) with ESMTP id 4735940002BE; Mon, 19 Mar 2018 13:47:44 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 2E1FC40006F9; Mon, 19 Mar 2018 13:47:44 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Mon, 19 Mar 2018 09:47:44 -0400
From: "UTTARO, JAMES" <>
To: "" <>, "Henderickx, Wim (Nokia - BE/Antwerp)" <>, Robert Raszuk <>, Adrian Farrel <>
CC: mpls <>, SPRING WG List <>, "" <>, "" <>
Thread-Topic: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Thread-Index: AQHTvdwBHGt1a3lfzE6cxr+P43AHk6PU9xWAgAAHlYCAAN1DgIABu0iA///nz9CAAFLFAP//wbYw
Date: Mon, 19 Mar 2018 13:47:43 +0000
Message-ID: <>
References: <019501d3bd6b$657d7ef0$30787cd0$> <> <00a001d3be17$e0ec3ca0$a2c4b5e0$> <> <> <787AE7BB302AE849A7480A190F8B93302DEE2A47@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93302DEE304D@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEE304D@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F36721B24MISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190159
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: Mon, 19 Mar 2018 13:47:56 -0000


                We run an MPLS network so there is no NSH deployed anywhere. I want to create simple chains that we can make available to our WAN customers and I want to keep it simple from a technology and operations POV.. At this point I do not see the need to introduce NSH for what we need to do. I can simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to define the set of requirements/criteria and compare the encaps.

                Jim Uttaro

From: []
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <>; Henderickx, Wim (Nokia - BE/Antwerp) <>; Robert Raszuk <>; Adrian Farrel <>
Cc: mpls <>; SPRING WG List <>;;
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a transport-agnostic approach that can be deployed in conjunction with one’s favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.


Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List;<>;<>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is an encap that has tons of functionality but if a simple chain is needed why is it that an existing encap should be disallowed by the IETF?? I want to simplify the network, when I say network it is all of the plumbing to realize a service for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single encap across an integrated solution is quite attractive.

                Jim Uttaro

From: sfc [] On Behalf Of<>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <<>>; Robert Raszuk <<>>; Adrian Farrel <<>>
Cc: mpls <<>>; SPRING WG List <<>>;<>;<>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.

For all these proposals, a new behavior is needed to be followed by SFC-aware nodes. What differs is the channel used to signal a chain and to supply additional data for SFC purposes.

Leveraging on existing code/capabilities is good for a vendor/implementer, but the risk is that a given solution will need to support all/many of these flavors. Which is not optimal.

The IETF has already a consensus on a transport-agnostic solution. If we open the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to go that way? If yes, what is the NEW problem are we trying to solve?



De : sfc [] De la part de Henderickx, Wim (Nokia - BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List;<>;<>
Objet : 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?