Note that the case you pointed regarding bidirectional LSP with SPRING is also interesting to investigate.
-----Original Message----- From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com] Sent: Tuesday, January 13, 2015 19:59 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org Subject: RE: Providing unprotected SPRING TE path Hi Stephane, et. al, very interesting topic. Please find my questions, notes in-lined and tagged GIM>>. Regards, Greg -----Original Message----- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Monday, January 12, 2015 12:18 AM To: spring@ietf.org Subject: [spring] Providing unprotected SPRING TE path I think it would be good to discuss this topic within SPRING WG. -----Original Message----- From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Monday, January 12, 2015 09:14 To: Rob Shakir Cc: isis...@ietf.org; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; o...@ietf.org; draft-ietf-isis-segment-routing-extensi...@tools.ietf.org Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions Hi, After discussing a lot with Les offline, we almost found an agreement on the understanding of this use case and possible relationship with unprotected SIDs. Use case : Creation of a SR TE tunnel which is unprotected. Protection may be provided end to end using for example two disjoint paths. GIM>> So, this is e2e protection for unidirectional LSP or for e2e bi-directional associated LSP (in MPLS-TP terms)? Controller based or ingress based tunnel setup. It seems clear now that using ONLY unprotected SIDs does not solve the issue as when a link fails, convergence will happen, and nodes that are near the failure may reroute a NodeSID Algo 0 used within the TE stack before Ingress or controller recomputes the new path fitting constraints. So there may be transient situations where the path does not fit constraints anymore. GIM>> Is local protection being assumed in this scenario? Local protection, e.g. RSVP FRR, always viewed as transient, temporary solution and not as one that satisfies all constraints. Lower priority services likely to be affected, squeezed out of BW until services recovered and new working paths established. Based on this, introducing "NON PROTECTED" NodeSID does not help in solving this transient situation. GIM>> If Local protection is available, then what is the interpretation of "NON PROTECTED" characterization? Now, as I explained, IMO, it's possible to introduce end to end OAM on top on the SRTE to bring the LSP down as soon as there s something wrong on the path. GIM>> Assuming the monitored LSP is unidirectional and "bring down" must happen at ingress. As we demonstrated in draft-mirsky-mpls-bfd-directed, CC session must be bi-directional co-routed in order to avoid false positive and false negative if and when action by the ingress required. Or use AIS-like OAM. A Holddown timer can be used to keep LSP down until convergence happens at Ingress or Controller. But introducing such OAM and holddown and coupled with relations with IGP may also be complex and there is a chance that it does not solve the issue. GIM>> Multi-layer OAM does require coordination of defect detection timers. AIS can help to suppress unnecessary alarms if and when server layer defect already detected. In case of protected NodeSID used, OAM will not work, because switchover time will be too small. GIM>> I think this generalization is too strong. For example, e2e CC monitoring can work with 3.3 msec interval and detect defect in 10 msec guaranteed. Add sub-50 msec for service switchover, e.g. Linear Protection. What doesn't work here? Using OAM , defacto requires path with no protection. GIM>> I think that terminology clarification would be helpful. What OAM you're referring to - pro-active CC like BFD with 3.3 msec interval or on-demand CC like LSP Ping? So unprotected SID+OAM may solve the use at the price of some complexity and possibly not solving 100% of the cases. To conclude : We need to solve this use case and we need to find another elegant, simple and scalable solution for this. Possible existing solutions : - Use Adj-SID only => does not sounds good as there will be an impact of stack depth => Path compression necessary - Use binding TLV and create some new Node-SID corresponding to a set of Adj-SID => This introduces more states within the network (how many ?) - Anything else ? Best regards, Stephane -----Original Message----- From: Rob Shakir [mailto:r...@rob.sh] Sent: Thursday, January 08, 2015 10:52 To: LITKOWSKI Stephane SCE/IBNF Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler; o...@ietf.org; isis...@ietf.org Subject: Re: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions Stephane, If we think about the “MUST NOT be protected” case that you mention. Let’s assume that we have a service that is performance sensitive, such that we want to take a particular path through the network - and that we use Node-SIDs like you say. If we assume that the requirement is for A-B-C-D-E path below. The node SID for E points via C-D-E and hence is used for stack compression like you say: A -- B -- C -- D -- E | / --- Q --- In your envisaged behaviour, C does not protect the Node-SID for E. In the case of the C-D link failure, then the “preferred” behaviour is that C now drops traffic towards this destination. However, C does not remove the FIB entry for the Node-SID for E, it’s actually just now known via Q. At this point, A can forward with exactly the same stack, and the packet takes a new A-B-C-Q-E path, which is non-conformant with the performance requirement of the service. In terms of what C does with its FIB, does it simply not use C-Q-E during the failure, but post-reconvergence use it anyway? If so, why not use C-Q-E during the failure - because the service is always going to non-conformant to the performance requirement? With an Adj-SID, it makes sense, because essentially unless that adjacency is available, then there is no alternate path for the SID that will be taken - so traffic never hits a non-conformant path. Practically, if I can’t tell a customer that the path taken will definitely be A-B-C-D-E, and it may rather go via C-Q-E at some point following convergence [until the head-end calculates that such a change had happened - either a link outage, or a metric change - and stops using the label stack], then there’s little problem of having the traffic go via C-Q-E during protection. For the disjoint case, the consideration that one has to make is: * are alternative SPF paths for a particular Node-SID actually still conformant with the disjointness requirement? How many simultaneous failures does one require to violate constraints. For example, in a dual-plane core network, then if the requirement is disjointness at the IP level, then we may need to lose connectivity entirely within the plane before it is preferable to “hop” to another plane. In this case, using an alternative SPF path for the Node-SID is actually not a problem for disjointness. * does the application prefer losing an entire path to having some risk of the services being shared fate until the re-optimisation? From the work that we’ve looked at thus far, I have not yet seen a case where I absolutely MUST NOT use an alternate shortest path for a Node-SID and hence don’t require protection at a practical level. Stack depth is definitely going to be something that we need to consider - to me, where we have centralised controller - actions such as dynamically created forwarding-adjacency LSPs which allow “expansion” of one segment into a set of segments within the path are attractive as a solution where one needs to have explicit routing of traffic for TE purposes. Does this make sense, or do you see the use case that we’re addressing here differently? Cheers, r. > On 7 Jan 2015, at 09:44, stephane.litkow...@orange.com wrote: > > Hi, > > I'm coming into this long thread and I tried to read all the exchange > but I may be missed some lines :) > > But here is my opinion on this subject. > I think the point from Shradda is valuable in case of Traffic Engineering > with Segment Routing, especially with a central controller. > > Today in TE networks, we are selling some disjoints paths to customer that > MUST NOT be protected (SDH like services). It would be good to reproduce the > same thing with SR-TE. > > Now, current encoding permits to advertise that a specific Adj-SID is > protected or not (as already mentioned, this does not say that a protection > really exists ..., in case of LFA protection , there may be no FRR path for > this adj-SID despite of the protection flag set). > We pretty know that it would not be possible in all case to use only Adj-SID > for a TE tunnel (due to label stack depth), so we need to introduce stack > compression using SPT segments and node-SID. > So to reply on Rob's comment, on RSVP-TE tunnels with looses hops that does > not request protection : yes for RSVP, it does not make sense to me, but for > SR, due to stack compression, it will be needed. > > If we look at a network, where TE is managed by a central controller, how the > controller can ensure that the node-SID used is protected or not (as for > Adj-SID, I mean protection requested, not protection installed). I see two > ways : > * Use two SIDs attached to the same prefix and add a flag to prevent > automatically all nodes to compute a protection for one of the SID. The flag > does not really force nodes to compute a protection. Each node will still > require local configuration for protection, but the flag will permit to > exclude some prefixes for protection (overriding local policy). > > * Use two prefixes on each node , prefixes are marked with tags > (admin-tags) : "protection tag" and "non protection tag". Each router is > configured using LFA policies to not compute protection for prefixes having > "non protection tag" AND add knowledge to the controller to use only "non > protection tag" prefixes to compress non protected path. > > > Best Regards, > > Stephane > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
