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

"Bernier, Daniel" <daniel.bernier@bell.ca> Wed, 21 March 2018 00:53 UTC

Return-Path: <daniel.bernier@bell.ca>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80E12D7F3; Tue, 20 Mar 2018 17:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIOvnv-Zca1I; Tue, 20 Mar 2018 17:53:43 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317DD126BF6; Tue, 20 Mar 2018 17:53:34 -0700 (PDT)
Received: from [85.158.136.3] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-16.bemta-5.messagelabs.com id AF/FD-21081-D0DA1BA5; Wed, 21 Mar 2018 00:53:33 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTYRTH99y3XdPFdWo+jjJaFBVoqwjuJw0 iGgRW0IdYUV3z5kbblN0Zq6DEMtMKl1iwYbVQa1uLcqlovlZMU0ttRQ4j0rRy08AoS9O0e3et 7Mvh/5zfefk/cEhU/pJQkKzFzJqMjF5JLMK2bvuYnxR5t0qjaplR0ZMXAyhd1V2L0c52G0p/s rfi9JPPH6R0f6ULp/Nu5qH08ECNlG7vnQb0RNMgTpdMe7EtkepgcRlQV1RMIeq3/X5E7XzgAu qzHzsIdUOVA9lFaHCdMT3LcgjXeiYLsex6K27xumuJXPCpAC8CESSk0uAl/2uiCCwi5VQTgIG BkvlHAMDygE8qProAbCgOAaGFoFRwbm4EF0As1YfAmm83CQGg1El4xvYuXBRDpUCf52tYx1Kp 8EVhFyHqNNjnvBXOY9QqGGyfkgpaRq2FI47zuLjNFwHPl4yiAoigDsCxy3Nhs4BaAn90ehBxW TzsH76BiJ+gYEVjDyrqOBgcmp3/nArWVDZjol4OX3o/4GLvTljeWw3ExdGwwzY8X5MAHzkDYS 2nVsKfLY1ANOQA8P2QZ35BKpzzTwIrUNgX+LAvmGtfMNcOSD6/Ft57uF4sWQFLLwxKRb0G5pd dky7MO4DUDdZwrOkYa0rauCk53aTL1JoNjE6ftEG1OdnAchyTyeqZdC75cJbBC/hDOi2RgDpQ V5D2GCSQiDJOtntFlUa+OD0r47iW4bQHTTl6lnsMlpKkEsp+3eFZtInNZC1HdHr+Gv9gSEYpY 2X7PDyWcdmMgdNliqgTbCOr3wfPoWRrOAZGRvlYfWuMj3Wlty+gcsyYZWQV8TKJ0EwJzdoc49 /Rf27dD5YpYmRAIpHIo7JZk0Fn/p+HQDwJlDGyRGFKlM5o/usgxJtDeHNHbfcFc2bmH1Lkgp2 NMbOJW7c/2xvx4+nt/TWpr2wa98ldO6why5H6otXH8nu5ioYR96HAqYxTZ8dDHS4HFt1WTSVe 8U60Nd9/HWj3ewfefOtcOuT9ruGuFqT0tPXPJnRLk6+ndkU6U1x5rhx1ML/QMVPSPO4uk3f4d D6VKjj05Xkf4puwnthjnVFinJbZsA41ccxvPMGlu+YDAAA=
X-Env-Sender: daniel.bernier@bell.ca
X-Msg-Ref: server-8.tower-123.messagelabs.com!1521593610!87232935!1
X-Originating-IP: [67.69.230.133]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11895 invoked from network); 21 Mar 2018 00:53:31 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-8.tower-123.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Mar 2018 00:53:31 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca
Received: from DG1MBX02-WYN.bell.corp.bce.ca (198.235.102.33) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1263.5; Tue, 20 Mar 2018 20:53:25 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Mar 2018 20:53:27 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::440d:d4b7:fe2d:d8b7]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::440d:d4b7:fe2d:d8b7%22]) with mapi id 15.00.1263.000; Tue, 20 Mar 2018 20:53:29 -0400
From: "Bernier, Daniel" <daniel.bernier@bell.ca>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "UTTARO, JAMES" <ju1738@att.com>, LITKOWSKI Stephane OBS/OINIS <stephane.litkowski@orange.com>, "LINGALA, AVINASH" <ar977m@att.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Robert Raszuk <robert@raszuk.net>, Adrian Farrel <adrian@olddog.co.uk>
CC: mpls <mpls@ietf.org>, SPRING WG List <spring@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [mpls] [sfc] Progress with draft-farrel-mpls-sfc
Thread-Index: AQHTv44cG9B9ptUv4UC7eRb0xddHsqPZKgiAgAAFNYCAABIvAIAACGIAgACQj7s=
Date: Wed, 21 Mar 2018 00:53:29 +0000
Message-ID: <1521593607690.49171@bell.ca>
References: <019501d3bd6b$657d7ef0$30787cd0$@olddog.co.uk> <BB36A9A4-284C-4B36-BDE0-6B919273AB02@nokia.com> <00a001d3be17$e0ec3ca0$a2c4b5e0$@olddog.co.uk> <CA+b+ERmMKfuEaHgH4ZD3mq6A8YRuxKVxhmTtDQEFHU9zE4pwRQ@mail.gmail.com> <90F4F09A-4E4D-41B0-8B91-09AF2EDFC1A5@nokia.com> <787AE7BB302AE849A7480A190F8B93302DEE2A47@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <B17A6910EEDD1F45980687268941550F36721A4D@MISOUT7MSGUSRCD.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93302DEE304D@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <B17A6910EEDD1F45980687268941550F36721B24@MISOUT7MSGUSRCD.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93302DEE3199@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <B17A6910EEDD1F45980687268941550F36721C14@MISOUT7MSGUSRCD.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93302DEE3237@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <69C84E23D6485E46BBAC817C2860E07D4DB2A19C@MISOUT7MSGUSRCA.ITServices.sbc.com> <17637_1521541483_5AB0E16B_17637_25_1_7e586202-c151-4d51-88f6-5ccc3f028694@OPEXCLILM33.corporate.adroot.infra.ftgroup> <B17A6910EEDD1F45980687268941550F36722027@MISOUT7MSGUSRCD.ITServices.sbc.com>, <d8d054f4-03c3-48d4-a9f6-a37828f1b7ba@OPEXCNORM3D.corporate.adroot.infra.ftgroup>
In-Reply-To: <d8d054f4-03c3-48d4-a9f6-a37828f1b7ba@OPEXCNORM3D.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.1]
Content-Type: multipart/alternative; boundary="_000_152159360769049171bellca_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning daniel.bernier@bell.ca discourages use of 198.235.102.33 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Cod30Bok1g5O74hlG-zaABqdaIQ>
X-Mailman-Approved-At: Tue, 20 Mar 2018 23:15:59 -0700
Subject: Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2018 00:53:49 -0000

+1 to Jim and Avinash


Same challenge on our side.


Our network is built upon a MPLS data plane. My current "network appliances" are connected to MPLS devices and service instantiation done through static pseudowires. It will be easier for me to introduce SRTE policy capabilities through software upgrades instead of certifying and introducing new hardware to enable a newer encap.


And by the time we get to leverage contextual metadata between functions, most probably, these will have also evolved (micro-services, hw/sw disaggregation) and new ways of conveying that metadata will have been proposed.


Thanks,


PS: I am also wondering why it is so badly seen to look at alternatives to NSH SFC while at the same time we introduce new WG to discuss DC routing (RIFT, LSVR, ...). If we accept multiplicity in that space, and I think we should, then we should allow it in chain composition and programming.


Cheers,


Daniel Bernier


________________________________
From: mpls <mpls-bounces@ietf.org> on behalf of mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; bess@ietf.org; sfc@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you want a path to be steered relying upon some information conveyed in the packet and to invoke specific SFs, then you need to define the structure of such information and its meaning.

That is another piece of specification work to be yet done if you want it to be part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1738@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; sfc@ietf.org; bess@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of simple chains. I simply need SR to realize the chain. Why is the IETF forcing me to adopt technology that I do not need, while at the same time reducing the number of vendors that I may use in my network as this encap will have to be supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains are required. The reality of my world is that I have lots of simpler chains i.e FW, LB  and do not need the additional OPEX and CAPEX  costs associated with deploying NSH.

Jim Uttaro

From: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar977m@att.com<mailto:ar977m@att.com>>; BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the transport you want.


From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to see various encapsulation options for SFC. This would help an operator to pick the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, VXLAN, GENEVE,..

​​​​​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are requirements/constraints/new practices/new OAM procedures that need to be supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1738@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

                When I say simply, I am speaking as an operator. The operations, systems, tools, institutional knowledge etc… in this space is around MPLS. There is a simpler path to creating simple chains by using MPLS instead of introducing a new encap.

Thanks,
                Jim Uttaro

From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without any code upgrade.


NSH does provide the simple functionality you need; that is the information to identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with length is 0x2.

Of course you can encode that information using another channel, but still code change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1738@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

                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.

Thanks,
                Jim Uttaro

From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
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.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1738@att.com]
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; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
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.

Thanks,
                Jim Uttaro

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; sfc@ietf.org<mailto:sfc@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>
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?



Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org] 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; bess@ietf.org<mailto:bess@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>
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: <rraszuk@gmail.com<mailto:rraszuk@gmail.com>> on behalf of Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, mpls <mpls@ietf.org<mailto:mpls@ietf.org>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
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.

Cheers,
R.



On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> 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?

Cheers,
Adrian

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.