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

Uma Chunduri <uma.chunduri@ericsson.com> Fri, 08 April 2016 01:28 UTC

Return-Path: <uma.chunduri@ericsson.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 D1C1512D1CF; Thu, 7 Apr 2016 18:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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] 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 Rh_BvNwswAxz; Thu, 7 Apr 2016 18:28:03 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A7812D126; Thu, 7 Apr 2016 18:28:02 -0700 (PDT)
X-AuditID: c618062d-f79216d00000767f-92-570702dbe1cd
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id E8.5A.30335.BD207075; Fri, 8 Apr 2016 03:01:15 +0200 (CEST)
Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 21:28:01 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, 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: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ9/Rn2w
Date: Fri, 8 Apr 2016 01:28:00 +0000
Message-ID: <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRPc2E3u4wcazBhbrNnxgtri1dCWr xfELvxkttp5fxejA4tFy5C2rx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DK6H90iLXglHLF nT8bGRsYryh1MXJySAiYSCy93skKYYtJXLi3nq2LkYtDSOAoo8SdjxOZIJxljBLvZs9lBKli E9CT+Dj1JzuILSKQIzHx0TKgDg4OZgFliVN3ZUDCwgJpEnNmHGOBKEmXuH3/I1iJiICRxJ+N +SBhFgEViRnz74NN5BXwlbi0fT7U3iOMEl9/tYAlOAXCJHpfnmUGsRmBjvt+ag0TiM0sIC5x 68l8JoijBSSW7DnPDGGLSrx8/A/qGSWJOa+vMUPUa0nMa/gN1asoMaX7ITvEYkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSNHaXFBTm66kcEmRmAMHZNg093BeH+65yFGAQ5GJR7eB22s 4UKsiWXFlbmHGCU4mJVEeN+ysIcL8aYkVlalFuXHF5XmpBYfYpTmYFES520M/hcmJJCeWJKa nZpakFoEk2Xi4JRqYLSWy+RarBZ/4/jEVfe5Sj/unp0owrZLJZ0zT3Xu5bBfpd3y++o9l3/w PSYc6Rl82lg73GmDzeU5XqKO73j89cVXsbyabuhyxUnMa+mniwem1JgG3v6m/eijjXKEd8w1 mVJHxtc/l2VsTChg3y6+p0T4s8PBoPVGmnXOQbIPd2+YUP67K3qDpBJLcUaioRZzUXEiAMGm Jc2dAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/8CDuSu_a9RUvA6ZxzhVm2HjXkpo>
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: Fri, 08 Apr 2016 01:28:05 -0000

> It would be somewhat unusual
> to have an IGP domain in which some nodes support MPLS and some don't.

May be true with non-SR and traditional  MPLS. 
But with SR I am working with one customer where MPLS (as SR data plane) is brought into their pure IGP-IP domain.
With static PW labels (inner label)  currently pure soft GRE encap is being used (for transport)  but SR is being planned from EPG to cell site routers eventually. 
Planning slow upgrade for some of the MBH nodes with SR-MPLS data plane.  In this case its quite possible to use (in future) non-shortest path SR label stack.
Thx!
--
Uma C.

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, April 07, 2016 3:40 PM
To: Eric C Rosen; spring@ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

Hi Eric,

________________________________________
发件人: 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

[Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label of L is desired to forward that MPLS packet towards node N via an IP-based tunnel. In this case, the node N is the remote peer for that FEC.

Best regards,
Xiaohu


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?
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls