Re: [Isis-wg] draft-previdi-filsfils-isis-segment-routing

[stefano previdi <[e-mail]>]

Hi Iftekhar,

see comments below...


On Mar 25, 2013, at 6:56 PM, Iftekhar Hussain wrote:
> Repeat. Added isis-wg list. Some error in the previous post.
> 
> -----Original Message-----
> From: Iftekhar Hussain 
> Sent: Monday, March 25, 2013 10:54 AM
> To: 'stefano previdi'
> Cc: [e-mail]; '[e-mail].'
> Subject: RE: draft-previdi-filsfils-isis-segment-routing 
> 
> Thanks Stefano. Sorry I thought that the isis-wg list is copied. This time I have explicitly added isis-wg list to the cc. 
> Please see few comments in-line.
> 
> -----Original Message-----
> From: stefano previdi [mailto:[e-mail]]
> Sent: Monday, March 25, 2013 3:23 AM
> To: Iftekhar Hussain
> Cc: [e-mail]
> Subject: Re: draft-previdi-filsfils-isis-segment-routing 
> 
> Hi Iftekhar,
> 
> thanks for you comments. 
> 
> Note that you addressed your email only to the authors. Maybe, next time, let's also include the ISIS WG mailing list.
> 
> See below some answers.
> 
> On Mar 23, 2013, at 12:25 AM, Iftekhar Hussain wrote:
>> Hi Authors,
>> Interesting work. Few clarification questions and comments:
>> Section 1:
>> a)      "These segments act as topological sub-paths that can be combined together to form the desired path."
>> So the advertising node would need to first find/compute these sub-paths before advertising the segments? Does this mean a change to the existing IGP processing logic?
> 
> 
> The IGP processing logic doesn't change. What we added on top of it is the ability of using paths that are in fact an assembly of portion of different SPTs.
> 
> This is not substantially different fro what PCALC algorithm does today for RSVP-TE.
> 
> Obviously, the ISIS operations and algorithm does NOT change otherwise you won't be backward compatible. SR is NOT disruptive.
> 
> In its default behavior, a SR capable router will just compute SPT and find that for each leaf of the SPT it has a segment identifier (the Node-SID of the router advertising the leaf).
> 
> Now, think what you could do if you take portion of shortest paths (i.e.: 
> portion == segment) and combine them together. This doesn't impact at all ISIS SPF computation. It's a decision the ingress router (or an SDN orchestration system) can take.
> 
>       A----B----C----D----Z
>                 \        /
>                  \      /
>                   X----Y
> Example: 
>  . Router A's shortest path to Z is: A-B-C-D-Z
>  . However, C has another path (not shortest) to Z: C-X-Y-Z
>  . Also, X's shortest path to Z is: X-Y-Z
>  . If router A wants to use shortest pat to C and then diverge 
>    from shortest in C it can combine both and put the following 
>    label stack: X, Z
>  . Label X will bring the packet along to SPT into X and label Z
>    will bring the packet to its final destination. 
>  . Router A has combined two segments from two shortest paths:  
>       . Path-1: A to X
>       . Path-2: X to Z
> 
> As you can see, router A has computed its normal topology (set of shortest paths) and picked up some segments of them, combined them together in order to have an explicit path.
> 
> Again, from a path perspective is no different from PCALC. However, the big difference here is that, once computed, the path requires NO signaling.
> 
> [Iftekhar] Thanks for the clarification. It is now much clear. Suppose a user (CLI or SDN) requests an arbitrary explicit path (e.g., manually specifies a list of nodes to traverse) which diverges from all available SPTs, what would be the expected behavior for an ingress LSR using SR (just trying to contrast it with regular RSVP-TE)? 


in SR, paths are not signaled. The path is in the packet in the form 
of a label stack. If the path is computed by an SDN orchestration 
system or by a PCE, the result is a label stack that will be pushed
on top of the packet. When the packet enters the network each router 
will just do its job and forward the packet according to the label 
at the top of the stack.


>> b)      "In Figure 1, all the nodes must be configured with the same Segment Routing Identifiers Block (called SRB Node Registry)."
>> Would there be periods during which segment numbers can collide? For example node A and B advertise the same segment.
> 
> 
> Node-SID values must be unique in the ISIS domain, same as ip addresses. By default, you need one Node-SID per router (i.e.: not a big deal). We have defined dynamic/automatic mechanisms for ensuring the unicity but most of operators (if not all of them) do not perceive the need to automate this process. Again, we're talking about one Node-SID per box so it can be handled exactly in the same way IP address allocation is done today.
> 
> [Iftekhar] I guess what you mean is that through manual provisioning the operator would need to ensure that each node has a unique Node-SID. It would be helpful to clarify this operational aspect in the draft. 


indeed. I'd let operators to comment on this but yes, I presume the 
same (or similar) provisioning mechanisms used for IP addresses would 
be used.

Note that ISIS implementations may always signal through a syslog 
message when a collision ins found. I know an implementation that does 
it already ;-)


>> Section 2/2.1:
>> c)       "Segment Routing is applicable to the following use-cases: simplicity, TE, FRR and SDN"
>> Does the segment-routing control plane also intended to address PW label distributions?
> 
> 
> of course, you can use SR to distribute PW end-points. It's just another SID.
> 
> [Iftekhar] I think, it would be very useful to add this use case and the corresponding SR operational/behavioral details. 
> 
>> d)       "An adjancey segment is instantiated as a crossconnect entry pointing to a specific egress".
>> To me, a crossconnect implies an ingress to egress data path through a node. Can you provide an example of the crossconnect in the MPLS data plane?
> 
> 
> maybe "cross-connect" is not the best word...
> 
> We can say the Adj-SID determines a one-hop path from a router to one of its adjacent neighbors. Using the Adj-SID on top of a packet will make you sure the packet is going from the node that advertised the Adj-SID up to the adjacent neighbor represented by the Adj-SID value, no matter what the SPT and routing table says in the node.
> 
> This allows you, if needed it, to support some form explicit paths. I intentionally say "some form of" because most of the explicit path cases can be easily handled through Node-SID (without any Adj-SID).
> 
> However, Adj-SID is one more option in SR.
> 
> [Iftekhar] OK, I see. It would be good to add an example with the use of Adj-SID.
> 
>> e)      "Node segments must be globally unique within the network domain". 
>> So the maximum allowable range in a network will be determined by the node with the minimum range?
> 
> 
> yes.
> 
> 
>> f)       Do you plan to allow multiple disjoint ranges or just one range?
> 
> 
> multiple.
> 
> 
>> Section 2.2:
>> g)       "...A single node segment enumerates all the ECMP paths along the shortest-path".
>>    So in Fig 3, there would be single node segment A to M for all six paths?
> 
> 
> yes. Think about how ISIS works. When you compute SPT the shortest path to a given leaf node is just one. Then, when computing SPT algorithm and moving nodes from TENT to PATHS, you compute the set of adjacencies the leaf node is reachable through. At this stage you populate your set of available next-hops.
> 
> Still, from a SPF algorithm perspective, you have computed shortest path to a leaf node.
> 
> This doesn't mean you lose control on which path you take of course. 
> Using Node-SIDs you may explicit state which of the ECMP members you want to use.
> 
> [Iftekhar] OK.
> 
>> h)      "Alternatively, a three-label stack with adjacency segments FI, IK and KM could have been used".
>> What is the maximum label stack depth needed in an arbitrary topology using this option?
> 
> 
> Worst case scenario: as many labels you have adjacencies in the network. 
> But if you come to that, your network has a design flaw ;-)
> 
> In practice, you will use (most of the time and in most of the
> topologies) explicit paths through concatenation of segments of shortest paths (see my example). This substantially compresses the label stack depth.
> 
> 
>> i)        For the Fig 3 example, how does node A or other nodes determine (or build the label stack)? It is not clear just based on segments how nodes infer/learn to instantiate correct label stack in the MPLS data plane?
> 
> 
> ISIS SPF and explicit path computation. Exactly as it is done today in
> MPLS:
> . ISIS computes SPT
> . You populate your RIB
> . SR gives also the SID values for each leaf node . MPLS FIB is them populated with the SID values coming from ISIS
>  (rather than LDP).
> 
> For explicit routing, you will use PCALC the same as today. When your explicit path is computed, the ISIS LSDB will also tell you which SID to use (i.e.: the label stack you have to push prior to send out the packet).
> 
> [Iftekhar] Now it is much clear. I assume no BW CAC as there is no explicit signaling of path unlike RSVP-TE? 


correct.

Note that extensions like draft-previdi-isis-te-metric-extensions are 
helpful here because they give you the exact resource availability 
that you can take into account during your explicit path 
computations.


>> j)        "The network does not hold any signaling state for the traffic engineered flows..."
>> Won't there be some state for explicit routes somewhere?
> 
> 
> no, that's the beauty of SR.
> 
> The statement is clear: no "signaling" state for the explicit paths.
> 
> This means that the router computing the explicit path will obviously keep knowledge (i.e.: state) of that path but it will not signal it anywhere.
> 
> 
>>   Availability Implications:  Any drawback of combining the IGP/MPLS control planes:
>>     = Now with MPLS and IP control planes combined, a failure will affect both IP and MPLS control planes?
> 
> 
> It has been ALWAYS the case,m nothing new here. Before SR, at any failure, you need to wait for ISIS to converge and then LDP has to figure out that it has to re-advertise or withdrawn labels, not to mention the RSVP signaling storms that would happen during convergence.
> 
> Now, SR brings a substantial advantage: MPLS forwarding plane benefits from ISIS convergence performance. This is WAY better than the interaction between LDP and ISIS.
> 
> Before SR, at any failure, you needed to wait for ISIS to converge and then LDP to figure out that it has to re-advertise or withdrawn labels (not to mention the RSVP signaling storms that would happen during convergence).
> 
> With SR, everything is done inside ISIS convergence.
> 
> s.
> 
> 
> [Iftekhar] OK. Suppose  there is a SR control plane failure a remote node in a network, a given local node who is using some SIDs its data plane, it will keep forwarding oblivious of that failure until its local SR control plane decides to update/remove that entry?  


yes, this is ordinary ISIS convergence. However, with SR, you get new 
labels and new isis topology in one shot (i.e.: when the new ISIS LSP 
arrives).

s.



> 
>> 
>> Thanks,
>> Iftekhar
> 
>