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

Peter Psenak <ppsenak@cisco.com> Fri, 08 November 2013 00:40 UTC

Return-Path: <ppsenak@cisco.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 41DE921E80BD; Thu, 7 Nov 2013 16:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.952
X-Spam-Level:
X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, 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 nn88tQN+YOHK; Thu, 7 Nov 2013 16:40:01 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB211E823D; Thu, 7 Nov 2013 16:39:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1146; q=dns/txt; s=iport; t=1383871194; x=1385080794; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=B1AAWCTBE7C+BR9r67jbVTWAc+cakpZjaPjTttKVYpk=; b=SWUQDfQnM30bpwpCx4iBDkzmqImSdR11WM4vcY1h+Ay7lJpqD/xdveft 5733qU7dqmGusaaq0ba25AKiqE63kdLUMgB6TIhZkBEdSmw0IxTOAefv2 NJ/Z9bMViUNUG1eR9yh3pVWPOHs0v0qIjUSIcUWITfIcYotNdISs5IrN5 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAHcyfFKrRDoI/2dsb2JhbABagwc4g0e8HIEoFnSCJQEBAQR4ARAJAhgEBRYNAgkDAgECAToLBg0BBwEBh3wOjwibWAiSU4EljjQHgmeBSQOJDTOOTIEvhQ6LTYFogV8b
X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="96846556"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Nov 2013 00:39:15 +0000
Received: from [10.21.114.250] (sjc-vpn2-762.cisco.com [10.21.114.250]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA80dDcj026887; Fri, 8 Nov 2013 00:39:13 GMT
Message-ID: <527C32B0.5070101@cisco.com>
Date: Thu, 07 Nov 2013 16:39:12 -0800
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Xuxiaohu <xuxiaohu@huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>, <527C2606.5060906@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277AB@NKGEML512-MBS.china.huawei.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Cc: "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [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 00:40:06 -0000

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