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

Robert Raszuk <robert@raszuk.net> Tue, 28 July 2015 11:11 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 C1B7E1A8953 for <mpls@ietfa.amsl.com>; Tue, 28 Jul 2015 04:11:21 -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 llh4GEkH6ZVG for <mpls@ietfa.amsl.com>; Tue, 28 Jul 2015 04:11:20 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 79FCA1A894E for <mpls@ietf.org>; Tue, 28 Jul 2015 04:11:20 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so174683215wic.0 for <mpls@ietf.org>; Tue, 28 Jul 2015 04:11:19 -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=+lyZtPR25QsDVe4/6RyjzYPSCAl2i9vT0xgTb6IK/Ss=; b=hnzpf2ukmCusy92z0Qcjkv3gV3EueCIW5FCwgL9UZqcfaNuWZyrYlHuwADHMBJ5LoE URk0os8LgycuZ0rAY8PF+bVz8z2wFsNHUMTmPvEPm9bq9+Jlp0+YZm5FWEtYwAYizAk1 2HYB7omSHWaO3yHex7Yi+JrjXh/jNOrriR+YplGdtwUPAlcMfSh6dFNv2Bm5As7cpZjG ozMPcbICZlO52d4EkmEUZE20s19/o59QmehiMpnJWXtsbytEYQ+wC9aM9hk1VxLODzNu gji6BPlpIGMadnIXOsuNngYtN7IDSmG7AwDzgoTtfL4spMgHEDHYGnztEJBpWKQo3gvl iz1A==
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr64314996wjb.133.1438081879247; Tue, 28 Jul 2015 04:11:19 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.194.95.168 with HTTP; Tue, 28 Jul 2015 04:11:18 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Tue, 28 Jul 2015 04:11:18 -0700 (PDT)
In-Reply-To: <55B7617A.90808@cisco.com>
References: <DB3PR03MB0780AE3E11BEA6B29B81FF5B9D810@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F60C0D@MTKMBS61N1.mediatek.inc> <55B64078.7030601@cisco.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F624BE@MTKMBS61N1.mediatek.inc> <55B7617A.90808@cisco.com>
Date: Tue, 28 Jul 2015 13:11:18 +0200
X-Google-Sender-Auth: 0ul6e_kZCL78hu0U97PC00WZeVU
Message-ID: <CA+b+ERn5t9PN9ZmOZKPXazpbKt17OOw0PuJMQW-OvVFxqfuEQQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: stbryant@cisco.com
Content-Type: multipart/alternative; boundary=089e0116000292165d051bed87fd
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/1JN3sa3OHC-dD1yiDrZJ7HfQDnI>
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: Tue, 28 Jul 2015 11:11:21 -0000

Stewart,

That is not quite correct.

I can have context label directing my packets to a completely new label
space on both old and new devices.

Therefor mutually disjoined non aligned label space is not sufficient
reason to enforce swap action on all LSRs.

Besides while you can call it as optimization what is the problem in
defining it ?

Cheers,
R.
On Jul 28, 2015 1:03 PM, "Stewart Bryant" <stbryant@cisco.com> wrote:

> Adding “NO_SWAP” for new/future generation DEVICE does NOT break backward
>> capability.
>>
>>  Andrew
>
> Existing devices should be assumed to have non-aligned label spaces.
> (there is much empirical evidence to support this position)
>
> So if you have a no-swap only device between two existing devices
> you cannot be sure that you can build an LSP.
>
> A backwards compatible device would therefore need to support swap.
>
> Once you support swap then no-swap become an optimization.
>
> - Stewart
>
>
>