Hi, Authors:
I think other use case, such as 3.2 and 3.3 can also be solved by other means. Following the direction of using different routing instances to transfer such information is not one feasible way. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Uma Chunduri Sent: Tuesday, March 9, 2021 4:48 AM To: lsr@ietf.org Subject: [Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance Dear Authors, Just want to quickly clarify my comment today on this draft. We know there was a significant discussion many years ago when similar work was done during RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo). The usefulness of this is evident with the more recent publication https://datatracker.ietf.org/doc/rfc8202/. I am certainly not in the group and would not question 'why' this is needed in OSPF. However, section 3.1 use cases are difficult to understand and quite frankly either through the reference (ETSI-WP28-MEC) or the cases listed. As long as there is overlay in those networks (with the 3GPP preferred option expanded rapidly for multiple interfaces beyond N9, F1, W1 etc after REL16+) the usefulness of this core network and application info into the underlay and routing layer is limited and even more so for UEs. So please either expand the use case (sec 3.1) to see how this is applicable or leave it out for future scenarios. -- Uma C.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
