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 protected]> wrote: > > 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 protected]] > Sent: 10 February 2017 15:02 > To: Veerendranatha Reddy Vallem <[email protected]> > Cc: [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH > > 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 protected]> wrote: >> >> 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 protected]] >> Sent: 09 February 2017 22:41 >> To: Veerendranatha Reddy Vallem <[email protected]> >> Cc: [email protected]; >> [email protected]; >> [email protected]; [email protected] >> Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH >> >> 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 protected]> wrote: >>> >>> Dear Authors, >>> >>> I am requesting your clarification regarding usage of Adj-SID in SRH header >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
