Hi Ketan,
1. I am not sure I understood the question. Your example says "using the
TE topology from OSPFv2 to compute a tunnel". In that case TE router ID
is an IPv4 address. So no, advertising IPv6 address won't help to
identify the tunnel.
2. my opinion (not discussed with other authors): RFC 3906 is
Informational RFC, so it is not mandatory for implementation to follow.
I think we can insert mention to that RFC somewhere in the Introduction
but wording should be sufficiently weak (like "one possible example of
route computation algorithm...").
---
Anton
On 10/24/18 12:06, Ketan Talaulikar (ketant) wrote:
Hello All,
I support this simple but important extension.
A couple of minor comments on the draft:
1)Sec 3 says
A node that implements X-AF routing SHOULD advertise, in the
corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6
addresses local to the router that can be used by Constrained SPF
(CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise
the IP address listed in the Router Address TLV [RFC3630
<https://tools.ietf.org/html/rfc3630>] [RFC5329
<https://tools.ietf.org/html/rfc5329>]
of the X-AF instance maintaining the MPLS TE database, plus any
additional local addresses advertised by the X-AF OSPF instance in
its Node Local Address sub-TLVs. An implementation MAY advertise
other local X-AF addresses.
Generally speaking, should the IP address (TE router ID in common
terms) which is candidate for inclusion in the Router Address TLV not
be a MUST candidate for X-AF advertisement?
I also have a question about the first statement with the SHOULD in
it. Consider we are using the TE topology from OSPFv2 to compute a
tunnel for use with OSPFv3. Any IPv6 addresses associated with the
OSPFv3 instance on a router would be advertised as a Node attribute
and would not help identify a specific link. So practically, if any
IPv6 addresses (if at all) were to be used for CSPF then it would just
identify the node – in this case, isn’t advertising the IPv6 address
(TE router ID used in Router Address TLV) sufficient?
For practical deployment, it think it would help if this was clarified
that we really need only the TE Router ID Address to go X-AF in
most/general cases and not the others?
2)Isn’t the mapping algorithm in Sec 3 actually going to be used for
IGP short-cut use-case with its reference to the IGP cost of the
tunnel? If so, would a reference to rfc3906 be helpful in this document.
Thanks,
Ketan
*From:*Lsr <lsr-boun...@ietf.org> *On Behalf Of *Acee Lindem (acee)
*Sent:* 23 October 2018 03:55
*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
