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

[Rob Shakir <[e-mail]>]

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.