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

Eric C Rosen <erosen@juniper.net> Fri, 24 July 2015 16:30 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC051AC3A0 for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 09:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 k-AWSCzG8pYL for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 09:30:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF601A9092 for <mpls@ietf.org>; Fri, 24 Jul 2015 09:30:03 -0700 (PDT)
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;
Received: from [172.29.32.141] (66.129.241.14) by CY1PR0501MB1099.namprd05.prod.outlook.com (10.160.144.141) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 16:29:47 +0000
To: Robert Raszuk <robert@raszuk.net>
References: <55AD19F2.1010206@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com> <55AD2DAD.4060908@juniper.net> <4A6CE49E6084B141B15C0713B8993F2831F73F3A@SJEXCHMB12.corp.ad.broadcom.com> <55AD416D.2020306@juniper.net> <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com> <55B15C59.5040105@juniper.net> <CA+b+ERnWSg-BoxhntMmSXfBfj0mWhscuZ1VUdUkC0k0xDLd4Tw@mail.gmail.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <55B267F6.80106@juniper.net>
Date: Fri, 24 Jul 2015 12:29:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERnWSg-BoxhntMmSXfBfj0mWhscuZ1VUdUkC0k0xDLd4Tw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: CY1PR0101CA0012.prod.exchangelabs.com (25.162.170.22) To CY1PR0501MB1099.namprd05.prod.outlook.com (25.160.144.141)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 2:igJC0fVWUzzzqwrqztVHq5uSTNkULZw1t+GHYEZeRNqRs3oEQU14+7A0u1VnDf6p; 3:lo2LZEtcNHKDuaGurHTMRuIx+wLvJW53Afa9bn8dCBD2C73V95kYRosTO0LjbFd+jaE/d8Bx4Tvzm5ApMFK9gSpu1ODeqpsdhgXeou3hnhXxL1xvA9zd0Dik0tpMSvwWLoxMStnw9I9u3wqzPQ3wGQ==; 25:PahCAvnZugN9vrHNNeCuZkPIj5KMrOiK+nUdj8kbtsJZxhWMV+UPBIAcxJCryKEgUUa/KhuN24VWzNgZHg+cjXZgKl2lnGhaSRWPG5pLK4qlcyJ4rGLV5gIqQ885Fd4htGB4eO2BeJBj6uwnx9lN3Y4cVJrc8MMYFZaJ1MtFAgqOcMTifzytp+0Dz9VDwzwa+IZUswTtMKuk0exoykgdyAXvu5LPAFEbdaWGRKqe8Pm/3Z5v2y5B8nKnFW/fX6g1MpFQt5AhC+/cK3nK2+/kLA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1099;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 20:7gS0OPZeRzuYEvTfKu1eXIo80QILyKys37HS18w1Cj+dqsL2AZosP8ncPauhTe90KgHyetq7BFqXkiA9+H/TcP/eo13ziHBlgJY2GzGT7RAP0F/UzvQYUHLJjKN3KdyQP7kcqDeeqgR52F4K1+dnNj3AxyVPmR4dI1AC1obpKisH+pmHQ6GwG8ukOwH+3ooFV2A0oGZr8I9zWdJs72aB6sI0zM4/outr2WTjB3Wz08RdD/+tod6gQaBmi5NZDVpLN+EYri79OpBZRHkoBETOBk9dwEaszo1k70F+st18oQ5jPfB3lJxcbxRHOhH6Kj0qpUPLW2tf6kiujFZbeN2zFXUh60x4MEpHkoNWIvgQ6ZYOBA0ZNzoUlPkb+9DC9WmxYahODQS37Aq7yvw67+sib/fdQp6mxC2aDX6l1L+vweR1I8K0l9OHzwf5OgtRntzqO16qmpC1bn8pGoOB9yUAfIzollkGfU4rGgC6pfBQmbWWFoqWGqmltIY+Y0YZf2WX; 4:IAo/1eLw6u+mgq0/1oguYrX4Ue0HTrO/eMH+dUAVlut8fZWWWgw9t7outRC4Z81Hluk9XAs184E7ATuUNmd/33xnSxhkLT/pme7JUXCmF85Brib0Y6pZZXO9qzD0G1OT6NQeOGtzL+bfufEpt65macbxCFL7mp5s7+YjczbHSyZpcAX9n4Jdd8ObGKlqkJXyyeqslPusoPmF+qUewXmbbw8ouPTdMWBN/MpaKj/bUYovtdOc2exj1A8Zd1zM6ODZZFPOCOYCJoAZY+fjzVtYaeg5UHbUcCA4RYKgDjkoi10=
CY1PR0501MB1099: X-MS-Exchange-Organization-RulesExecuted
X-Microsoft-Antispam-PRVS: <CY1PR0501MB10993533907EFBA12E0D04DFD4810@CY1PR0501MB1099.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1099; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1099;
X-Forefront-PRVS: 0647963F84
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(479174004)(377454003)(110136002)(87976001)(42186005)(93886004)(230783001)(86362001)(54356999)(76176999)(77096005)(33656002)(65816999)(4001350100001)(5001960100002)(122386002)(40100003)(62966003)(92566002)(2950100001)(5001920100001)(50986999)(46102003)(65806001)(66066001)(47776003)(65956001)(77156002)(189998001)(83506001)(50466002)(23676002)(36756003)(64126003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1099; H:[172.29.32.141]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1099;23:c+7a46uUadkVq1Gx4uKurQQ3O8BW0dehWYpYDlktc3OQaIPhUBaj6IbQtnGS7SxJvHf8Clx82eTvQvGnRmM+u+ksPWal2P8VyehESkN6X17LA0IgzrExOR6wFJ5ZOMzFZeaTzTs2YRJbRYi9zbLFVPlnS2ISsMxN3NCAblLiEtBdVUw4MzQyl16zEUf0gDnMSEud465RvPa4VPHSTekb30rhnNUXfzotVlypFf7Z02zk5YhDOtZ3Bc+3OotyVdUCM66zwO1zMYc3aBW0Hen9NtumKjxdEfsF6Vyi3/QXXVNXuhSCHmtiuQRAsz+aiKZQcDAEtmp5SAmkxmzWvH3UhnqZ14ApOu+z+Crtcq21Kkxn01Eh7IEl5TggT/PIho+YPtKUtCqSI04LVxdvQyBZNLUJ7zRjURFW1PoM1rWLGZ6D/HieQYVeOKPZjMS4YUxx1jh3EM7yKV8Bvmraad9005FP6y7qTzvcPAOfUSLRuIMgwGI2Tmfo54lHAmkrmlMGgJMHsuGQ0qQV68W8zWgHxaSREAX2sYImuzOqchXFFcAFOqY84q/mpy/U3dnl6D/JQsjcYr/iKKwAZ13OerC/cMroY59SqiYiAEEyIx17rxYxivT//1mXjyZfzLE3067PNisPg5vmd0VflV5vq6/MJVQZB/SvVZ7VqPvFz89dM16n7skH3KltB3Sxp2hUNKpyc0zpU94iq1owOHIejEzqwJLX+e0ZMiufi69B9Pc4sL/Vu3DnF8ttPD40X5Pq9SymnQ/l3zKXyUestpJjuWaoWyqH65E/xvaax5oSEFCeLAB7kuJYEigDettUGF6yb/W+xPg7hGsNduqCqEE1mj0gUeH0xgN5Q254eMRvKorWnYpjoREp0ahQvYLj6sDxy8tE0yW2Cd7fUf7oYP8YEKg6mnlBpFnFy3dZtgXh4SOhz8E26uaClk4pLwNqzciGANwBtAyavJ5s/a+kRQqpqGxoqvnMkJOUECIaRN2RzmgNWpc=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 5:Tv+R5i4kB6s2T8YacbE19SBwQew1RIlGj31Lk4e63/GtSFE2RhVC1C4CA6LYyyO12O3/UMnbylJzbku315ouXIK39LAiPH1hRwObVXLFWn6vH78xPvtOlBTEiYwJ1TNEaNccSg4ZvX+PUte+jPC4wA==; 24:afR/5qPFGB9Vi+SU3rm2qA0jpskBWj6Aeu6LvtZQwTBpzoquNzPDRe4rEzacylsyPVS0+axE7l+UdoS4zU88+hjLuUzKb7OlK3Lbcj7aBEg=; 20:PAuylKw37ZzAivdsvqwbPhPeM5mgM1ZGvtnlQMHvqWNYMVGDwxz+N9ZGtojRitcJjt9RpRwvO+B+NpqWLttbTA==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2015 16:29:47.5719 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1099
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/u1XO32dm7J2w8MdKVU7Yy0oTkxw>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
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: Fri, 24 Jul 2015 16:30:05 -0000

On 7/23/2015 5:31 PM, Robert Raszuk wrote:
> Going by your logic we would have a notion of "incoming IP address" and
> "outgoing IP address" in all routers in the world doing basic non NAT
> routing

I'm not sure I understand what it means to "have a notion ... in all 
routers".  A given router only needs to implement the functionality that 
it needs to provide to those who are going to deploy it.

However, certainly there is a distinction to be made between "incoming" 
and "outgoing" even in the case of "pure" IP.  The incoming IP header of 
a packet is always different than the outgoing IP header of that packet, 
due to the need to modify the TTL and checksum fields.

In addition, as you point out, the incoming source address field may be 
different than the outgoing source address field, due to NAT.  And use 
of the source routing option can result in there being a difference 
between the incoming destination address field and the outgoing 
destination address field.

Another interesting case is tunnel stitching, where the incoming source 
and destination address fields may both be different than the outgoing 
source and destination address fields.  If you want to optimize for 
tunnel stitching, you precompute the rewrite string, and to the 
forwarding plane it looks like an ordinary case of forwarding a packet.

Of course, if your platform doesn't need to perform any of these 
functions, it doesn't have to implement them.  Similarly, if you think 
that the most common operation (or even the only operation) your 
platform will have to perform on an MPLS packet is "don't modify the 
label stack except for the TTL of the top entry", nothing stops you from 
optimizing for that case.

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.