Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane

From: Chris Bowers <[email-masked]>
Date: Tue, 2 Sep 2014 22:55:40 +0000

Stefano,

Thanks.  I have a similar question regarding node-SID index values for different algorithms.  Does each node need to advertise a unique index value for each algorithm?   For example, in a network supporting 3 algorithms, would each node need to be assigned 3 unique index values for IPv4 forwarding?

I was hoping to be able to assign a single unique index value to each node, and then have each node advertise a different label block for each algorithm.  This would achieve the same result as assigning a unique index value for each node for each algorithm, and it would simplify network operations.  The current versions of the ISIS and OSPF SR extensions don't appear to support advertising a different label block for each algorithm, but I wanted to make sure I'm not misreading the drafts.

Thanks,
Chris

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2014 11:39 AM
To: Chris Bowers
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane

On Sep 2, 2014, at 6:17 PM, Chris Bowers wrote:
> Stefano,
> 
> Thanks.  Is there a mechanism to advertise different label blocks for v4 and v6 and have a single unique index value associated with the node?

there's a mechanism that allows you to advertise multiple label blocks and the index is used across all of them (see isis/ospf sr extensions drafts). Not sure if you need to explicitly advertise the af of the label block knowing that a sid corresponds to a prefix which implies its af.

s.

>  This would still result in different label values being used for v4 and v6 packets destined for the same node, but the network operator only has to assign a single unique index value to each node.
> 
> Chris
> 
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
> Sent: Tuesday, September 02, 2014 10:21 AM
> To: Chris Bowers
> Cc: [email-masked]; [email-masked]
> Subject: Re: [spring] carrying IPv6 and IPv4 packets using SPRING/SR with MPLS dataplane
> 
> Hi Chris,
> 
> On Sep 2, 2014, at 5:12 PM, Chris Bowers wrote:
>> Has there been any discussion about how to carry both IPv6 and IPv4 packets with SPRING/SR MPLS labels?  From what I can tell, neither draft-filsfils-spring-segment-routing-04 nor draft-filsfils-spring-segment-routing-mpls-03 addresses this scenario.
> 
> 
> sid's are assigned to ip addresses (e.g. intf addresses). A node having two loopbacks (v4/v6) will have a sid for the ipv4 address and another one for the ipv6.
> 
> Then you compute your spt's or explicit paths based on your af-topology and you pick the right sid's stack.
> 
> 
>> In the context of shortest-path forwarding using Node-SID labels, there would seem to be two main approaches to consider.  One could distinguish between IPv6 and IPv4 packets by using two different Node-SID labels for the same node.
> 
> 
> correct. this is same as above: one sid per address (one for v4 and one for v6).
> 
> s.
> 
> 
>> Or one could use IPv6 and/or IPv4 Explicit Null labels pushed on the bottom of the label stack by the SR ingress router.
>> 
>> Do the authors of these drafts or other working group participants have an opinion on the best way to address this scenario?
>> 
>> Thanks,
>> Chris
>> 
>> 
>> 
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 3 Sep 2014 07:45:03 +0000

> Thanks.  I have a similar question regarding node-SID index values for different algorithms.  Does each node need to advertise a unique index value for each algorithm?   For example, in a network s…

yes.

> I was hoping to be able to assign a single unique index value to each node, and then have each node advertise a different label block for each algorithm.  This would achieve the same result as assi…

that's correct. Note that we don't really have documented a use case for the algorithm field. Yet another way to do multi-topology... in case we don't have enough of them already...

s.