[Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01

Xuxiaohu <xuxiaohu@huawei.com> Thu, 12 June 2014 10:10 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id AC2A61B2833; Thu, 12 Jun 2014 03:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eQ3CWKyIRfoJ; Thu, 12 Jun 2014 03:10:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC3E1A0325; Thu, 12 Jun 2014 03:10:11 -0700 (PDT)
Received: from (EHLO lhreml406-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII60348; Thu, 12 Jun 2014 10:10:09 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com ( by lhreml406-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 12 Jun 2014 11:10:08 +0100
Received: from NKGEML512-MBS.china.huawei.com ([]) by nkgeml410-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 18:10:02 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: Comments on draft-ietf-isis-segment-routing-extensions-01
Thread-Index: Ac+GJni8pnqnrJn8Sty9J1EyPVqh3g==
Date: Thu, 12 Jun 2014 10:10:01 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/j268EVdVsFX8loqqeLqjFLJb65g
Cc: OSPF List <ospf@ietf.org>
Subject: [Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2014 10:10:13 -0000

Hi all, 

The following are some comments on draft-ietf-isis-segment-routing-extensions-01 (Note that the former four comments are applicable to draft-psenak-ospf-segment-routing-extensions-05 as well.):

1. Terminology inconsistency issues

The first example is about the semantics of the SID. According to the following description in section 2.1 "...SID/Index/Label: according to the V and L flags, it contains...", the SID would be something other than label and index. However,  in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which case each SID is encoded as a separate Sub-TLV....", here the SID seems to be a generic terminology, which could be index, label or SID. 

The second example is about the length of the SID (here the SID is something other than index and label). In section 2.1, it said "...A variable length SID (e.g.: an IPv6 address SID)...." However, in section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID..." 

2. The uncertain usage of the 32-bit SID

It said in draft-previdi-6man-segment-routing-header-01 that "In Segment Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of the 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID)?

3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV

In IPv6-SR case, since the SID is an IPv6 address, what's the usage of the prefix-SID sub-TLV? It has been said in draft-previdi-6man-segment-routing-header-00 that " When Segment Routing is applied to IPv6, segments are encoded as 128-bit IPv6 addresses.  This implies that, in the IPv6 instantiation of SR, the SID values are in fact the prefixes advertised in the IPv6 control-plane.  Hence there's no need to advertise any additional specific identifier (other than IPv6 prefix) for the purpose of SR. This simplifies the introduction of IPv6 Segment Routing in existing protocols (i.e.: IS-IS, OSPF and BGP). "
I noticed that the above statement has been disappeared in the -01 version. Did that mean that the co-authors of that draft have changed their minds significantly?

4. Suggestion on the algorithm field in the prefix-SID sub-TLV

It seems that using various algorithms in the best path computation could also be applicable to some cases other than SR. For instance, use different algorithms for different topologies [rfc5120]. Therefore, it seems better to decouple the best path computation algorithm advertisement from the SR-specific advertisement. In this way, the algorithm is just coupled with the topology while the labels advertised through the prefix-sid sub-TLVs could be used to determine to which topology the received SR-MPLS packet belongs to. This behavior is much similar to the LDP and the LDP-MT. In other words, the SR-specific IGP extension just plays the role of label distribution protocol which shouldn't have any impact on the path computation behavior. 

5. The lack of MT-ID field in the SID/Label Binding TLV

I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stefano had agreed to that suggestion. But it seems that the MT-ID field has not been added yet.

6. Suggestion on SR-Capabilities Sub-TLV
The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability; 2) range of SID/Label values. It seems better to advertise these two capabilities via two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range sub-TLV. In the way, the role of SID/Label Range sub-tlv is consistent with the counterpart in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better to keep the ISIS and OSPF extensions for the same function as consistent as possible. 

Best regards,