Re: [spring] draft-ietf-spring-srv6-network-programming

Gyan,

If the Locator were guaranteed to be 64 bits, as you suggest, there would be no problem. However, the following text from Section 3.1 suggests otherwise.

"   An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L
   most significant bits and FUNCT (function) is the 128-L least
   significant bits of the SID.  L is called the locator length and is
   flexible.  Each operator is free to use the locator length it
   chooses.  Most often the locator is routable and leads to the node
   which instantiates that SID.  A control-plane protocol might
   represent the locator as B:N where B is the SRv6 SID block (IPv6
   subnet allocated for SRv6 SIDs by the operator) and N is the
   identifier of the parent node."

                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: Gyan Mishra <hayabusagsm@gmail.com> 
Sent: Wednesday, October 9, 2019 7:21 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Fernando Gont <fgont@si6networks.com>; SPRING WG List <spring@ietf.org>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

In-line comments 

Thanks 

Gyan

Sent from my iPhone

> On Oct 3, 2019, at 12:25 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> 
> Fernando,
> 
> Someone should. I think that the expertise to do this is in 6man.
> 
>                                  Ron
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Fernando Gont <fgont@si6networks.com>
> Sent: Wednesday, October 2, 2019 3:11 PM
> To: Ron Bonica <rbonica@juniper.net>; SPRING WG List <spring@ietf.org>
> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - 
> IPv6 Addresses and SIDs
> 
>> On 1/10/19 23:30, Ron Bonica wrote:
>> Authors,
>> 
>>  
>> 
>> The document should include a discussion of the relationship between
>> IPv6 addresses and SIDs. For example:
>> 
>>  
>> 
>>  * From what address space can SIDs be drawn? Link local? Multicast? ULA?
>>  * Can a locator be longer than 64 bits? If so, how can the rest of the
>>    /64 be used?
> 
> I'm not saying that this shouldn't be done or that it is a bad idea, 
> but I'm curious if is anybody looking at this from a higher level?  
> (these seems pretty architectural to me)
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 

[Gyan] The SRv6 SID format is below:

So from an IPv6 data plane forwarding perspective the fixed length 64 bit Locator is copied hop by hop into the destination address of the IPv6 header to the tail end FEC destination egress PE and during failover Ti-LFA kicks in additional EH is inserted {violating RFC 8200} at the PLR NNHOP to the similar to RLFA PQ node.

So with SRV6 native traffic engineering the locator is either the physical IP on ingress interface along each hop or loopback along each hop and so is either a GUA or ULA but not LL or multicast address is what I understand from a technical standpoint.

From everything I have read the SID is fixed at 64 bit length maximum but I guess you can have a smaller then 64 bit locator.

I am working on getting this setup in the lab now so that will really help understand the real world implementations.

SRv6 SID format:

128-bits Segment IDs can be used and allocated for different purposes, for example:
• The first 64 bits can be used to direct traffic to a specific node in the network – the “main body” of the program • The next 32 bits can be used to enforce some actions on the traffic – the “function”part • The remaining 32 bits can be used to pass some additional information – the “argument” part 128-bit SRv6 SID
Locator: routed to the node performing the function Function: any possible function Flexible bit-length selection

> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz8K
> kBJW9qEVHARw$