[Isis-wg] 答复: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing

Xuxiaohu <xuxiaohu@huawei.com> Fri, 08 November 2013 00:23 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCCE21E808F; Thu, 7 Nov 2013 16:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.383
X-Spam-Level:
X-Spam-Status: No, score=0.383 tagged_above=-999 required=5 tests=[AWL=-2.066, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji1iTZm6we11; Thu, 7 Nov 2013 16:23:50 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB221E8195; Thu, 7 Nov 2013 16:23:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ81159; Fri, 08 Nov 2013 00:23:48 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:23:05 +0000
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:23:47 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 08:23:40 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Peter Psenak <ppsenak@cisco.com>
Thread-Topic: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
Thread-Index: Ac7cBOuuRGeZzkraQJWpEDg6hpTODv//ltYAgACPRrw=
Date: Fri, 08 Nov 2013 00:23:39 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com>
In-Reply-To: <527C2606.5060906@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.129.171]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: [Isis-wg] 答复: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 00:23:54 -0000

Hi Peter,

________________________________________
发件人: Peter Psenak [ppsenak@cisco.com]
发送时间: 2013年11月8日 7:45
收件人: Xuxiaohu
抄送: ospf@ietf.org; isis@ietf.org
主题: Re: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing

Xiaohu,

please see inline:

On 11/7/13 14:51 , Xuxiaohu wrote:
> Hi co-authors of the above two drafts,
>
> OSPF extension draft proposes to use Extended Prefix Opaque LSA to carry SR-related attributes. Since the Extended Prefix Opaque LSA does not advertise reachability of the prefix, but only its attributes, the prefixes contained within those LSAs for building IP routing table (e.g., Router LSAs) can be aggregated when crossing area boundaries while the Extended Prefix Opaque LSAs containing prefix SIDs can be intactly propagated across area boudaries. The final effect is much similar to the mechanism defined in RFC5283.
>
> In contract, IS-IS extension draft proposes to reuse those Extended IP Reachability TLVs which are used for building IP routing table to carry SR-related attributes. Although this choice has the benefit of propagating less LSAs, it loses the capability of aggregating routes when acrossing level boudaries. Furthermore, it requires the L1/L2 routers much be SR-capable.

if you aggregate on area/L1L2 boundary, SIDs/labels for individual
prefixes that are covered by the aggregate are useless in the area to
which you aggregate - there will be no FIB entries for these individual
prefixes in such area. So if you aggregate, there is no need to
propagate SIDs/labels for aggregated prefixes.

[Xiaohu] "In the multi-area/level
   scenario where route summary between areas/levels is required, the IP
   longest-match algorithm SHOULD be used by SR-capable routers when
   processing label bindings advertised by the mapping server" For more details, please read the Introduction section of http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00

Best regards,
Xiaohu

"

thanks,
Peter

>
> Although these two drafts are proposing extensions to two different IGPs, IMHO, it would better to provide similar capabilities if possible, especially advoid destroying the existing capabilities of these two IGPs,  e.g., inter-area/level route aggregation capability.
>
> To Peter Psenak,
>
> I don't agree with your argrment that the reason that IS-IS extension draft made that choice is because there is no choice for IS-IS. In fact, you can use the signalling mechanism for Label Request which has been proposed in draft-xu-rtgwg-global-label-adv-00. That's to say, you can use separate Extended IP Reachability TLVs other than those for IP reachability advertisement to carry SR-related attibutes. Since the former TLVs are intened for advertising label bindings other than building IP routing table, the Metric field of these TLVs is set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). It's a normal approach for IS-IS. Of course, if SR is just used within a single level, it's good to use the existing approach proposed in the IS-IS extension draft.
>
> Best regards,
> Xiaohu
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>