Looks fine. One item I would like to see changed (or at least discussed) I have a problem with chapter3 – Para6 – Point 1 :
EXISTING: If T's destination IP address is from the same address family as the computing OSPF instance, then the tunnel must have been signaled based on MPLS TE information propagated in the same OSPF instance. Process the tunnel as per [RFC3630<https://tools.ietf.org/html/rfc3630>] or [RFC5329<https://tools.ietf.org/html/rfc5329>]. PROPOSED: If T's destination IP address is from the same address family as the computing OSPF instance, then process the tunnel as per [RFC3630<https://tools.ietf.org/html/rfc3630>] or [RFC5329<https://tools.ietf.org/html/rfc5329>]. MOTIVATION: I do not understand why to restrict the tunnel to be signaled with only info from same OSPF instance. If there is tunnel available (different instance, or even other routing protocol), it should be able to be used. G/ From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) Sent: Tuesday, October 23, 2018 00:25 To: lsr@ietf.org Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time. https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Thanks, Acee
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
