On Sep 3, 2014, at 12:55 AM, Chris Bowers wrote:

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


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


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.


> 
> Thanks,
> Chris
> 
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[email protected]] 
> Sent: Tuesday, September 02, 2014 11:39 AM
> To: Chris Bowers
> Cc: [email protected]; [email protected]
> 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 protected]] 
>> Sent: Tuesday, September 02, 2014 10:21 AM
>> To: Chris Bowers
>> Cc: [email protected]; [email protected]
>> 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 protected]
>>> https://www.ietf.org/mailman/listinfo/spring
>> 
> 

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to