Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Peter Psenak <ppsenak@cisco.com> Mon, 23 July 2018 11:30 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B3130E6F for <lsr@ietfa.amsl.com>; Mon, 23 Jul 2018 04:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRfjhPkiH2Lh for <lsr@ietfa.amsl.com>; Mon, 23 Jul 2018 04:30:05 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB0B130E5D for <lsr@ietf.org>; Mon, 23 Jul 2018 04:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6034; q=dns/txt; s=iport; t=1532345405; x=1533555005; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5HFdgusS4qaBvIdpcNNCQt7615bhVmH8smtPwJBP9Ak=; b=bqd9NsZ7BHyGl5XJE9C9942DW8wddH3TiQuAweBj+HhawkCbZbD7kpET Dpiocb3Pflxac6UgjBWyhe4idq3GCES2ArEYC2+h3RmuCrvP34HNlg3Pb I9yvnwkymU/zZqKZy5C6c4R8XmhnqyHny3+qzGzyRIvEH9KhLh+baQoKF g=;
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400"; d="scan'208";a="146952763"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 11:30:04 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id w6NBU0HN032524; Mon, 23 Jul 2018 11:30:01 GMT
Message-ID: <5B55BC38.3050605@cisco.com>
Date: Mon, 23 Jul 2018 13:30:00 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Aijun Wang <wangaijun@tsinghua.org.cn>, chopps@chopps.org
CC: lsr@ietf.org, "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, "'Acee Lindem (acee)'" <acee@cisco.com>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>
References: <001601d42259$a860fff0$f922ffd0$@org.cn> <5B558E76.3010703@cisco.com> <003201d42265$cd011af0$670350d0$@org.cn> <5B55ABB5.60806@cisco.com> <003f01d42275$5ec00eb0$1c402c10$@org.cn>
In-Reply-To: <003f01d42275$5ec00eb0$1c402c10$@org.cn>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/31rlSrSduEOElBWl8HzRGYviwX0>
Subject: Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2018 11:30:07 -0000

Hi Aijun,

On 23/07/18 13:07 , Aijun Wang wrote:
> Hi, Peter:
> 
> For routers that connected by LAN, the router will establish adjacent
> neighbor with DR, but not only DR advertises the connected prefixes. 

only the Network LSA includes the network mask, other routers would
include the interface address only.


> DR and
> DRother will all advertise type 1 and type 2 LSA with each other, then the
> process and proposal described in this draft will still work.
> We seldom use the ip unnumbered features in our network, can we ignore it
> then? Or other persons has some idea on such situation?

the fact that you do not use unnumbered is not really relevant. IETF
defines solutions that MUST work for all possible scenarios, not only
for a specific one.

> Anycast prefixes are often /32 long, this can be easily filtered by SDN
> controller because the link prefixes between two routers will be no larger
> than /32 for IPv4 network.

protocol allows to advertise the same prefix with an arbitrary mask from
multiple routers without these routers being directly connected. Your
proposal is based on the assumptions that are incorrect.

thanks,
Peter

> 
> Best Regards.
> 
> Aijun Wang
> Network R&D and Operation Support Department
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
> 
> -----邮件原件-----
> 发件人: Peter Psenak [mailto:ppsenak=40cisco.com@dmarc.ietf.org]
> 发送时间: 2018年7月23日 18:20
> 收件人: Aijun Wang; 'Peter Psenak'; chopps@chopps.org
> 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
> 'Dongjie (Jimmy)'
> 主题: Re: [Lsr] 答复: Regarding OSPF extension for inter-area topology
> retrieval
> 
> Hi Aijun,
> 
> On 23/07/18 11:16 , Aijun Wang wrote:
>> Hi, Peter:
>>
>> Actually, I consider mainly the point-to-point connection and the
>> numbered interface, which are normal in our network.
>> For the two situations that you mentioned, I will investigation the
>> possible solutions and feedback you later.
>>
>> For the point-to-point and numbered interface, do you have other
>> questions then?
> 
> the fact that two routers announce the same subnet, does not mean they are
> connected together by p2p link. Anycast prefix is an example.
> 
> The idea you are proposing simply does not work.
> 
> thanks,
> Peter
> 
> 
>>
>> Best Regards.
>>
>> Aijun Wang
>> Network R&D and Operation Support Department China Telecom Corporation
>> Limited Beijing Research Institute,Beijing, China.
>>
>> -----邮件原件-----
>> 发件人: Peter Psenak [mailto:ppsenak=40cisco.com@dmarc.ietf.org]
>> 发送时间: 2018年7月23日 16:15
>> 收件人: Aijun Wang; chopps@chopps.org
>> 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
>> 'Dongjie (Jimmy)'
>> 主题: Re: [Lsr] Regarding OSPF extension for inter-area topology
>> retrieval
>>
>> Hi Aijun,
>>
>> you are trying to reconstruct the topology of the remote area based on
>> the fact that two routers are connected to the same subnet. It does
>> not work
>> because:
>>
>> 1. connections between routers can be unnumbered 2. routers can be
>> connected via LAN, in which case only DR announces the prefix.
>>
>> In summary, what you propose does not work.
>>
>> thanks,
>> Peter
>>
>>
>>
>> On 23/07/18 09:49 , Aijun Wang wrote:
>>> (Sorry for my previous mail sent wrongly to the IDR mail list, please
>>> reply on this thread within the LSR wg)
>>>
>>> Hi, Peter:
>>>
>>> I am Aijun Wang from China Telecom, the author of draft about “OSPF
>>> extension for inter-area topology retrieval”
>>> <https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topo
>>> l ogy-ext/>, which is presented by Mr.Jie Dong during the IETF102
>>> meeting.
>>>
>>> Thanks for your comments on the presentation material
>>>
>> <https://datatracker.ietf.org/meeting/102/materials/slides-102-lsr-osp
>> f-inte
>> r-area-topology-retrieval-00>.
>>>
>>> Below are my explanation that regarding to the question about “how it
>>> retrievals the inter-area topology based on the extension information”:
>>>
>>> Let’s see the graph that illustrates in Fig.1 at section 3
>>> <https://tools.ietf.org/html/draft-wang-lsr-ospf-inter-area-topology-
>>> e xt-00#section-3> of the draft(I copy it also below for your
>>> conveniences ):
>>>
>>> Assuming we want to rebuild the connection between router S1 and
>>> router
>>> S2 that locates in area 1:
>>>
>>> 1)Normally, router S1 will advertise prefix N1 within its router LSA
>>>
>>> 2)When this router LSA reaches the ABR router R1, it will convert it
>>> into summary LSA, add the “Source Router Information”, which is
>>> router id of S1 in this example, as proposed in this draft.
>>>
>>> 3)R1 then floods this extension summary LSA to R0, which is running
>>> BGP-LS protocol with IP SDN Controller. The controller then knows the
>>> prefixes of N1 is from S1.
>>>
>>> 4)Router S2 will do the similar process, and the controller will also
>>> knows the prefixes N1 is also from S2
>>>
>>> 5)Then it can reconstruct the connection between S1 and S2, which
>>> prefix is N1. The topology within Area 1 can then be recovered
>> accordingly.
>>>
>>> Does the above explanation can answer your question. if so, I can add
>>> it into the context of this draft in updated version.
>>>
>>> Best Regards.
>>>
>>> Aijun Wang
>>>
>>> Network R&D and Operation Support Department
>>>
>>> China Telecom Corporation Limited Beijing Research Institute,Beijing,
>> China.
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> .
>