IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Tue, 20 March 2018 12:00 UTC

Return-Path: <rraszuk@gmail.com>
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 B5AAC12EAD9; Tue, 20 Mar 2018 05:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 EpK__5ypTA_f; Tue, 20 Mar 2018 05:00:01 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 D562612EA53; Tue, 20 Mar 2018 05:00:00 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id z12so1402086wrg.4; Tue, 20 Mar 2018 05:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=94sV/IJBUn1ccU3b8mtVBRbjdLx4btRbV0TXMcMlpSk=; b=CorT/TIMi+WDeQKRazBn/w1l3Bieqhc518XsZZsiYLIKH+/JxtNYj1OKCbata+euXS RHU4ve32qVKLmoR57zSiUYlftflFIMd2LOIVFXxXEsvCMeopQg/Z+AN/gHEar7McVr4c NgdGheL+ZSGsfn+yw3LZW7xtZE+ipxZjFkMPHhEbSb5q1DR/1skgNoMapPf2JLsSsp3s SBwrw2rAYlcjotws+uO21mP4C//7eTH3ZDdZ959xDCpHqMzrrCvhqoO3ojmiKqXK4rQP pyLIZ7mV65EgkkV/4Mxlhj5MnMg2TaCKCnsooqQvMCs+b/UfQ7Lw669oyy1HElEv+7BE lq1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=94sV/IJBUn1ccU3b8mtVBRbjdLx4btRbV0TXMcMlpSk=; b=qRMQ2M7hxyD3+VNhTWT4u7MMN9DQRBTKeBfflUvcdwdLN+LD77EZ8jmzcdoFgHrsX9 G+1dpDaAiTaN06LoVwRFpZXEatTR6zNXo5+BofI8p/7tg3lS1O57uNL0PuIw1iGmA3hp e8WEfSNZQqVcLJ7UAgHLiUM+wEeq/jvFoXexMJZxISChhzX3iT5thaDHuSm9chlrMrvP Y6o0FK1gec2IVlITICUvIg0alNEbtBcnwFTFoESKSm+8gz3dAH03k/TNTpCIhg7dyNIu wOnY2V95Q9K7qL4o3E3eTa1tG6n+cEdNk4/LQvg4gtvP9sFSUQRqL7gYuNhtBuShjAZK 2PWw==
X-Gm-Message-State: AElRT7Fpm31pleKNkg/q7lLjDLYAZ4jG4lMeyNn7m9YrGjnZVF5BunJz dXxfmwzZVW4RsLwE6qQXHL8Uw/sZ4+/BJGY6uKI=
X-Google-Smtp-Source: AG47ELvmxuQk2YajDN9yEMccN5dcle4BGJAARHBPa6KczTfxxPWrxidEo/1xNyE8Spl+8Ls5gqiJ/hVf6FG5iJCOJSg=
X-Received: by 10.223.196.141 with SMTP id m13mr12578972wrf.173.1521547199129; Tue, 20 Mar 2018 04:59:59 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.222.197 with HTTP; Tue, 20 Mar 2018 04:59:58 -0700 (PDT)
In-Reply-To: <B17A6910EEDD1F45980687268941550F36722027@MISOUT7MSGUSRCD.ITServices.sbc.com>
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>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 20 Mar 2018 12:59:58 +0100
X-Google-Sender-Auth: WBHq0iltzV0lDFA87WgInaz6jZY
Message-ID: <CA+b+ERnACm9cXDiYuaLcpoNHUX=z3o-=fJq8LtWLfnWvuxWeSA@mail.gmail.com>
To: "UTTARO, JAMES" <ju1738@att.com>
Cc: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "LINGALA, AVINASH" <ar977m@att.com>, BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Adrian Farrel <adrian@olddog.co.uk>, mpls <mpls@ietf.org>, SPRING WG List <spring@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f526e502ef60567d6d047"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ctJ0_oTOk7E37P817zKfd7FoeH0>
X-Mailman-Approved-At: Tue, 20 Mar 2018 06:30:10 -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: Tue, 20 Mar 2018 12:00:17 -0000

Jim & Avinash,

Please let's observe that Adrian removed any references to Segment Routing.
What this means that the current proposal is based on vanilla MPLS labels
which by base MPLS architecture have **local significance*. *

You can't assume that out of the sudden label has domain wide or global
meaning with SR references removed any more.

If so this draft in question is not required to dynamically signal a label
bound by operator to given service in a control plane. Just like you
advertise any other label which has local meaning by the node advertising
it. As we pointed out draft-ietf-bess-service-chaining-04 is one option to
signal this. They may be other options, but you either treat label as local
or as domain wide. You can't pretend that under the umbrella of doing
former you are effectively doing latter without admitting it.

Best,
Robert.


On Tue, Mar 20, 2018 at 12:29 PM, UTTARO, JAMES <ju1738@att.com> wrote:

> *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*
>

v2.23.0 | Report a Bug | By Email