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

Peter Psenak <ppsenak@cisco.com> Mon, 23 July 2018 08:14 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 27627130E35 for <lsr@ietfa.amsl.com>; Mon, 23 Jul 2018 01:14:52 -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_HIGH=-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 RupaFX9Eo9Hx for <lsr@ietfa.amsl.com>; Mon, 23 Jul 2018 01:14:50 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87EC130E17 for <lsr@ietf.org>; Mon, 23 Jul 2018 01:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2503; q=dns/txt; s=iport; t=1532333689; x=1533543289; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DpWmXzu7gp4JLYJF/XNaTEslzABR/O3W43dWaMG4+ds=; b=de/ffjoBFkuxpcABfSDt/CgHfJaAAwnuVaenVwB41QuyMFhk3X75OIt1 bdNSsF/o87PDL7QsxiacUdYSGVcrfuv+sBATfKNw9SipyUStMQImwHztU QhJaK+pF8V9iIw+lHORfWG3Y+3cWF1L7Nn6xv64IPEatvJBp+Os3UHUL+ k=;
X-IronPort-AV: E=Sophos;i="5.51,392,1526342400"; d="scan'208";a="146268345"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 08:14:49 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6N8ElAl013362; Mon, 23 Jul 2018 08:14:47 GMT
Message-ID: <5B558E76.3010703@cisco.com>
Date: Mon, 23 Jul 2018 10:14:46 +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, "'Acee Lindem (acee)'" <acee@cisco.com>, "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>
References: <001601d42259$a860fff0$f922ffd0$@org.cn>
In-Reply-To: <001601d42259$a860fff0$f922ffd0$@org.cn>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/silrt2twr3dl6bp1Znx4Pq-uip4>
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 08:14:52 -0000

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-topology-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-ospf-inter-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-ext-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.
>