Re: [Status] Status of Spring

Xuxiaohu <xuxiaohu@huawei.com> Sat, 12 October 2013 10:01 UTC

Return-Path: <xuxiaohu@huawei.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 B4F7C11E8192 for <status@ietfa.amsl.com>; Sat, 12 Oct 2013 03:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.505
X-Spam-Level:
X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 Tf-ZYUN94VD8 for <status@ietfa.amsl.com>; Sat, 12 Oct 2013 03:01:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC9CC11E8144 for <status@ietf.org>; Sat, 12 Oct 2013 03:01:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWS91293; Sat, 12 Oct 2013 10:01:40 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 11:01:08 +0100
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 11:01:39 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Sat, 12 Oct 2013 18:01:29 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxyWW9BewZxauYES7bPxS7YMw45nwT6Gg
Date: Sat, 12 Oct 2013 10:01:28 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B94@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> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B64@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B64@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Hannes Gredler <hannes@juniper.net>, "status@ietf.org" <status@ietf.org>, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
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 10:01:46 -0000

In fact, the idea as mentioned before (i.e., replacing the innermost LSP of a stacked LSP tunnel with an IP-based tunnel) is not only suitable for SPRING, but also useful for the traditional MPLS paradigm in multi-area/level or even multi-domain scenarios.

For example, as stated in section 5.1.6. Inter-Area Routing of the seamless MPLS draft (http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/?include_text=1),

   "This architecture results in carrying all loopbacks of all nodes
   except pure P nodes (AN, AGN, ABR and core PE) in labeled BGP, e.g.
   there will be in the order of 100.000 routes in labeled BGP when
   approaching the stated scalability goal."

with the above idea, there is no need to advertise such a large amount of labeled BGP host routes across area/level boundaries anymore. Instead, it only requires to advertise aggregated BGP routes (w/o label) across area/level boundaries. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2013年10月12日 16:32
> 收件人: Xuxiaohu; Robert Raszuk
> 抄送: Hannes Gredler; status@ietf.org; AshwoodsmithPeter
> 主题: 答复: [Status] Status of Spring
> 
> 
> 
> > -----邮件原件-----
> > 发件人: Xuxiaohu
> > 发送时间: 2013年10月12日 16:26
> > 收件人: 'Robert Raszuk'
> > 抄送: Hannes Gredler; status@ietf.org; AshwoodsmithPeter
> > 主题: re: [Status] Status of Spring
> >
> >
> >
> > > -----邮件原件-----
> > > 发件人: rraszuk@gmail.com [mailto:rraszuk@gmail.com] 代表 Robert
> > Raszuk
> > > 发送时间: 2013年10月12日 15:35
> > > 收件人: Xuxiaohu
> > > 抄送: Hannes Gredler; status@ietf.org; AshwoodsmithPeter
> > > 主题: Re: 答复: [Status] Status of Spring
> > >
> > > LDP has not removed any limitation. If you use MPLS you still need to
> >
> > I meant "...Prefix SHOULD NOT use the label for forwarding unless its routing
> > table contains an entry that exactly matches the FEC Element." by
> "limitation".
> >
> > > send all host FECs in LDP. There is no magic transit nodes are not
> > > aware about your overlay application .. they can not demux on their
> > > own. Label must be specific to the transport endpoint.
> >
> > Exactly. FECs can't be aggregated and therefore the MPLS forwarding table
> size
> > is not reduced.
> >
> > > RFC5283 just reduces IGP and RIB size - not LDP:
> > >
> > >    "Note that LDP re-advertises to its peers the specific FEC element
> > >    FEC1, and not the aggregated prefix found in the IP RIB during the
> > >    longest-match search."
> > >
> > > If you use IP encapsulation you don't need any additional signalling
> > > to send your overlay application between any two end points in the
> > > network yet benefit from natural aggregation of IP subnets at any
> > > point.
> >
> > The concern is whether a list of IPv6 addresses or a list of short IDs is used in a
> > packet to represent an explicit source path. If the former is the case, I agree
> with
> > you. However, it seem that is not the recommended option. On the contrary,
> > the latter is. See the following statement quoted from
> > http://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing:
> >
> > " ...The main differences from the IPv6 source route model are:  The source
> > route is encoded as an ordered list of segments instead of IP addresses. "
> >
> > > Likewise when SR SIDs are MPLS labels they can not be aggregated. When
> > > SR SIDs are IP addresses they can be nicely aggregated for example at
> > > the IGP or AS area boundaries.
> >
> > 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.
> >
> > For example, in the following topology where the metrics of all links are the
> > same, assume A want to send a packet X to Z via a explicit route {C, E}, the
> > packet sent from A would look as: |MPLS label for C|GRE tunnel to E|packet
> X|.
> 
> s/Z/E
> 
> > A-----B-------D-----E
> >      \   /
> >        C
> >
> > Best regards,
> > Xiaohu
> >
> > > r.
> > >
> > > On Sat, Oct 12, 2013 at 5:05 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > > >
> > > >
> > > >> -----邮件原件-----
> > > >> 发件人: status-bounces@ietf.org [mailto:status-bounces@ietf.org] 代表
> > > >> Hannes Gredler
> > > >> 发送时间: 2013年10月11日 22:11
> > > >> 收件人: Robert Raszuk
> > > >> 抄送: status@ietf.org; AshwoodsmithPeter
> > > >> 主题: Re: [Status] Status of Spring
> > > >>
> > > >> On Fri, Oct 11, 2013 at 03:00:02PM +0200, Robert Raszuk wrote:
> > > >> | > please have a look at
> > > >> | >
> > > >>
> > >
> >
> http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page
> > > >> |
> > > >> | [ ... ] Please point me to any
> > > >> | linux distribution which officially supports this. Also please point
> > > >> | me to the official linux kernel which supports mpls kernel project.
> > > >>
> > > >> i am not sure if there is such a thing as an "official linux kernel"
> > > >>   of course there is linus' and his lieutenants git trees - however
> > > >>   every major linux distribution pulls from there and adds a ton
> > > >>   of patches to it. - the linux MPLS extensions are basically
> > > >>   kernel patches plus userspace utilizities - nothing more.
> > > >>   so if you want to get it to work - get your favourite
> > > >>   (linux from scratch) distro and apply the patches ...
> > > >>   i did it with 'gentoo' linux and as far as i can tell it works fine
> > > >>   even with l2vpn services on top of the transport LSPs.
> > > >>     note that there are also pre-cooked debian ISO images with
> > everything
> > > >>     applied if you do not want to compile your kernel by yourself.
> > > >>
> > > >> | > can you point me to the text which says so.
> > > >> | > i could not find such a claim in rfc3031 ?
> > > >> |
> > > >> | Not in rfc3031 but in rfc5036 .. pretty much the only practical
> > > >> | signalling protocol for mpls transport (not an overlay mpls
> > > >> | signalling):
> > > >> |
> > > >> |    "Prefix SHOULD NOT use the label for forwarding unless its routing
> > > >> |     table contains an entry that exactly matches the FEC Element."
> > > >>
> > > >> oh yes, and this is indeed problematic ... and its fixed here:
> > > >> http://www.ietf.org/rfc/rfc5283.txt
> > > >
> > > > Great that LDP has removed that limitation. When using ISIS or OSPF for
> > label
> > > distribution purpose, we should follow the same principle. In this way, the
> > > scalability of IGP would not be impacted by the SPRING architecture.
> > > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > > >> _______________________________________________
> > > >> status mailing list
> > > >> status@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/status