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

[Michael Barnes]

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  on behalf of Acee Lindem 


*Date: *Thursday, April 19, 2018 at 5:29 PM
*To: *"Anton Smirnov (asmirnov)" , 
"draft-ietf-ospf-xaf...@ietf.org" 

*Cc: *"lsr@ietf.org" 
*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)" 
*Organization: *Cisco Systems
*Date: *Saturday, April 14, 2018 at 6:48 PM
*To: *Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 


*Cc: *"lsr@ietf.org" 
*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 Lo

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

[Acee Lindem (acee)]

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)"  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  on behalf of Acee Lindem 

> *Date: *Thursday, April 19, 2018 at 5:29 PM
> *To: *"Anton Smirnov (asmirnov)" , 
    > "draft-ietf-ospf-xaf...@ietf.org" 
    > *Cc: *"lsr@ietf.org" 
> *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)" 
> *Organization: *Cisco Systems
> *Date: *Saturday, April 14, 2018 at 6:48 PM
> *To: *Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 
> 
> *Cc: *"lsr@ietf.org" 
> *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.

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

[Anton Smirnov]

   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  on behalf of Acee Lindem 
*Date: *Thursday, April 19, 2018 at 5:29 PM
*To: *"Anton Smirnov (asmirnov)" , 
"draft-ietf-ospf-xaf...@ietf.org" 

*Cc: *"lsr@ietf.org" 
*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)" 
*Organization: *Cisco Systems
*Date: *Saturday, April 14, 2018 at 6:48 PM
*To: *Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 


*Cc: *"lsr@ietf.org" 
*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. Thu

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

[Acee Lindem (acee)]

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  on behalf of Acee Lindem 
Date: Thursday, April 19, 2018 at 5:29 PM
To: "Anton Smirnov (asmirnov)" , 
"draft-ietf-ospf-xaf...@ietf.org" 
Cc: "lsr@ietf.org" 
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)" 
Organization: Cisco Systems
Date: Saturday, April 14, 2018 at 6:48 PM
To: Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 

Cc: "lsr@ietf.org" 
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 

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

[Anton Smirnov]

   Hi Acee,

> I guess I see the use case described below as only one of the potential
> use cases for the X-AF tunnels.

   Correct. At the very minimum technique is symmetric, i.e. can 
equally be applied to compute OSPFv2/IPv4 routes over TE tunnels with 
IPv6 tailend where TE LSAs were distributed by OSPFv3. But as you noted 
the same technique can be applied to other use cases, i.e. to tunnels 
other than MPLS TE and even use cases other than tunneling.
   The document's text tries to account for these multiple 
applications. This is good for generalization but makes text a bit 
abstract and thus difficult to understand. We tried to mitigate 
abstractness of general description with down-to-earth example of IPv6 
routes over IPv4 TE tunnels that present day reader (or should I already 
say year-2013 reader? things have already changed quite a bit since 
then) should find most practical.



> You can certainly keep this use case but I’d reference RFC
> 3906 (informational reference) and state that there could alternate use
> cases.

   At one point in time authors discussed adding one sentence saying 
that proposed technique can be employed in other use cases, notably 
those requiring mapping of an address from OSPFv2 database to router LSA 
in OSPFv3 LSDB and vice verse. I don't see any similar statement in the 
latest text, we must have dropped it. May be we should reinstall it.


---
Anton


On 04/19/18 23:29, Acee Lindem (acee) wrote:

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)" 
*Organization: *Cisco Systems
*Date: *Saturday, April 14, 2018 at 6:48 PM
*To: *Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 


*Cc: *"lsr@ietf.org" 
*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 

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

[Acee Lindem (acee)]

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)" 
Organization: Cisco Systems
Date: Saturday, April 14, 2018 at 6:48 PM
To: Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" 

Cc: "lsr@ietf.org" 
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)" 
 wrote:

Hi Acee,
my answers below (I didn't v

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

[Anton Smirnov]

   Hi Acee,
   to refresh the draft I published a new revision with changes we 
agreed upon (like dropping 'MPLS' from title) and minor editorial 
changes (change group to LSR and the like). I didn't add text to the 
backward compatibility section that you found confusing.
   Please give me know if answers in my previous email didn't clarify 
your questions/concerns.


---
Anton


On 04/07/18 23:06, Acee Lindem (acee) wrote:

Hi Anton,

On 4/6/18, 7:33 AM, "Anton Smirnov (asmirnov)"  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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anton Smirnov]

   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)"  
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
  

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

[Acee Lindem (acee)]

Hi Anton, 

On 4/6/18, 7:33 AM, "Anton Smirnov (asmirnov)"  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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anton Smirnov]

   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.



>  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?

---
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr