Subject: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Thu, 9 Feb 2017 16:02:19 +0000

Dear Authors,

I am requesting your clarification regarding usage of Adj-SID in SRH header.

As per draft, the segment list  is the list of 128 bit IPv6 address.

Whether it means it is global ipv6 address or can be link local address also.

As per "OSPFv3 Extensions for Segment Routing" draft, the Adj-SID can be link local address.

In section 7.1,

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |               Type            |              Length           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Flags         |     Weight    |             Reserved          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                   SID/Label/Index (variable)                  |

   +---------------------------------------------------------------+

Examples:

            A 32 bit global index defining the offset in the SID/Label

            space advertised by this router - in this case the V and L

            flags MUST NOT be set.

            A 24 bit local label where the 20 rightmost bits are used

            for encoding the label value - in this case the V and L

            flags MUST be set.

            16 octet IPv6 address - in this case the V-flag MUST be set.

            The L-flag MUST be set for link-local IPv6 address and MUST

            NOT be set for IPv6 global unicast address.

If Link local address is Link local, how we can use this address in SRH header,

since IPv6 destination address should not be link local address as per IPv6 protocol.

If Adj-Sid is global ipv6 address, means we need to consider "global ipv6 interface address" of the neighbor on the link?

Regards,

Veerendranath

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 9 Feb 2017 17:10:34 +0000

Hi,

the first version of the draft (draft-previdi-6man-segment-routing-header) had a description of Node-SID and Adj-SID. Later, in order to simplify the document, we removed the descriptions and focused the document into the SRH format.

I think it will be helpful to re-introduce a section on the two main SID types (Node, Adjacency). I’m working on an update for the next version.

Thanks.
s.

> On Feb 9, 2017, at 5:02 PM, Veerendranatha Reddy Vallem <[email-masked]> wrote:
> 
> Dear Authors,
> 
> I am requesting your clarification regarding usage of Adj-SID in SRH header

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Feb 2017 06:26:02 +1100

On 10 Feb. 2017 03:02, "Veerendranatha Reddy Vallem" <
[email-masked]> wrote:

Dear Authors,

As per “OSPFv3 Extensions for Segment Routing” draft, the Adj-SID can
be link local address.

In section 7.1,

    0                   1                   2                   3

   |               Type            |              Length           |

Examples:

            flags MUST NOT be set.

            flags MUST be set.

            *The L-flag MUST be set for link-local IPv6 address* and MUST

since IPv6 destination address should not be link local address as per
IPv6 protocol.

I'd be curious where you might have got that idea from.

LL addresses are perfectly fine as destination addresses, including for
application traffic. They're even preferred over global and ULA addresses
by default when there is a choice from a set.

Many of the advantages of LLs for end-user applications would also apply to
network applications such as SR.

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Regards,
Mark.

If Adj-Sid is global ipv6 address, means we need to consider “global
ipv6 interface address” of the neighbor on the link?

Regards,

Veerendranath

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Feb 2017 11:48:45 +1300

Mark,
> [email-masked]> wrote:
...
> by default when there is a choice from a set.

Right, but if an SR header is travelling off-link, which I think must often
be the case, it would be doubleplus ungood to include a LL address, which is
meaningless off-link. So probably using a LL address in SRH needs to be
strictly limited.

   Brian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Feb 2017 23:41:12 +0000

>meaningless off-link. So probably using a LL address in SRH needs to be

Agreed - even though the the link-local address is associated with the
OSPFv3 router¹s adjacency, in the IPv6 SR header there is no indication of
outgoing interface so the IPv6 packet cannot be forwarded unambiguously.
Note that we have a similar restriction for OSPFv3 AS-External-LSA and
NSSA-LSA forwarding address. From RFC 5340:

   Forwarding address
      A fully qualified IPv6 address (128 bits).  Included in the LSA if
      and only if bit F has been set.  If included, data traffic for the
      advertised destination will be forwarded to this address.  It MUST
      NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
      IPv6 Link-Local Address (Prefix FE80/10).  While OSPFv3 routes are
      normally installed with link-local addresses, an OSPFv3
      implementation advertising a forwarding address MUST advertise a
      global IPv6 address.  This global IPv6 address may be the next-hop
      gateway for an external prefix or may be obtained through some
      other method (e.g., configuration).

The OSPFv3 Segment Routing Extensions draft will be updated to correct
this. 

Thanks,
Acee

>> If Adj-Sid is global ipv6 address, means we need to consider ³global
>> ipv6 interface address² of the neighbor on the link?
>> 
>> 
>> 
>> Regards,
>> 
>> Veerendranath
>> 
>> 
>> 
>> 
>> 
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Fri, 10 Feb 2017 06:37:48 +0000

Dear Previdi,
Thanks for your reply. 

As per first version of draft, Adj-SID is also  IPv6 prefix. 

4.2.2.  Adjacency-SID

   The Adjacency-SID identifies a given interface.  In the SR
   architecture a node may advertise one or more Adj-SIDs allocated to a
   given interface so to force the forwarding of the packet (when
   received with that particular Adj-SID) into the interface, regardless
   the routing entry for the packet destination.  The same is defined
   for SR-IPv6: a node may advertise a given IPv6 prefix which is
   associated to the SR semantic of "send out the packet to the
   interface this prefix is allocated to".  Here also, the SID is in
   fact the IPv6 prefix.

As per my understanding  "segment list in SRH is global IPv6 prefixes, If we need to include Adj SID to segment list then Adj-SID is also global IPv6 prefix". 
Please correct me if my understanding is wrong.

Thanks and Regards,
Veerendranath

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: 09 February 2017 22:41
To: Veerendranatha Reddy Vallem <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

Hi,

Thanks.
s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 10 Feb 2017 09:30:52 +0000

the use of ll addresses in ospfv3 draft is a bug and should be fixed.

s.

> On Feb 10, 2017, at 12:41 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 10 Feb 2017 09:31:51 +0000

Hi Veerendranath,

yes, an SR-IPv6 SID is a 128-bit IPv6 addresses. 

The semantic associated to the SID is given by the control plane. We have already documented the signaling of the SIDs in ISIS, OSPF and BGP. Currently we have defined Node-SIDs (representing a node) and Adjacency-SIDs (instruction to forward out to the interface the SID is allocated to).

In the IPv6 dataplane a SID being an IPv6 address, it makes the SID a global IPv6 address (even in the case of Adj-SIDs). This of course is orthogonal to the control plane that may or may not advertise such address.

I.e., you may have an Adj-SID as a global IPv6 address that it is not advertised by any routing protocol in the network (which implies of course that the packet will have to first reach the node using a node-SID).

The use of LL addresses as SID has not been contemplated for the simple reason that a router may well allocated the same address to all links so it is not a reliable mechanism for forwarding. This will be fixed in the next revision of the ospfv3 draft (isis draft is ok).

s.

> On Feb 10, 2017, at 7:37 AM, Veerendranatha Reddy Vallem <[email-masked]> wrote:
> 
> Dear Previdi,
> Thanks for your reply. 
>

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Fri, 10 Feb 2017 11:49:21 +0000

Dear Previdi,
I got it. Thanks for the detailed clarification.

Regards,
Veerendranath

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: 10 February 2017 15:02
To: Veerendranatha Reddy Vallem <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

Hi Veerendranath,

s.

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Fri, 10 Feb 2017 15:18:30 +0000

Dear Previdi,
SRH may carry Adj Segment and Special segments (128 IPv6 prefixes)  along with Node Segments.

Ex: Consider below Topology

                        / B ------ C------- D\                                                                                                   
                      /        Fadj| |                 \                                                                                                
 X --------A                   | |                 H----- Y                                                                                       
                   \                   | |              /                                                                                               
                     \   E ----  F ----- G  /                                                                                                   

  At Node X         		At Node A,                            		At node C,     while forwarding to F (C need to decrement segments to twice, one for Fadj and other for F)                                                                                          
 IPv6 Hdr                              Ipv6 Hdr                                 		 IPv6 Hdr
 DA= Y SA=X                      DA= C SA=X                             		DA= F SA=X                                                                                          
          		             SRHdr (segment left 4)        		SRHdr (segment left 2)                                                                              
         		            Y,H,F,Fadj,C                            	                Y,H,F,Fadj,C                                                                                        
                                                                                                                                       
While processing this type of SRH, I feel existing algorithm may be required to modify to add recursive look up to process Adj Segment/Special segment as below. (Based on above example)

Existing algorithm: (As per section 4.3), 

   1.   IF DA = myself (segment endpoint)
   2.      IF Segments Left > 0 THEN
              decrement Segments Left
              update DA with Segment List[Segments Left]
   3.      ELSE continue IPv6 processing of the packet
                End of processing.
   4.   Forward the packet out

Proposed Modification:

    1.   IF DA = myself (segment endpoint)
   2.      IF   Segments Left > 0  THEN
              decrement Segments Left
               do
               IF Segment List[Segments Left]= Adj-Segment/Special Segment originated by myself
                     Trigger the action as per Segment (Ex: if it is Adj Segment, identify interface to forward, if segment is for the service,  trigger for service)
                     Decrement Segments Left
               ELSE 
                      Update DA with Segment List[Segments Left]
                       break;
             while (Segments Left > 0)    
             
   3.      ELSE continue IPv6 processing of the packet
                End of processing.
   4.   Forward the packet out

If SRH is having combination of Node and Adj SID then recursive look up to be 2 times maximum at each IPv6 SR supported nodes 
If Service Segments are added to SRH, then may be multiple recursive look ups, since it may require to handle multiple services by same node.

Please check and let me know your opinion.

Thanks & Regards,
Veerendranath

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: 10 February 2017 15:02
To: Veerendranatha Reddy Vallem <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

Hi Veerendranath,

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 10 Feb 2017 15:25:44 +0000

you are right. The algorithm needs to be different for the adj-sid. It is part of the changes I’m working at for the next revision of the draft.

Typically, the “action” in the algorithm (for the adj-sid) consists of a forwarding instruction out to the interface the adj-sid is allocated to.

s.

> On Feb 10, 2017, at 4:18 PM, Veerendranatha Reddy Vallem <[email-masked]> wrote:
> 
> Dear Previdi,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2017 09:02:52 +1300

On 10/02/2017 22:31, Stefano Previdi (sprevidi) wrote:
...
> In the IPv6 dataplane a SID being an IPv6 address, it makes the SID a global IPv6 address (even in the case of Adj-SIDs). This of course is orthogonal to the control plane that may or may not adver…

By the way, be careful with the phrase "global IPv6 address". I think you mean "global scope" (which
includes ULA), not "globally reachable" (which excludes ULA).

   Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 13 Feb 2017 09:30:33 +0000

> On Feb 10, 2017, at 9:02 PM, Brian E Carpenter <[email-masked]> wrote:
> 

yes.

s.

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Mon, 13 Feb 2017 14:20:29 +0000

Using ULA for Adj segment/special segment is good option. 
We can generate these addresses automatically and assign for adjacent  neighbors.

Thanks and Regards,
Veerendranath

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 11 February 2017 01:33
To: Stefano Previdi (sprevidi) <[email-masked]>; Veerendranatha Reddy Vallem <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

> In the IPv6 dataplane a SID being an IPv6 address, it makes the SID a global IPv6 address (even in the case of Adj-SIDs). This of course is orthogonal to the control plane that may or may not adver…

By the way, be careful with the phrase "global IPv6 address". I think you mean "global scope" (which includes ULA), not "globally reachable" (which excludes ULA).

   Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 13 Feb 2017 14:34:53 +0000

> On Feb 13, 2017, at 3:20 PM, Veerendranatha Reddy Vallem <[email-masked]> wrote:
> 

absolutely, ULA make sense in many use cases are fully supported in the segment routing architecture.

> We can generate these addresses automatically and assign for adjacent  neighbors.

sure. 

s.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2017 08:12:24 +1300

> absolutely, ULA make sense in many use cases are fully supported in the segment routing architecture.

That was my assumption. I'm very sensitive to the terminology trap, however,
since I discovered the hard way that the Python ipaddress module thinks that
ULAs are non-global. This confusion may exist in other programming
environments too. (Also see draft-bchv-rfc6890bis.)

   Brian