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

["Aijun Wang" <[e-mail]>]

Hi, Rob:

 

If we use BGP-LS to get the underlay topology, we will not consider deployment other methods such as IGP adjacency or LSDB telemetry, although all of them are applicable.

If we deploy BGP-LS adjacency with routers in multi-area to get the full multi-area topology, it will be no different with the traditional IGP adjacency, increase the complexity that BGP-LS solution itself can reduce.

 

On the other hand, if we do not solve such scenario, isn’t BGP-LS one complete solution for underlay IGP topology gathering?

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Rob Shakir [mailto:[e-mail]] 
发送时间: 2018年7月25日 0:22
收件人: Aijun Wang
抄送: Dongjie (Jimmy); [e-mail]; Peter Psenak; Ketan Talaulikar (ketant); [e-mail]; Acee Lindem (acee)
主题: Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

 

 

 

On 23 July 2018 at 23:37, Aijun Wang <[e-mail]> wrote:

 

To Rob: 

 

BGP-LS is one prominent method to get the underlay network topology and has more flexibility to control the topology export as described in RFC 7752 <https://tools.ietf.org/html/rfc7752#section-1> . 

 

Solution 1) that you proposed is possible, but we will not run two different methods to get the topology.

 

What is the other method that you're running alongside an IGP adjacency? This is a single method that just uses the IGP protocol that you have today.

 

Solution 2) is also one possible deployment, but it eliminates the advantage of the BGP-LS, in which it needs several interaction points with the underlay network. and such deployment is not belong to redundancy category as information got from different areaes are different.

 

Yes, the information is different but this is why you have areas within the IGP. Are you implying that your controller cannot merge topologies from different areas? I'd suggest that this is something that is relatively trivial to add into that code, rather than changing the code running on your routers.

 

Solution 3)--Streaming telemetry technology should be used mainly for the monitor of network devices, it requires the PCE controller to contact with every router in the network, is also not the optimal solution when compared with BGP-LS.

 

This is not true. LSDB export via streaming telemetry (for the entire LSDB) is possible in today's running code with IS-IS, and models are written for OSPF's LSDB. The controller just needs to interact with one device per area per the existing discussion. 

 

Assertion that this is not the optimal solution seems more like opinion to me. Some justification would be useful for us to understand why the existing solutions that are shipping aren't suitable. Why should we further complicate protocols that ship for everyone if there is no technical reason to do so?

 

 We can update the current draft to include all possible scenarios that we are not aiming at beginning for integrity consideration. The proposed extension does not add to complexity of IGP. What we discussed here is the complexity of IGP protocol itself.

 

 You're asking for information that is explicitly partitioned (based on the fact that your network is partitioned into areas) to be exported into an area simply to reduce the number of adjacencies between a controller and the network to N (where N is the redundancy of the controller) rather than N*areas -- why is this the right trade-off?

 

r.