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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Apr 2018 03:37:33 +0000

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 <[email-masked]> on behalf of Acee Lindem <[email-masked]>
Date: Thursday, April 19, 2018 at 5:29 PM
To: "Anton Smirnov (asmirnov)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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)" <[email-masked]>
Organization: Cisco Systems
Date: Saturday, April 14, 2018 at 6:48 PM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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-masked]><mailto:[email-masked]> 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
    >

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 24 Apr 2018 22:56:39 +0200

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:
> 
> *From: *Lsr <[email-masked]> on behalf of Acee Lindem <[email-masked]>
> *Date: *Thursday, April 19, 2018 at 5:29 PM
> *To: *"Anton Smirnov (asmirnov)" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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)" <[email-masked]>
> *Organization: *Cisco Systems
> *Date: *Saturday, April 14, 2018 at 6:48 PM
> *To: *Acee Lindem <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: OSPF Routing with Cross-Address Family MPLS Traffic 
> Engineering Tunnels
> 
>     Hi Acee,
> 
> - 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?
> 
>     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.
> 
>     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.
> 
>     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?
> 
> - OSPFv3 computes IPv6 routes. If TE tunnels provide shortcut to 
> destination then OSPFv3 will point route into the tunnel.
> 
> ---
> 
> Anton
> 
>     On 4/6/18, 7:33 AM, "Anton Smirnov (asmirnov)"
>     <[email-masked]><mailto:[email-masked]>wrote:
> 
>              Hi Acee,
>           >  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?
> 
>     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.
> 
>     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
> 
> 
>          > 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
>          >
> 
> 
> 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Apr 2018 21:15:21 +0000

Hi Anton, 

If you could indicate that the IGP shortcut usage of the X-AF tunnels is only one of the usages. I'm afraid subsequent reviewers will get hung up on the reference algorithm when the draft is really about X-AF endpoint advertisement. 

Thanks,
Acee 

On 4/24/18, 4:56 PM, "Anton Smirnov (asmirnov)" <[email-masked]> wrote:

        Hi Acee,

    ---
    Anton

---

From: Michael Barnes <[email-masked]>
Date: Tue, 24 Apr 2018 16:07:30 -0700

I am fine with it as well.

-Michael

On 04/24/2018 01:56 PM, Anton Smirnov wrote:
>> 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:
>>
>> *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.
>>
>> requested a Routing Directorate review and I’m going to start the LSR 
>> WG last call shortly.
>>
>> Thanks,
>> Acee
>>
>> 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.
>>
>>
>>
> .