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