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

Xuxiaohu <xuxiaohu@huawei.com> Wed, 06 April 2016 15:37 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 395DA12D542; Wed, 6 Apr 2016 08:37:34 -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 v4eHF2aMAY-5; Wed, 6 Apr 2016 08:37:31 -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 1B5F412D528; Wed, 6 Apr 2016 08:37:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLQ92283; Wed, 06 Apr 2016 15:37:28 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 16:37:27 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 23:37:21 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vg==
Date: Wed, 6 Apr 2016 15:37:21 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.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.212.198.226]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57052D39.0008, 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: c66893d3ade0d7a0417cd6f057135152
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9xsNo0faiGnQUBLMUaCXgqEQsTI>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [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 15:37:34 -0000

Hi all,

According to suggestions from SPRING co-chairs, I would clarify the intention of this draft (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-05) as follows.

If I understood the current MPLS-SR specification (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls) correctly, the IGP next-hop for a given /32 or /128 prefix FEC (i.e., node segment prefix) is taken as the next-hop of the received MPLS packet belonging to that FEC. When the IGP next-hop for that FEC is a non-MPLS node, the outgoing label for that FEC is lacked. As a result, the received MPLS packet belonging to that FEC would be dropped BY DEFAULT according to the following specification as quoted from RFC3031:

"3.22. Lack of Outgoing Label
   When a labeled packet is traveling along an LSP, it may occasionally
   happen that it reaches an LSR at which the ILM does not map the
   packet's incoming label into an NHLFE, even though the incoming label
   is itself valid.  This can happen due to transient conditions, or due
   to an error at the LSR which should be the packet's next hop.
   It is tempting in such cases to strip off the label stack and attempt
   to forward the packet further via conventional forwarding, based on
   its network layer header.  However, in general this is not a safe
   procedure:
      -  If the packet has been following an explicitly routed LSP, this
         could result in a loop.
      -  The packet's network header may not contain enough information
         to enable this particular LSR to forward it correctly.
   Unless it can be determined (through some means outside the scope of
   this document) that neither of these situations obtains, the only
   safe procedure is to discard the packet."

In the T-LDP or L-BGP case, the next-hop for the MPLS packet belong to a given prefix FEC is not the IGP next-hop of that FEC anymore. For instance, in the T-LDP case, the next-hop is the T-LDP peer, and in the L-BGP case, the next-hop is the L-BGP peer. As a result, if T-LDP peers or L-BGP peers are not directly connected and are separated by an IP network, the LSP signaled by T-LDP or L-BGP could be transported over that IP network. 

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 former case is straightforward to understand and has been described in the current MPLS-SR draft. the latter case is a bit hard to understand and has not been described in the current MPLS-SR drafts. In fact, the latter case belongs to the "remote label distribution peer" case as defined in RFC3031, see below:

"When two LSRs are IGP neighbors, we will refer to them as "local
      label distribution peers".  When two LSRs may be label distribution
      peers, but are not IGP neighbors, we will refer to them as "remote
      label distribution peers."

In a word, this draft (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-05) describes the remote label distribution peer mode which is useful for incremental deployment purpose.

I would like to hear from SPRING and MPLS WGs whether the remote label distribution peer mode is valid for MPLS-SR and whether we need a draft to describe the remote label distribution peer mode for MPLS-SR.

Best regards,
Xiaohu