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

Robert Raszuk <robert@raszuk.net> Sat, 17 March 2018 18:13 UTC

Return-Path: <rraszuk@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 B8126129C6A; Sat, 17 Mar 2018 11:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 HTxlS9s_g8-n; Sat, 17 Mar 2018 11:13:38 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 AC340128D2E; Sat, 17 Mar 2018 11:13:37 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id s206so6988322wme.0; Sat, 17 Mar 2018 11:13:37 -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=ca6RkZo0okzedSLRzvGzqpF8WgGtgqCfKqYPk2su0UA=; b=klLlqF6b/po4ZyB+WH1fSV6I0EkaOgADzJXPNFFNic8sUDUiIHZ1bf99ZG+hBDq1Xr J/WTJdLic7vFCGBmauMcoewSYei9lyYumrdTPBQLX7mgwKVNgOXpivvM17pHl9+LM9/y p1Bv/1D1ZSAobLJUlyCR8Tbw6cfwMHfzbPhsPUK+wt3dKK414fvQ3NaX2gqFdfxw6MIO a9HvX0x3o0aDJxvcuravfuGBiahu0DiPlTC4Q8MGNne3uXQDJkRrbTRI3smwJPL8YIdg o2j/IKOubh75Cl63BKeE/ZCpSzyvJyZsXrwaQ3QCVNcQh6cZ3ygHO66QgVn1Um+V4gYt idTQ==
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=ca6RkZo0okzedSLRzvGzqpF8WgGtgqCfKqYPk2su0UA=; b=RyrXLG3PpnCIE4QKY5ofzEzbyNLXJWm4tYFi0XmnlRCr77soJvt7LtvcOEDcs70JfZ iqOUTnjXzCanIFcP2Xtlxoti9ExwkiFpnqmafSvK3Dx7ODz4Ejk/bL68yV2tZB+199pP jN/Yc1JfFcnS010jkRamiqWUwV5I6YTCrut0DM5iNcA8jwEkWDArBUEm32+Y14ztBLgT mRHtccEK4Lwld14Fcvmv6R459l5wQQ+TxL9L+rtf//ljIM6IuPRGSmElB7sAhHjFOA6o JF4S3MxYxQtg0Cgvv3s8N+NAOn0TgQhCjpFtRuoFFoiXAUDLg8MoAn4WgHiD2NWZPAC9 KSCg==
X-Gm-Message-State: AElRT7E+YHo+NHsRIdNiJlMaSJ2+zR+yVCvKEB8/qsG6mV4bXe0lOrXV /EYQkdAbW+Fxq3Ia3PHwZmT/Ztfi1WODe6pXh+o=
X-Google-Smtp-Source: AG47ELuYrR3N81jOkjjqezPL9b2NT/XDBP1PFAm1dHL7PqC+zI1JPN2WRmZWp5SOVVAhz2QMHYPdpOYISefDUh3QEiw=
X-Received: by 10.28.40.195 with SMTP id o186mr4556738wmo.134.1521310415807; Sat, 17 Mar 2018 11:13:35 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.57.86 with HTTP; Sat, 17 Mar 2018 11:13:35 -0700 (PDT)
In-Reply-To: <00a001d3be17$e0ec3ca0$a2c4b5e0$@olddog.co.uk>
References: <019501d3bd6b$657d7ef0$30787cd0$@olddog.co.uk> <BB36A9A4-284C-4B36-BDE0-6B919273AB02@nokia.com> <00a001d3be17$e0ec3ca0$a2c4b5e0$@olddog.co.uk>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 17 Mar 2018 19:13:35 +0100
X-Google-Sender-Auth: _b86zv6VNxfcPy_rRxeRAhIY5MI
Message-ID: <CA+b+ERmMKfuEaHgH4ZD3mq6A8YRuxKVxhmTtDQEFHU9zE4pwRQ@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, mpls <mpls@ietf.org>, SPRING WG List <spring@ietf.org>, sfc@ietf.org, bess@ietf.org
Content-Type: multipart/alternative; boundary="001a1143b598ed698205679faeb0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2j4xazcmAS-3hz3K09b3SiKeQ5E>
Subject: Re: [mpls] [sfc] Progress with 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: Sat, 17 Mar 2018 18:13:40 -0000

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