Hi, Yingzhen: Thanks for your answers to the previous questions. Detail responses inline[WAJ].
Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Yingzhen Qu Sent: Tuesday, May 25, 2021 5:47 AM To: lsr@ietf.org 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr