I think it would be good to discuss this topic within SPRING WG.
-----Original Message-----
From: OSPF [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: [email protected];
[email protected]; [email protected];
[email protected]
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.
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. Based on
this, introducing "NON PROTECTED" NodeSID does not help in solving this
transient situation.
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.
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. In case of protected NodeSID used, OAM will not work, because
switchover time will be too small. Using OAM , defacto requires path with no
protection.
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:[email protected]]
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak
(ppsenak); [email protected];
[email protected]; Hannes Gredler;
[email protected]; [email protected]
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, [email protected] 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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
