Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 12 April 2018 15:19 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CCC12D881; Thu, 12 Apr 2018 08:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 xZRuCVVc9ZOr; Thu, 12 Apr 2018 08:19:48 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.4]) (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 1D9771201FA; Thu, 12 Apr 2018 08:19:46 -0700 (PDT)
Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-central-1.aws.symcld.net id 38/14-30567-1197FCA5; Thu, 12 Apr 2018 15:19:45 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0gUURTHu/PaSdwaV8vTmh/cHpA1i1tJWxD 0QhYzKCICs8fsNrmDu6vsjLn2ANveK5WBUlqsbdm7KEXTssgsrCS1tCKNTU0tK4yosPxSzexs r/vpd+/v3POfuRwa19VTepr3SLzbxTkMVAQxe9r3yWxUflt6UvkIMn+4/Jo0d50+T5q9AS9u7 u+p0Zibe7gFpOXSyEfMcr0sqLFUVIxglvrKE9hyIp0UXNZszwbS3uofIHKC8Z7+L8+pAtQLPh RBE8weHIoaDhHKRscUY9BUtyO86UGw11+I+dBommLmQ9XFIKVwDLMd9t2rCp3jzCIoONuBFI5 mUsFbX6dRa5bCy9snw2yF4Sf+EBPMFPA2DeIKa5kMODD8RKOGvSTh3F5fqNFoOezizY5QEWLG w7fmS+GwWOjqLw8xMAxU3GzDVR4H7/p+kGq9FboHAkg9T4Cjr45rVI6H9vJCpIQBU43Bs6tDY cHCp5ISuREt8ySoHlyr1txFUL2vl1BrEmFny/5wcBZ8rLtBqZwBL/y3MPXCSRwaH78lVTER/J /7wmmnKLjyriPUScfY4MHxL4Qq+hDs6K6hihBb9s/vqZwErbWVGpWnw5nAB7ws9GZR8LC0nzi BiAvIbHULmXbJyQkO1pSUxJpMs9hZbPIcI7eF5Yx8LmvjXZKbk6WRyxONYr7T5thodPFSFZKH apS86tCdFq4RTaAxwzhtZUZbum6MNXtjvp0T7evduQ5ebEQTadoA2rEe2UW5+Uzes0lwyJP5W wMdaYjRTlG0VszhnKKQqapmlKCP1Q7lyYJRhD3X9efa75luR/H6aC2SP0QXmcO7nYL0v3+PYm lkiNYuVtpHCi7pT/f3cjAmBzelPVKCJe6v0heg3V1zV9fMnTx7V+mxQOnAjBsLx9iyF7Tfnnk sbrDcviyFaRqa52yIbv0MKV9LJE7QmzrHP/L9PPKpaGpgXUntm/u3CtYk+gotKWfivmUxuq1k yvxFm21zvEFhxvo46mByRGfvEqrTK2ai1Jxg99OYPRdqpWsrtjes2n24eNvwyrQ3BkK0c6ZE3 C1yvwD+btjbzgMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-9.tower-228.messagelabs.com!1523546381!379883!1
X-Originating-IP: [52.41.248.36]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 3274 invoked from network); 12 Apr 2018 15:19:44 -0000
Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-9.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Apr 2018 15:19:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a3ftQ8Lon5An8+ruYtGgUXSPY7AZDyJNAqtbFXUParI=; b=DYtVk1XNNNIHmkWDT0STp8f8FxwVJhjkwFP7g/MWDRUmNjRvsWvv2jfcSza6lavyk/8T3db5qP+rkBso3Mkrzp4NjH9F73ayU+JAilfZZH7wGe56GD3CXC6B/KZhlywQlUaw8fkLHlQyXjI90zigjLr+yNop4phJaa1J8fbg/aA=
Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0665.eurprd03.prod.outlook.com (10.255.184.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 12 Apr 2018 15:19:38 +0000
Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::d900:fa47:ee6d:6b0c]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::d900:fa47:ee6d:6b0c%13]) with mapi id 15.20.0653.015; Thu, 12 Apr 2018 15:19:38 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "Bernier, Daniel" <daniel.bernier@bell.ca>, Robert Raszuk <robert@raszuk.net>
CC: "mpls@ietf.org" <mpls@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc
Thread-Index: AQHTx4/0V5oXJ9epS0qKNUITZ6AJ5KPnlH+AgAAOXICAAYB4gIACJsaAgAIUHgCAApvtAIANVcCAgAADNpA=
Date: Thu, 12 Apr 2018 15:19:38 +0000
Message-ID: <DB3PR03MB0969B99569852875E3E865FF9DBC0@DB3PR03MB0969.eurprd03.prod.outlook.com>
References: <2ac6b61d-3a38-1aaf-62ae-d923f1ad7468@pi.nu> <a392880f-6b86-4406-a348-42398e24285a.xiaohu.xxh@alibaba-inc.com> <DB5PR07MB158998C7FAAB4831C243D88D83A30@DB5PR07MB1589.eurprd07.prod.outlook.com> <CA+b+ERnJNad6Awo+-2dU2kz6rwx-HQEniXcWgjoWUd-zm3r2qQ@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C88828EFEB@MISOUT7MSGUSRDE.ITServices.sbc.com> <CA+b+ER==g53MZK5RSNmaFkg1UBC8zEiNsfxNLKCNXDumannaHg@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C88828F06D@MISOUT7MSGUSRDE.ITServices.sbc.com> <052998BB-B820-412C-8363-B3EB7551B299@nokia.com> <1522554645079.8864@bell.ca> <CA+b+ERmzFPZRyrCnBvnRVhK5F25RMc8+Wt-n6NXKrONWy9G+_g@mail.gmail.com> <1522812352107.5966@bell.ca> <489a9667-f159-4607-5834-b4bacf64989c@gmail.com>
In-Reply-To: <489a9667-f159-4607-5834-b4bacf64989c@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR03MB0665; 7:KnQIMAPawfzSDJ0PrNuExPrzKVNcHrV9/sK35tDlspdYCDYtvFzNZUPwfUipJ6wxwu7aXycp2PcmtHGfaGWIdXJmxgbUe3gli98Kzh9i35xZnUnxEZZaE+G76pzovAHusoCgDBhO0+WcnSDdbjDty704vE0FfOXziZ9irhYnxRaaunkLAIJFJAqkjU3dDasvo8G/OIf+9BVYYg2r9mhk+htXFubXRRo8kyIl9K9/vHgmclYMaTFXo2FBjGtoDKBS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB3PR03MB0665;
x-ms-traffictypediagnostic: DB3PR03MB0665:
x-microsoft-antispam-prvs: <DB3PR03MB06651C434EC46F05A1EAA0F89DBC0@DB3PR03MB0665.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(226690903318834)(15185016700835)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR03MB0665; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0665;
x-forefront-prvs: 06400060E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(376002)(346002)(39380400002)(13464003)(252514010)(51444003)(189003)(199004)(2900100001)(86362001)(5660300001)(66066001)(7696005)(72206003)(446003)(26005)(6506007)(8936002)(316002)(54906003)(3660700001)(106356001)(76176011)(2906002)(478600001)(305945005)(4326008)(25786009)(93886005)(102836004)(39060400002)(99286004)(11346002)(110136005)(186003)(7736002)(3280700002)(53546011)(966005)(5250100002)(6246003)(53936002)(6116002)(97736004)(74316002)(81156014)(3846002)(9686003)(229853002)(55016002)(33656002)(68736007)(14454004)(476003)(6306002)(81166006)(105586002)(486006)(8676002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0665; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Szl+8o9LA3BGyQqn4SGun+ocTm9fRUVkfZoexhrwe2oGwAPPHiBDF9IFeCmeVZUlH361+BeVpR8jQZvBOCgWNir8W8G/dM2A4EntFMJgZAU9nlHqnIeMiVAvDCQWiNR6gP7bCVr/dAbuSaI/QjZQWvyGGvejj52N25d17YaqZtaub6dHJuy/FEZDufp4wm2G
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 8eb7b29d-4b10-4e43-35bb-08d5a088cec6
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8eb7b29d-4b10-4e43-35bb-08d5a088cec6
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 15:19:38.6948 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0665
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/x2SWcxxPfgb70D2JnIzAeqdtnUE>
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 15:19:50 -0000

Stewart and all,
I concur with Stewart with one minor correction: the "simple edge routers" are not the only category of routers that would have problems with imposition of a very deep label stack. And the problem with such stacks goes beyond imposition if effective ECMP is supposed to be used by transit routers, because the labels that carry entropy are located somewhere at the bottom of the label stack and therefore may be not readable by transit routers even if imposition succeeded...

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Thursday, April 12, 2018 6:04 PM
To: Bernier, Daniel <daniel.bernier@bell.ca>; Robert Raszuk <robert@raszuk.net>
Cc: mpls@ietf.org; sfc@ietf.org
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc


Rather than have a process discussion, I think we should go up a level and better understand the technical differences between the two drafts.

draft-farrel-mpls-sfc describes the actions at a hop in terms of a tuple that mirrors the SFC approach that allows a short indication of potentially re-entrant chains. In its simplest form it uses a compact MPLS stack to describe an arbitarily complex path that is compatile with simple edge routers which are often challenged in terms of the number of labels that they can push.

draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly calls out each hop and each function into the label stack. This results in a much larger MPLS label stack that will challenge some edge routers. 
The way that we generally deal with imposition limits is through the use of binding-SIDs, which in the limiting case resolves to the approach in draft-farrel with the limitation that the position on the path is implicit in the label stack size rather than explicitly specified by the SI.

Mid-flight path changes (if such things are needed) is clearly simpler with draft-farrel.

The short stack in draft-farrel comes at the cost of greater network forwarding stack, and the long stack is the price that draft-xu-clad pays for the reduction in forwarding state.

The optimal design point between forwarding and control plane state is something that is dependent on many parameters, and is dependent on many network and operational factors, so much so, that don't think it is wise to rule either out of scope at this stage.

The hybrid mode in section 6 of draft-farrel supports the mixed mode in section 7 of the draft. This allows the construction of SFCs that are the concatination of two or more compacted sub-chains. This allows the operator to deploy a solution with the advantages of draft-farrel together with some of the flexibility of draft-xu-clad.

At this stage the two drafts are sufficienly different that I think we need to proceed with both at least to the point where we fully understand the detailed consequences of the two approachs and the scenarios where each finds it's niche.

After developing a better understanding the detail of each design, their control plane, and operational contexts and how each maps to customer network requirements, we can move the drafts to the appropriate IETF track. Such tracks may be anything from abandonment to IETF standard for one or both of these approaches.

Meanwhile I think that we need to focus our efforts on a deeper understanding of the technology and how each might make the Internet work better,  rather than spending effort on arguing about IETF process.

- Stewart

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________