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

[Michael Barnes <[e-mail]>]

I am fine with it as well.

-Michael

On 04/24/2018 01:56 PM, Anton Smirnov wrote:
>     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
>>          >
>>
>>
>>
>>
> .
>