Not going to repeat all the comments made before, +1

Regards,
Jeff

> On Jul 24, 2018, at 23:08, Tony Przygienda <[email protected]> wrote:
> 
> pretty obvious +1 here 
> 
> --- tony 
> 
>> On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir <[email protected]> wrote:
>> +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 
>>> <[email protected]> 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:[email protected]]
>>> > 发送时间: 2018年7月23日 18:20
>>> > 收件人: Aijun Wang; 'Peter Psenak'; [email protected]
>>> > 抄送: [email protected]; '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:[email protected]]
>>> >> 发送时间: 2018年7月23日 16:15
>>> >> 收件人: Aijun Wang; [email protected]
>>> >> 抄送: [email protected]; '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
>>> >> [email protected]
>>> >> https://www.ietf.org/mailman/listinfo/lsr
>>> >>
>>> >> _______________________________________________
>>> >> Lsr mailing list
>>> >> [email protected]
>>> >> https://www.ietf.org/mailman/listinfo/lsr
>>> >>
>>> > 
>>> > _______________________________________________
>>> > Lsr mailing list
>>> > [email protected]
>>> > https://www.ietf.org/mailman/listinfo/lsr
>>> > 
>>> > .
>>> > 
>>> 
>>> _______________________________________________
>>> Lsr mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/lsr
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to