Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

"Adrian Farrel" <> Fri, 24 July 2015 17:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD6901A0233 for <>; Fri, 24 Jul 2015 10:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JRPRU7PqxQKP for <>; Fri, 24 Jul 2015 10:08:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F11F1A0217 for <>; Fri, 24 Jul 2015 10:08:40 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t6OH8cDS016858 for <>; Fri, 24 Jul 2015 18:08:38 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6OH8aJd016850 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <>; Fri, 24 Jul 2015 18:08:37 +0100
From: Adrian Farrel <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Fri, 24 Jul 2015 18:08:37 +0100
Message-ID: <0a8401d0c633$6228b0d0$267a1270$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIFBBCy8RZ/CxlvQaWWNxgEokAwzgDc/jE5Ab0WRiYCPfPxeAJiCcHdAUJKZgkCwfGxfQHS611nAniJ1ZadBgr1UA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--19.640-10.0-31-10
X-imss-scan-details: No--19.640-10.0-31-10
X-TMASE-MatchedRID: gzVbiXtWD9tlTYPLUKF/gPHkpkyUphL9CQ3xS+zL6e2Qcp7izK6RGBch drJv3xSnaVmmjIw6uTX0n3dotmyQeiFIFN2ANN3NjNvYZHpO13dB+8LAeeOOMBjQD3m2MCf7CtT YPpaUkKUUPm/3TsFL+lx+wuIZ62ksMrjYlVK+7cBIOSHptb5txxluk36HDQp78gW3ugGq8mI5d9 n04fLNZsIrvJSRinkgO2+Q6DWq9OzWG4H6gpT598NrWpY804TGviRliDV2nyyKvSwHZ9zxVIFof 8aeC04NOb4lL83Jz/300AgBAXs4SJjnwEDvOfN9cFEiuPxHjsXj5lyuq8IOQRxUkJPe1WBqMQYW N5nDJFRRYCkHwu6XM5HoyOpJ36wt/4moRhsEts2hLSC6hXpJlxhcBBg0V+bsERHkysQaiHkKBL0 NA6AeCeY3GOG0ig1OoQYVKjwKaWkB/868Hoi7s40jlXkSHG1ewoAL8oEWzRDkMnUVL5d0EwOR3t ZA0vji4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjkGUtrowrXLg=
Archived-At: <>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2015 17:08:42 -0000

> BTW, I understand perfectly well that there is some controversy about
> whether it is or is not a good idea to use domain-wide labels, but that
> is not a data plane issue, and the use of domain-wide labels does not
> require a change in the data plane architecture.

Thank you Eric!

It always saddens me when people choose to implement functional architectures as
though they were design documents for their product. Of course, the resulting
product will be functionally adequate, but it will not perform well. This
problem is well known across a number of standards organizations and we are not
immune, it would seem.

Some other standards bodies produce "equipment specifications" and these seem to
be used by a number of implementers to design their products without considering
best practices or optimizations. Equipment specifications from a  standards body
describe *a* way to achieve the required functionality, but they describe the
internals of a box and that is not something that can or should be standardized.
We specify black boxes and interoperate on the wire.

RFC 3031, as it describes the forwarding plane, is a functional architecture.
When it talks about label operations it describes, in functional terms, things
that happen and change the externally visible behavior (i.e. the packets). It is
completely true that 3031 could have described SWAP as POP'n'PUSH, and could
have introduced a term NO-SWAP equivalent to SWAP-TO-SAME or POP'n'PUSH-SAME.
But it didn't and it didn't lose any generality by doing so.

And it is OK for people to talk about NO-SWAP forwarding. You can even write an
informational I-D to say "There is an optimization in the MPLS forwarding plane
when the same label is used on a packet that comes in and goes out." I don't
believe such a document is needed, but why not write it if it helps you or you
strongly feel it might help others? It doesn't update 3031, but it provides some
alternative view. And yes, you describe all operations as POP'n'PUSH as well if
you want to, but again, I don't think it is needed.

With respect to domain-wide labels, please consider a network in which a mix of
labels is used. Some are per-interface, some are upstream-assigned, some are
per-platform, and some are global. Some LSPs terminate at this node (POP) and
some don't (SWAP, or NO-SWAP). Perhaps some LSPs are tunnelled onwards from this
node (SWAP or NO-SWAP, followed by PUSH). Perhaps other LSPs are stitched
(POP'n'PUSH, or SWAP, or NO-SWAP). When you receive a packet on an interface you
will have to examine the label and do some form of look-up. You cannot simply do
pass-through (decrementing and checking the TTL). You have to look up the label
at least to find out what type of label it is and decide what to do with it. The
look-up may be into a range or into the NHLFE for a one-to-one mapping. Etc.,

3031 does not mention global labels except for the special purpose label space.
That could be fixed with an update, or it could be observed that the global
label space is actually a mirrored (or distributed) per-platform label space
where each LSR uses the same label for the same destination. Which, by the
 way, is why SR could be supported using LDP (not that I am saying you'd want to
do this).