Hi Gunter,
we agree with the proposed change and will make it in the next
revision, probably even rephrase this sentence.
---
Anton
On 10/24/18 12:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
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 13^th ,
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
