+1 to Peter. We should not define fragile solutions within the IETF. There are also a multitude of other solutions here already:
1) IGP adjacency with one router in each area (at a minimum - probably two for a robust system) over a tunnel. Deployed in many networks for years. 2) BGP-LS to one router (ditto robustness comment) in each area. 3) streaming telemetry of the LSDB contents via gNMI. All these solutions exist in shipping implementations - please let’s not add to the system complexity of the IGP here. r. On Mon, Jul 23, 2018 at 12:30 Peter Psenak <ppsenak= 40cisco....@dmarc.ietf.org> wrote: > 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....@dmarc.ietf.org] > > 发送时间: 2018年7月23日 18:20 > > 收件人: Aijun Wang; 'Peter Psenak'; cho...@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....@dmarc.ietf.org] > >> 发送时间: 2018年7月23日 16:15 > >> 收件人: Aijun Wang; cho...@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 > > > > . > > > > _______________________________________________ > 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
