Re: [Status] Status of Spring

Robert Raszuk <robert@raszuk.net> Sat, 12 October 2013 16:30 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16A21E8180 for <status@ietfa.amsl.com>; Sat, 12 Oct 2013 09:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.37
X-Spam-Level:
X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, DIET_1=0.083, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSF7nWKR4UGz for <status@ietfa.amsl.com>; Sat, 12 Oct 2013 09:30:52 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C86FC21E8197 for <status@ietf.org>; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so8201142iec.20 for <status@ietf.org>; Sat, 12 Oct 2013 09:30:48 -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=Oe7rTVqCBYOMNUPbhKe8sX+W1CbY99TF8RAZEFiBEkQ=; b=dm9UKTF9UYDyhZPUHmRSxEtx03oJm8Qk60HPldmVd8QRbPKZ/8q2UQXAbeSjpsSw6L 39S2exRHbKt0SenCLO2VQwFJcDd2DLGyVbpPZ0x+KLOvzc7iG8nRsLXg19ZQy99m0yU1 +G9QBVYqYu90Q9h+T35OXnxMWs9ecQsKztp24BJiQkoTU6jeRp1WF/12G5lAPo/LWisr v0iYFXWHZG0euciUQxMqF4PQFVZ+2xg0e9gseXb4vxADI5TsxPiaknWtAVCccd8BKc0I ARhScPsF8Nz3TU8mHW+mP1YPD3OgxBpsgFz9mM2vxqEEuFlcV2lcRAY8TUACYSJ7sA8F N03g==
MIME-Version: 1.0
X-Received: by 10.50.27.9 with SMTP id p9mr6884216igg.53.1381595448132; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com> <CA+b+ERmj13sz4yi+aQXwGKuu7boOKkz6CbcB9pYXqHV-_FMhSw@mail.gmail.com> <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com> <CA+b+ER=yE=mPi_CgV=8oyiykUvhd2BGVf7S7BZ36M0AF3gy0mA@mail.gmail.com> <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com> <CA+b+ERk3Xpp3mizRhij5EMUsRcXMg4Qfh=6da-3t1S-Anf6_UQ@mail.gmail.com> <20131011110724.GB29384@juniper.net> <CA+b+ER=wEfYP5wdO=SFVd2Qdm2tdzBjbfYXKkvfr2wzadTE09A@mail.gmail.com> <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com> <CA+b+ERm3U28s0_3L-ToOmUg9Z0tfVSr_X=r2w8DXVf2swCe=SQ@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com>
Date: Sat, 12 Oct 2013 18:30:48 +0200
X-Google-Sender-Auth: fQQMI8Z0ki7cpq-36qNmfyZdaFc
Message-ID: <CA+b+ERm6+=nt9UYUb+BV6=Jegqe2MXz2goC4rYTTknv5E=bqiA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Xuxiaohu <xuxiaohu@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:status-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:status@ietf.org>
List-Help: <mailto:status-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:status-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Oct 2013 16:30:52 -0000

Hi Xuxiahou,

> As I had illustrated in a previous email with an example, if you want to
> reduce the MPLS forwarding table size, you could replace the innermost
> LSP towards the final tunnel destination (i.e., the last hop of the explicit
> path) with an IP-based tunnel while still using LSPs to represent the paths
> to the remaining hops of the explicit path. In this way, there is no need to
> create label bindings for those large amount of final tunnel endpoints.


And my observation is that if you already remove inner most LSP and
replace it with IP encapsulation there is no need to add any
subsequent LSPs as well .. just in the case of need for steering or
service chaining add few extension headers.

Why would I run LDP if I IP encapsulation provides me with the
functional alternative and less control plane state ?

All compatible with each other, no need for extra heavy weight
signalling like you would need with RSVP-TE for path engineering.

Cheers,
R.