-----Original Message----- From: LITKOWSKI Stephane SCE/IBNF Sent: Thursday, January 08, 2015 12:10 To: 'Rob Shakir' 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; ospf@ietf.org; isis...@ietf.org Subject: RE: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions
Hi Rob, Please find inline comments -----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; ospf@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. [SLI] Completely agree, but to prevent the transient period, you can use OAM on top to bring down the LSP at ingress and let it down until ingress or controller has converged an provided a new stack. 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. [SLI] In case of architecture with disjoint path and end to end protection , local protection may prevent the end to end protection to be activated. 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. [SLI] It's fine for dual plane network, but for flat networks with SRLG at transmission level, it's not so easy. * does the application prefer losing an entire path to having some risk of the services being shared fate until the re-optimisation? [SLI] It's not the question here ... in case of disjoint path and end to end protection, yes , the application prefers to loose completely a path and switch to another. For some other applications where a single LSP is available, for sure, there is no issue with transient situations that are not completely optimal. 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. [SLI] There is the case today with RSVP-TE, so for sure, use case applied to SR also. 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. [SLI] Yes that's an approach, but this will create more states in the network. Drawback or not, I don't know today. Does this make sense, or do you see the use case that we’re addressing here differently? Cheers, r. _________________________________________________________________________________________________________________________ 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. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
