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|.

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