[mpls] draft-fang-mpls-label-forwarding-no-swap-00

Robert Raszuk <robert@raszuk.net> Thu, 23 July 2015 15:30 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8B14E1A8767 for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 08:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 86SxbsukLDaN for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 08:30:52 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 CBD841A7D83 for <mpls@ietf.org>; Thu, 23 Jul 2015 08:30:51 -0700 (PDT)
Received: by wicgb10 with SMTP id gb10so148389592wic.1 for <mpls@ietf.org>; Thu, 23 Jul 2015 08:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=uWEYxF9Wq304wgvKfqvSLwgOpfT7MX/zy5xycAGueJ0=; b=qnXYm1TLNXi3CQ79BOMNVIHcXyy/0biSsAZXLiaq7zr2IB2u2LNxHCdwim06Iwz9Gy d6T6gfIgYhob1LbUcmNYt8DYc/UjOTmNaB1v+bBWCcVy89NdsN9jRQu26iFxdzeAF3wn h5C0o1sdioqXJHEreowDWZWvHNj0uRVUP2+vr/T8+AVYMyNxjLRoHWLzozCiQKiq+BJk ZRnvQZDbd/mkEkSqbInOtFsrqwPqZw35+u35XnTIUMhlMykkIS6EF/xWxvoZtnITZjlo lKRCj1moK4SMOX5SSgCBgdM85TDOWrrfoZ+e1AWyrV5s2pOcI0Gawz4qe4vvu9HBP8SG Ze8w==
MIME-Version: 1.0
X-Received: by with SMTP id ho6mr54334806wib.58.1437665450597; Thu, 23 Jul 2015 08:30:50 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by with HTTP; Thu, 23 Jul 2015 08:30:50 -0700 (PDT)
Date: Thu, 23 Jul 2015 17:30:50 +0200
X-Google-Sender-Auth: 4N_J0kOt9E6Po4fkSYh5whKxnWE
Message-ID: <CA+b+ER=c2rW7u2aj0ohnKtpmpz7t+xibHPaQd9B9WvOxU91t7g@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Luyuan Fang <lufang@microsoft.com>
Content-Type: multipart/alternative; boundary="e89a8f3ba5f37d2430051b8c9247"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Wmw8Fn8QXtQd28OetVK1R5QaU9I>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] draft-fang-mpls-label-forwarding-no-swap-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jul 2015 15:30:53 -0000


Few comments, questions on this proposal.

Comment #1:

I very much agree with this draft document that RFC3031 has no explicit
provision for operation which does not require label rewrite. IMO the
update to RFC3031 is needed perhaps by issuing RFC3031bis.

It is implementation optimization how the hardware lookup and header
rewrite are done. But this is not the point here.

It matters to provide right set of label forwarding primitives such that
new protocol work and new architectures which chooses to still use MPLS as
their data plane in non local label scope can be consistently build on top.

As we all recall when RFC3031 was defined some folks were allergic to
anything other then local label significance :)

Therefor I support this document as a base to update RFC3031.

Comment #2:

We already see two individual workarounds and likely we will see more which
try to address the very same problem.

We see H-SDN inventing the term NO_SWAP.

We also see a Segment Routing which cleverly defined a new CONTINUE
operation and simply defined it as MPLS label swap.

"The CONTINUE operation is implemented as an MPLS swap operation."

SRC: draft-ietf-spring-segment-routing-mpls-01

Question 1:

Does this WG wants to see zoo of new terminology across IETF and broader
industry or perhaps ack on the problem and address it ?

Question 2:

What happens if hardware vendor comes with hardware which exposes to
control plane API which allow protocols to signal that mpls label Y is not
to be swapped ?

If so which IETF document such API would be compliant with ?