Hi Acee,
to refresh the draft I published a new revision with changes we
agreed upon (like dropping 'MPLS' from title) and minor editorial
changes (change group to LSR and the like). I didn't add text to the
backward compatibility section that you found confusing.
Please give me know if answers in my previous email didn't clarify
your questions/concerns.
---
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]> 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
