Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc
Stewart Bryant <stewart.bryant@gmail.com> Thu, 12 April 2018 15:04 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2012D940; Thu, 12 Apr 2018 08:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MAp1IiGZ-X2i; Thu, 12 Apr 2018 08:04:13 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E1612D881; Thu, 12 Apr 2018 08:04:12 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id u46so5450301wrc.11; Thu, 12 Apr 2018 08:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=rBEjTS23NgpXQzMZLNg38czumA/kdnh1pZX8iPuSpxk=; b=TtJYa7dS4KWZfY5SXlUcpoHwtl9om7Rl4PxCHkCG5ummNoZOgRbI0xO5X8tLp8Wt3a wkrKIsyEX+dRtWI1ZOjNuDYsjs1UC1HBzyCqR22qnQcJa9h9llNdz6XX54cQlO7gKRkT FLsfeyWfN9N5D4mOdj5XzD6tBVyM4raHGhDV6aafO8UC6QMR3/sIze21IdIZtL50hlAf UgczzREGAax3Yut6skHZu+200zZmVcebpMeAT6NLXHGdu8NtbtK9b+Dz27RDqTaZj4k8 qF0G6tdsACyCaiMvM+t3H071eAYMK40FBs0ZEkBfs4l+IyH6vay773JeOn8AAysSLQYW LbRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rBEjTS23NgpXQzMZLNg38czumA/kdnh1pZX8iPuSpxk=; b=JKylz8sIgvPjghkFdubtSxP/Gmovi85X9mTn+KU/Zudz5BD3cZ2t6n2CW+j0Tz+Xhe kZWRLu2LdEsN9ZOo884SbeGHlimppj3NeQZhJJS8tZgGD6bBTSfnrgd2QcUeWzTRquBZ BkgQWeoRvqW+3FbHnVTBUsTWgc4eJZN5cqiwlYICJU5hKh4gGPpgZ63bOZb0SgU4Q/VG MNMUOoBevZJkYw9AY7lftie30uCWusE4mF1gLZsLm1eQPQp57Ruk9CAIyGBTJ742rEGj VE5LVSELlrC8rE5hH0L6KRXIOhiTs+iHO3rF5icAtks0yKsIj9EKTJhClCUVcuio3rID +fZg==
X-Gm-Message-State: ALQs6tBtn7iuRP5IfipNau3LIY6b/lOrxR3hXWUnQKFwyACZajnRYS8L 0jR3FIYXVUKR9DUYglgZh3hTdeyD
X-Google-Smtp-Source: AIpwx4/l3zNGGytUp55WFPREnGvwGLY/bREmfaEUXoab1H1m+keBOdnvaL0dbCCWPegfcV9xg/JMDA==
X-Received: by 10.223.158.201 with SMTP id b9mr1034688wrf.215.1523545450674; Thu, 12 Apr 2018 08:04:10 -0700 (PDT)
Received: from [172.20.3.97] ([46.218.58.220]) by smtp.gmail.com with ESMTPSA id y9sm4933784wrg.46.2018.04.12.08.04.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 08:04:09 -0700 (PDT)
To: "Bernier, Daniel" <daniel.bernier@bell.ca>, Robert Raszuk <robert@raszuk.net>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <489a9667-f159-4607-5834-b4bacf64989c@gmail.com>
Date: Thu, 12 Apr 2018 17:04:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1522812352107.5966@bell.ca>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/bG_jgZorqOqkHKgd6B3x9UJb0lE>
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 15:04:15 -0000
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] Working Group adoption of draft-farrel-mpl… Loa Andersson
- Re: [mpls] Working Group adoption of draft-farrel… 徐小虎(义先)
- Re: [mpls] Working Group adoption of draft-farrel… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [mpls] Working Group adoption of draft-farrel… Chengli (IP Technology Research)
- Re: [mpls] Working Group adoption of draft-farrel… Robert Raszuk
- Re: [mpls] [sfc] Working Group adoption of draft-… BRUNGARD, DEBORAH A
- Re: [mpls] [sfc] Working Group adoption of draft-… Robert Raszuk
- Re: [mpls] [sfc] Working Group adoption of draft-… BRUNGARD, DEBORAH A
- Re: [mpls] [sfc] Working Group adoption of draft-… 徐小虎(义先)
- Re: [mpls] [sfc] Working Group adoption of draft-… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [mpls] [sfc] Working Group adoption of draft-… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [mpls] [sfc] Working Group adoption of draft-… Zafar Ali (zali)
- [mpls] 回复: [sfc] Working Group adoption of draft-… 徐小虎(义先)
- Re: [mpls] [sfc] Working Group adoption of draft-… Bernier, Daniel
- [mpls] 答复: [sfc] Working Group adoption of draft-… Lizhenbin
- Re: [mpls] [sfc] Working Group adoption of draft-… Robert Raszuk
- Re: [mpls] Working Group adoption of draft-farrel… Loa Andersson
- Re: [mpls] [sfc] Working Group adoption of draft-… Bernier, Daniel
- Re: [mpls] Working Group adoption of draft-farrel… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [mpls] Working Group adoption of draft-farrel… 徐小虎(义先)
- Re: [mpls] Working Group adoption of draft-farrel… Loa Andersson
- Re: [mpls] Working Group adoption of draft-farrel… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [mpls] [sfc] Working Group adoption of draft-… Dolganow, Andrew (Nokia - SG/Singapore)
- Re: [mpls] [sfc] Working Group adoption of draft-… 徐小虎(义先)
- Re: [mpls] Working Group adoption of draft-farrel… Robert Raszuk
- Re: [mpls] [sfc] Working Group adoption of draft-… Zafar Ali (zali)
- Re: [mpls] [sfc] Working Group adoption of draft-… Stewart Bryant
- Re: [mpls] [sfc] Working Group adoption of draft-… UTTARO, JAMES
- Re: [mpls] [sfc] Working Group adoption of draft-… Alexander Vainshtein
- Re: [mpls] [sfc] Working Group adoption of draft-… Robert Raszuk
- Re: [mpls] [sfc] Working Group adoption of draft-… Stewart Bryant
- Re: [mpls] [sfc] Working Group adoption of draft-… Robert Raszuk
- Re: [mpls] [sfc] Working Group adoption of draft-… 徐小虎(义先)
- Re: [mpls] [sfc] Working Group adoption of draft-… Stewart Bryant
- Re: [mpls] [sfc] Working Group adoption of draft-… 徐小虎(义先)
- Re: [mpls] [sfc] Working Group adoption of draft-… Stewart Bryant
- Re: [mpls] [sfc] Working Group adoption of draft-… Zafar Ali (zali)
- Re: [mpls] [sfc] Working Group adoption of draft-… Andrew G. Malis
- Re: [mpls] [sfc] Working Group adoption of draft-… Andrew G. Malis
- Re: [mpls] [sfc] Working Group adoption of draft-… Lizhong Jin
- Re: [mpls] [sfc] Working Group adoption of draft-… bruno.decraene
- Re: [mpls] [sfc] Working Group adoption of draft-… Adrian Farrel
- Re: [mpls] [sfc] Working Group adoption of draft-… Loa Andersson
- Re: [mpls] [sfc] Working Group adoption of draft-… Andrew G. Malis