Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

Xuxiaohu <xuxiaohu@huawei.com> Wed, 06 April 2016 23:57 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6D412D161; Wed, 6 Apr 2016 16:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 k8uuq9K9hNKY; Wed, 6 Apr 2016 16:57:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D7B12D15B; Wed, 6 Apr 2016 16:57:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLR20989; Wed, 06 Apr 2016 23:57:00 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 00:56:59 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 07:56:56 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Eric C Rosen <erosen@juniper.net>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAC0wMo=
Date: Wed, 6 Apr 2016 23:56:55 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5383EC@NKGEML515-MBX.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net>
In-Reply-To: <57057618.8020604@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.197.116]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5705A24D.0143, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ae67004a65fe6487a6f4468fd7610936
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/ElNTVRx_D0T9GxhmrYw2KfDK9AA>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Apr 2016 23:57:08 -0000

Hi Eric,

Thanks a lot for your comments. Your observation is correct that I'm  positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to
transport packets from one to the other.

One particular use case in mind is the MPLS-SR based service function chaining where the service function path is represented by a stack of labels (see https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring). In other words, the SFC encapsulation header is realized in the form of an MPLS label stack. One of the major requirement for the SFC encapsulation header is transport-independancy. That means the SFC encapsulation header in the form of an MPLS label stack should be able to be transported over IP networks. To meet the above requirement, one MPLS-SR node (e.g., service classifier or SFF) should be able to forward a received MPLS packet to another MPLS-SR node (e.g., SFF) which is indicated by the top label of the received packet via an IP-based tunnel, when the IGP next-hop towards the latter MPLS-SR node is a non-MPLS node.

Best regards,
Xiaohu

________________________________________
发件人: Eric C Rosen [erosen@juniper.net]
发送时间: 2016年4月7日 4:48
收件人: Xuxiaohu; spring@ietf.org
抄送: mpls@ietf.org
主题: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

On 4/6/2016 11:37 AM, Xuxiaohu wrote:
> The situation in MPLS-SR is a little bit complex since the outgoing label for a given /32 or /128 prefix FEC could be learnt either from the IGP next-hop of that FEC or the originator of that FEC due to the IGP flooding property. In the former case, the IGP next-hop for a given FEC is taken as the next-hop of the received MPLS packet belonging to that FEC; in the latter case, the originator of that FEC is taken as the next-hop of the MPLS packet belonging to that FEC ... the latter case belongs to the "remote label distribution peer" case as defined in RFC3031

I don't believe this is correct.  In SR, the fact that label L was
advertised by node N does not imply that a packet with L at the top of
the stack needs to be tunneled to N.  In the typical case, the packet
would just follow the IGP best path, and all the intermediate nodes
would be expected to recognize the label at the top of the stack.  If
the intermediate nodes are expected to recognize the label,  this is not
the "remote label distribution peer case".

You seem to be positing a case where two nodes are in the same IGP
domain, and same SPRING domain, but there is no LSP that can be used to
transport packets from one to the other.   It would be somewhat unusual
to have an IGP domain in which some nodes support MPLS and some don't.
In BIER, we do accommodate this sort of situation, where some of the
nodes in the BIER domain do not support BIER.  But I don't know whether
that sort of scenario needs to be supported for MPLS-SR.  Do you have a
particular use case in mind?