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

Robert Raszuk <robert@raszuk.net> Thu, 23 July 2015 21:31 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91C1A914E for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-xJoB5k3S3g for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:31:52 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 922811ACE18 for <mpls@ietf.org>; Thu, 23 Jul 2015 14:31:52 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so2392274wib.1 for <mpls@ietf.org>; Thu, 23 Jul 2015 14:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5I0h7eiBSoinqiqmWLj1KXbs6RaK4kksmA1fXM+/qaM=; b=Su7jsqxsGYAUP2CMonhxW+mJj3OdtSogvi231wWiZ70sNGdJZBYg3GpYm4yJ3RK6m8 2rGJMi1oaN/iiaIY7MPxAViSrlDz9sFuKg+ruO0tph0b/jqcZwyEXIl2TJZBUlM8kdb7 EuHrGnlqLE6xh3gFSSfR7k1ewMTwjCALk1ey8JV4MrkFczTta0TS9uY5iuY4t6SgNkk8 Auw3gnrj3anshDw3PY8BuwQOBQcJ7rZ1yAw9XOR8NpqaURZJhQ4et8uEIhcuKO26VrH6 /AEA3P8E+LipLgq7oKgjMDBlaNO6vGUM7ZuVgKgxYpM/zRLs0aTNGZEzlo+VkR01qqqZ qmyQ==
MIME-Version: 1.0
X-Received: by 10.180.186.35 with SMTP id fh3mr534182wic.7.1437687111420; Thu, 23 Jul 2015 14:31:51 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 14:31:51 -0700 (PDT)
In-Reply-To: <55B15C59.5040105@juniper.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>
Date: Thu, 23 Jul 2015 23:31:51 +0200
X-Google-Sender-Auth: _RHtluA0Hx9FAgRLt-MJH4pKIWY
Message-ID: <CA+b+ERnWSg-BoxhntMmSXfBfj0mWhscuZ1VUdUkC0k0xDLd4Tw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Eric C Rosen <erosen@juniper.net>
Content-Type: multipart/alternative; boundary=001a11c261209310f8051b919d30
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/lWBkGIzPw2iCI2Xub4iYiPvYCAg>
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: Thu, 23 Jul 2015 21:31:54 -0000

Eric,

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.

While packets still arrive and depart they do not change label value hence
it makes rather limited sense to divide the label they carry into "incoming
label" and "outgoing label". Wouldn't you agree ?

Cheers,
R.


On Thu, Jul 23, 2015 at 11:27 PM, Eric C Rosen <erosen@juniper.net> wrote:

> You use term "incoming label" and "outgoing label" ... well in the
>> new architectures there is no such things.
>>
>
> The incoming label is the label on the packet when it arrives, and the
> outgoing label is the label on the packet when it departs.  If a packet
> arrives with a label and leaves with a label, it has an incoming label and
> an outgoing label.  I believe that even in the "new architectures",
> packets still arrive and depart.
>
>  So to support legacy hardware new control plane has to make up from
>> single label now two (identical) labels to pass it to data plane. Now
>> also data plane must be smart to check that and program its state
>> per your suggestion.
>>
>
> I don't really understand what you are saying here.  The control plane
> determines the rewrite string and causes it to be programmed into the
> data plane.  There are many ways to implement this interaction.
>
> Are you worried about the following:
>
>  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 ?
>>
>
> I don't understand this point either.  RFC 3031 does not specify an API,
> so it doesn't make any sense to ask whether a particular API is or is not
> compliant with it.
>
>
>
>
>
>