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

Xuxiaohu <xuxiaohu@huawei.com> Fri, 08 November 2013 01:28 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD011E81BA; Thu, 7 Nov 2013 17:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.459
X-Spam-Level:
X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=-1.990, 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 RbB+1MYSWe9R; Thu, 7 Nov 2013 17:28:52 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2D11E81B9; Thu, 7 Nov 2013 17:28:51 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAA64436; Fri, 08 Nov 2013 01:28:49 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:28:48 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 01:28:47 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 09:28: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//ltYAgACPRrz//3/TAIAAkrMG
Date: Fri, 08 Nov 2013 01:28:40 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>, <527C32B0.5070101@cisco.com>
In-Reply-To: <527C32B0.5070101@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.148.96]
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: [OSPF] 答复: 答复: Inconsistency between OSPF extention and IS-IS extension for segment routing
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 01:28:56 -0000

Hi Peter,

The 'longest-match algorithm' for LIB installation has been proposed by RFC5283.

Best regards,
Xiaohu

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

Xiaohu,

On 11/7/13 16:23 , Xuxiaohu wrote:
>
> Hi Peter,
]
> 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

I don't understand. If you summarize, then only the summary prefix will
be visible in the backbone (and remote areas) and installed in the FIB
on all routers in these areas.

Where would you apply 'longest-match algorithm' when you only see the
single summary? How would you use the SID/label for prefixes that are
covered by the summary?

thanks,
Peter