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

["Acee Lindem (acee)" <[e-mail]>]

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)" <[e-mail]> 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
    >          >
    > 
    > 
    > 
    >