Re: [Lsr] Q&A for OSPF Transport Instance

[Aijun Wang <[e-mail]>]

Hi, Yingzhen:

Thanks for your answers to the previous questions.
Detail responses inline[WAJ].


Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [e-mail] <[e-mail]> On Behalf Of Yingzhen Qu
Sent: Tuesday, May 25, 2021 5:47 AM
To: [e-mail]
Subject: [Lsr] Q&A for OSPF Transport Instance

Hi,

On behalf of co-authors, thanks for the support of WG adoption of this draft.

There were some questions asked, and we’ve compiled them together into this Q&A. Comments and questions are welcome.

Thanks,
Yingzhen


Q: In section 4.3 of this draft, it says: 
   "The OSPF transport instance is not dependent on any other OSPF
   instance.  It does, however, have much of the same as topology
   information must be advertised to satisfy the "condition of
   reachability".  
   Then, this transport instance should also advertise the topology
   information. Right?
   But in section 4.5, the advertisement of inter-area information is
   omitted(Summary-LSA for OSPFv2/inter-area-prefix-LSA for OSPFv3). 
   So, how to transfer the non-routing information across different areas?
   Using the remote OSPF neighbor?

A: OSPF transport instance is not dependent on any other OSPF instance. 
   It’s possible that you run OSPF transport instance without regular OSPF
   instance.
   The topology information advertised by OSPF transport instance is to 
   satisfy the "condition of reachability", not for routing table/RIB update.
   We'll clarify in OSPFv2 this will include the type-4 summaries related to the
   transport instance topology. 
 [WAJ] Should be Type-3 summaries?


Q: The reason that we use the IGP to transfer the non-routing information is
   that the IGP assures the reachability/dissemination of such information.
   Using independent transport instance, the operator need again the design and
   deployment of the distributed topology. And most important, the correlation
   between the routing information and non-routing information is not solved or
   covered within the current draft, which is the merit of other solutions.
   There should be solutions/considerations to the possible problem as that
   described in
   https://datatracker.ietf.org/doc/html/draft-bowers-lsr-isis-gen-info-clarifi
   cations-00 for IS-IS.

A: The topology of OSPF transport instance may or may not be the same as
   the regular OSPF instance, and it's up to the applications that uses OSPF
   transport instance. The support of sparse topology and remote neighbor
   makes it possible for only some routers in the network get the application
   info.
   It is expected the applications in the transport instance will advertise
   non-routing information and, hence, there will be no requirement for
   correlation between route routing and non-routing instance. 
[WAJ] Transport Instance can certainly be used to advertise non-routing information. But the most usage of these non-routing information will be coupled with routing information, for example the use cases you mentioned in section 3.1 and section 3.2.
My understanding is that "Transport Instance" does not solve the ultimate requirements of flooding application information via IGP protocol. In most of scenarios, nearly every node within the IGP nodes should know these non-routing information.


Q: Section 4.7 described the "Non-Routing Sparse Topologies". It requires
   again the careful design and deployment. Is it more straightforward to let
   the IGP routers relay such information and only the necessary nodes to
   store/utilize it? 

A: As mentioned above, sparse topologies make it possible for only routers
   interested in certain applications get involved, and this doesn't impact 
   other routes and routing calculations in regular OSPF instance.
   I don't understand your suggestion of only necessary nodes to store/utilize
   it. This seems not consistent with the idea of link state protocol.
[WAJ] My intension is that the information is relayed via the IGP protocol, but such information does not participate in the SPF process, and only be consumed in necessary nodes.


Q: Add a section on how to advertise information in a transport instance if 
   an application requires, per-link resource information to be advertised in 
   transport instance.

A: This is dependent on the application and while it may be better for some
   applications to advertise separate LSAs per link, for others, it may make
   sense to have a lists of interfaces in a single LSA. 


Q: Some applications may require to co-relate the information in transport instance
   to a specific routing-instance. This requirement to be addressed.

A: This should be addressed by the application draft when using OSPF transport 
   instance. Again, it is expected that routing information will be in the routing
   instance. 


Q: There may be cases when application information gets associated with 
   prefixes rather than nodes. We should allow advertisement of Extended  
   Prefix-LSA and E-Intra-area-Prefix-LSA/E-Inter-Area-Prefix-LSA Advertisements 
   inside transport instance.

A: While an application could define prefix-level information with semantics identical
   to these LSAs, it would not use these LSAs. There are for routing information. 


Q: It seems like we could reuse RI-LSA and originate RI-LSA in transport 
   instance with application-ID TLV. What is the Need to define yet another 
   opaque LSA?

A:  so we have a clear cut of application data, and hopefully this can
    simplify implementations.


_______________________________________________
Lsr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr