Re: [Lsr] OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels

[Anton Smirnov <[e-mail]>]

    Hi Acee,
    this text looks good to me, if other authors do not object I will 
add it to the Backward Compatibility section.

    Do we have other potential changes to discuss before I refresh the 
draft one more time?

---
Anton


On 04/24/18 05:37, Acee Lindem (acee) wrote:
> Hi Anton
> 
> Since the IGP shortcut use case you reference does, in fact, use the TED 
> populated by an instance of one protocol (OSPFv2 or OSPFv3) in an 
> instance of the other protocol (OSPFv3 or OSPFv2), I don’t think we want 
> to say anything about instances in the backward compatibility section. I 
> think we can reduce the text you provided below to:
> 
>              X-AF only requires the head-end and the tail-end of the 
> advertised TE tunnels to support
> 
>              X-AF advertisement and usage as described herein. 
> Intermediate OSPF Routers on the TE
> 
>              tunnel path need not support X-AF functionality.
> 
> Thanks,
> Acee
> 
> *From: *Lsr <[e-mail]> on behalf of Acee Lindem <[e-mail]>
> *Date: *Thursday, April 19, 2018 at 5:29 PM
> *To: *"Anton Smirnov (asmirnov)" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Lsr] OSPF Routing with Cross-Address Family MPLS Traffic 
> Engineering Tunnels
> 
> 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)" <[e-mail]>
> *Organization: *Cisco Systems
> *Date: *Saturday, April 14, 2018 at 6:48 PM
> *To: *Acee Lindem <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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)"
>     <[e-mail]><mailto:[e-mail]>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
>          >
> 
> 
> 
>