Hi Acee,
> I guess I see the use case described below as only one of the potential
> use cases for the X-AF tunnels.
Correct. At the very minimum technique is symmetric, i.e. can
equally be applied to compute OSPFv2/IPv4 routes over TE tunnels with
IPv6 tailend where TE LSAs were distributed by OSPFv3. But as you noted
the same technique can be applied to other use cases, i.e. to tunnels
other than MPLS TE and even use cases other than tunneling.
The document's text tries to account for these multiple
applications. This is good for generalization but makes text a bit
abstract and thus difficult to understand. We tried to mitigate
abstractness of general description with down-to-earth example of IPv6
routes over IPv4 TE tunnels that present day reader (or should I already
say year-2013 reader? things have already changed quite a bit since
then) should find most practical.
> You can certainly keep this use case but I’d reference RFC
> 3906 (informational reference) and state that there could alternate use
> cases.
At one point in time authors discussed adding one sentence saying
that proposed technique can be employed in other use cases, notably
those requiring mapping of an address from OSPFv2 database to router LSA
in OSPFv3 LSDB and vice verse. I don't see any similar statement in the
latest text, we must have dropped it. May be we should reinstall it.
---
Anton
On 04/19/18 23:29, Acee Lindem (acee) wrote:
Hi Anton,
I guess I see the use case described below as only one of the potential
use cases for the X-AF tunnels. It seems that path computation, either
head-end or PCE, could also use the dual-stack endpoint information.
Note that the OSPF doesn’t establish the LSPs or even advertise the LSPs
themselves– it merely populates the TE Database. I know that you know
this but you want to assure your text doesn’t imply otherwise. Do you
disagree? You can certainly keep this use case but I’d reference RFC
3906 (informational reference) and state that there could alternate use
cases. Perhaps, your fellow author Alvaro (of OSPF TTZ fame) could help
with some generic text preceding the specific IGP Shortcut use case.
Let me see if I can massage the backward compatibility text. I’m
requested a Routing Directorate review and I’m going to start the LSR WG
last call shortly.
Thanks,
Acee
*From: *"Anton Smirnov (asmirnov)" <[email protected]>
*Organization: *Cisco Systems
*Date: *Saturday, April 14, 2018 at 6:48 PM
*To: *Acee Lindem <[email protected]>, "[email protected]"
<[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *Re: OSPF Routing with Cross-Address Family MPLS Traffic
Engineering Tunnels
Hi Acee,
sorry for my slow response.
Before answering questions lets establish 'prerequisites' of the
problem.
- Network is dual stack, OSPFv2 is used to route IPv4, OSPFv3 is used to
route IPv6
- TE LSAs are originated as per [RFC3630] and flooded in OSPFv2
- 'Endpoint' of each MPLS TE tunnel is IPv4 address
- There is a desire to make OSPFv3 to compute IPv6 routes over TE
tunnels - of which OSPFv3 has no topological information
> 3. In the section 3 mapping algorithm, why do you walk the X-AF
> endpoints from all connected areas? Why not just the
area of local
> IP address?
Idea behind this wording is to cater for cases when area
borders are
laid differently in OSPFv2 and OSPFv3. It's even possible that
router is
ABR in OSPFv2 but not OSPFv3. From network design perspective
this, of
course, is a terrible thing to do - but not impossible.
I guess I still don't understand. Are you implying that you are
advertising TE LSAs using both OSPFv2 and OSPFv3 and aggregating the
TED and since the area boundaries may be different, you need to
search all the areas LSP endpoints? I don't think this deployment
model makes sense and I don't think this should be supported.
No, TE LSAs are advertised only in OSPFv2.
Consider information available to OSPFv3 on tunnel headend router.
Endpoint address of TE tunnel is IPv4 address, say 7.7.7.7 (this address
is what tunnel tailend router advertises in OSPFv2 TE LSA in the Router
Address TLV). OSPFv3 needs to find what router in what area corresponds
to router that advertises that TE LSA in OSPFv2.
That is, OSPFv3 has no its own TE information and not even a hint to
which area may belong the tailend router.
> 4. In the backward compatibility section, can you also
discuss the
> requirements for backward compatibility of the
endpoints? Also state
> that the X-AF tunnel will not be recognized unless the
endpoints are
> advertised by the same protocol (OSPFv2 or OSPFv3); or
describe the
> behavior if this is not the intension.
We can add paragraph saying something like:
"In order for XAF computation to work tunnel tailend routers MUST
advertise XAF Node Local Address sub-TLVs in OSPF instance that
will
perform XAF computation. Thus only tunnel endpoints (both
tunnel headend
and tailend routers) and only OSPF protocol instance performing
XAF
routing must implement XAF as described in this document. Other
routers
in the network do not need to implement XAF algorithm or
interpret Node
Local Address sub-TLVs. For example, if network uses TE tunnels
signaled
by OSPFv2 [RFC3630] and intends to use cross-AF route
computation in
OSPFv3 then only OSPFv3 implementation on routers that serve as
tunnel
endpoints in OSPFv2 needs to be compliant with this specification."
Will this text work?
I think this could be a lot clearer if it were written from the
perspective of the head-end router performing the calculation. Also,
you lost me completely with the last sentence. We are uses a single
protocol, OSPFv2 or OSPFv3 to advertise TE LSAs. Since both IPv4 and
IPv6 traffic is tunneled over that LSP, there is no reason to
operate both protocols since traffic will take the path of the X-AF
LSP - correct?
But OSPFv2 does not produce IPv6 routes. Both protocols operate in the
network:
- OSPFv2 computes IPv4 routes and distributes TE database
- OSPFv3 computes IPv6 routes. If TE tunnels provide shortcut to
destination then OSPFv3 will point route into the tunnel.
---
Anton
On 04/07/18 23:06, Acee Lindem (acee) wrote:
Hi Anton,
On 4/6/18, 7:33 AM, "Anton Smirnov (asmirnov)"
<[email protected]><mailto:[email protected]>wrote:
Hi Acee,
my answers below (I didn't vet them with other authors, so
they may
express different opinions).
> 1. Have you considered a shorter name for the RFC? For
example: “OSPF
> Cross Address Family Traffic Engineering Tunnels”?
Your proposed variant drops two pieces: "Routing with" and
"MPLS".
Dropping mention to MPLS is fine with me. Dropping "Routing
with" seems
to me less correct because the draft is about ways to compute
routes and
not about setting up/managing tunnels.
But ultimately I have no strong feelings here and if there
is a
requirement to shorten document's name then that would be a
good candidate.
> 2. Can you change the requirements language text to the RFC
8174
version?
OK, we will publish new document revision when we agreed on
other
points.
> 3. In the section 3 mapping algorithm, why do you walk the X-AF
> endpoints from all connected areas? Why not just the
area of local
> IP address?
Idea behind this wording is to cater for cases when area
borders are
laid differently in OSPFv2 and OSPFv3. It's even possible that
router is
ABR in OSPFv2 but not OSPFv3. From network design perspective
this, of
course, is a terrible thing to do - but not impossible.
I guess I still don't understand. Are you implying that you are
advertising TE LSAs using both OSPFv2 and OSPFv3 and aggregating the
TED and since the area boundaries may be different, you need to
search all the areas LSP endpoints? I don't think this deployment
model makes sense and I don't think this should be supported.
> 4. In the backward compatibility section, can you also
discuss the
> requirements for backward compatibility of the
endpoints? Also state
> that the X-AF tunnel will not be recognized unless the
endpoints are
> advertised by the same protocol (OSPFv2 or OSPFv3); or
describe the
> behavior if this is not the intension.
We can add paragraph saying something like:
"In order for XAF computation to work tunnel tailend routers MUST
advertise XAF Node Local Address sub-TLVs in OSPF instance that
will
perform XAF computation. Thus only tunnel endpoints (both
tunnel headend
and tailend routers) and only OSPF protocol instance performing
XAF
routing must implement XAF as described in this document. Other
routers
in the network do not need to implement XAF algorithm or
interpret Node
Local Address sub-TLVs. For example, if network uses TE tunnels
signaled
by OSPFv2 [RFC3630] and intends to use cross-AF route
computation in
OSPFv3 then only OSPFv3 implementation on routers that serve as
tunnel
endpoints in OSPFv2 needs to be compliant with this specification."
Will this text work?
I think this could be a lot clearer if it were written from the
perspective of the head-end router performing the calculation. Also,
you lost me completely with the last sentence. We are uses a single
protocol, OSPFv2 or OSPFv3 to advertise TE LSAs. Since both IPv4 and
IPv6 traffic is tunneled over that LSP, there is no reason to
operate both protocols since traffic will take the path of the X-AF
LSP - correct?
Thanks,
Acee
---
Anton
On 04/04/18 20:13, Acee Lindem (acee) wrote:
> Hi Anton, Alvaro, and Mike,
>
> In preparation for WG last call, I have a couple comments.
>
> 1. Have you considered a shorter name for the RFC? For
example: “OSPF
> Cross Address Family Traffic Engineering Tunnels”?
> 2. Can you change the requirements language text to the RFC
8174 version?
> 3. In the section 3 mapping algorithm, why do you walk the X-AF
> endpoints from all connected areas? Why not just the area
of local
> IP address?
> 4. In the backward compatibility section, can you also
discuss the
> requirements for backward compatibility of the endpoints?
Also state
> that the X-AF tunnel will not be recognized unless the
endpoints are
> advertised by the same protocol (OSPFv2 or OSPFv3); or
describe the
> behavior if this is not the intension.
>
> Thanks,
>
> Acee
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
