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

Peter Psenak <ppsenak@cisco.com> Fri, 08 November 2013 21:14 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 C65F221E808D; Fri, 8 Nov 2013 13:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.034
X-Spam-Level:
X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 MCw1v2QewjbL; Fri, 8 Nov 2013 13:14:30 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5021E8087; Fri, 8 Nov 2013 13:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5110; q=dns/txt; s=iport; t=1383945270; x=1385154870; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=I6f3p+a34JcjJqFOpW2N+ClKlSebViT1J6x6MLsWdoM=; b=T5NqKNtxCZ3MjhcT83W5MhMZjNh0cIXfFX2W+LTt/ysEoxBm05hJMZ4Q 4VrNosSw2rAgKqWaCcD2dQWvlO0RIF5VKMzJeb0iASuP8S+WXarb2Pfb9 uEBSpxQ6zatYoBABG0ujD4LN0KFzWJox5NXm8uaIgiWvuPJNsn7ME23qs o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAPRSfVKrRDoG/2dsb2JhbABZgwc4g0e8IoExFnSCJQEBAQMBAQEBLwE7CgEQCQIYBAUWBAkCCQMCAQIBFSULBg0BBQIBAYd3BQ6PAJtYCJI9gSWOQgeCZ4FJA4kPM45NgS+FDotOgWiBXxs
X-IronPort-AV: E=Sophos;i="4.93,662,1378857600"; d="scan'208";a="96982649"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2013 21:14:30 +0000
Received: from [10.21.118.82] ([10.21.118.82]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA8LES79001691; Fri, 8 Nov 2013 21:14:28 GMT
Message-ID: <527D5434.3010201@cisco.com>
Date: Fri, 08 Nov 2013 13:14:28 -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>, <527C32B0.5070101@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082277D4@NKGEML512-MBS.china.huawei.com>, <527D41E3.1050008@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A99@NKGEML512-MBS.china.huawei.com>, <527D4B80.6070308@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AEE@NKGEML512-MBS.china.huawei.com>, <527D5083.6070904@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B32@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B32@NKGEML512-MBS.china.huawei.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
Cc: "ospf@ietf.org" <ospf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [OSPF] [Isis-wg] 答复: 答复: 答复: 答复: 答复: 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 21:14:35 -0000

Xiaohu,

On 11/8/13 13:07 , Xuxiaohu wrote:
> Peter,
> 
> In my understanding, the OSPF EP LSAs containing SID/label bindings just play the role of label distribution protocols. Since LDP can support the longest-matching algorithm for LFIB installation, why OSPF EP LSAs could not support that capability?

because we do not want OSPF EP LSAs to do what you want to use it for.

thanks,
Peter

> 
> BR
> Xiaohu
> 
> ________________________________________
> 发件人: Peter Psenak [ppsenak@cisco.com]
> 发送时间: 2013年11月9日 4:58
> 收件人: Xuxiaohu
> 抄送: ospf@ietf.org; isis-wg@ietf.org
> 主题: Re: 答复: [Isis-wg] 答复:  答复: 答复: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
> 
> Xiaohu,
> 
> I understand what you started this thread with.
> 
> What I'm trying to say is that even if OSPF separates the advertisement
> of prefix and prefix SID/label, you should not be using the SID/label
> advertisement without the actual prefix reachability advertisement.
> 
> thanks,
> Peter
> 
> On 11/8/13 12:50 , Xuxiaohu wrote:
>> Hi Peter,
>>
>> You misunderstood what I have said. On the contrary, the OSPF extension draft looks fine to me. It's the ISIS extension draft that I believed should follow the similar approach defined in the OSPF extension draft.
>>
>> Best regards,
>> Xiaohu
>>
>> ________________________________________
>> 发件人: Peter Psenak [ppsenak@cisco.com]
>> 发送时间: 2013年11月9日 4:37
>> 收件人: Xuxiaohu
>> 抄送: ospf@ietf.org; isis-wg@ietf.org
>> 主题: Re: [Isis-wg] 答复:  答复: 答复: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
>>
>> Xiaohu,
>>
>> OSPF SR draft clearly states that newly defined Extended Prefix Opaque
>> LSAs do not contribute to the prefix reachability. What you are asking
>> for is to negate that and install forwarding entries based on what is in
>> the EP-LSA, without prefix being advertised in any regular LSA. Once you
>> start to do that you will end up with all sorts of problems. I would
>> like to keep the current definition in place.
>>
>>
>> thanks,
>> Peter
>>
>>
>> On 11/8/13 12:04 , Xuxiaohu wrote:
>>> Hi Peter,
>>>
>>> Sure. However, why not borrow the idea of longest-matching algorithm proposed in that RFC to SR?
>>>
>>> BR,
>>> Xiaohu
>>>
>>> ________________________________________
>>> 发件人: isis-wg-bounces@ietf.org [isis-wg-bounces@ietf.org] 代表 Peter Psenak [ppsenak@cisco.com]
>>> 发送时间: 2013年11月9日 3:56
>>> 收件人: Xuxiaohu
>>> 抄送: ospf@ietf.org; isis-wg@ietf.org
>>> 主题: Re: [Isis-wg] 答复: 答复: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
>>>
>>> Xiaohu,
>>>
>>> there is no LDP in the SR network, so RFC5283 is not applicable.
>>>
>>> thanks,
>>> Peter
>>>
>>> On 11/7/13 17:28 , Xuxiaohu wrote:
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> Isis-wg mailing list
>>> Isis-wg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>> _______________________________________________
>>> Isis-wg mailing list
>>> Isis-wg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>
>>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>