draft-bashandy-rtgwg-segment-routing-uloop

[[e-mail]]

[changing the title to the real draft being discussed]

Hi Stewart,
Please see inline [Bruno]



Orange Restricted
From: Stewart Bryant <[e-mail]>
Sent: Saturday, November 4, 2023 1:35 PM
To: Gyan Mishra <[e-mail]>
Cc: Stewart Bryant <[e-mail]>; Alexander Vainshtein <[e-mail]>; [e-mail]; rtgwg-chairs <[e-mail]>; [e-mail]
Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment


I looked at draft-bashandy-rtgwg-segment-routing-uloop again and it appears to be proposing  RFC 5715 Section 6.3 far side tunnelling with the constraint that the path into Q space is congruent with the post convergence path.

[Bruno] Yes. draft-bashandy-rtgwg-segment-routing-uloop is:

  *   RFC 5715 Section 6.3 far side tunnelling
  *   Using SR to reach the "far side". (while RFC5715 did not really had a solution for this problem, while of the difficulty is to reach this far side)
  *   Along the path that the IGP has computed (aka post-convergence path)


What draft-bashandy does not emphasis clearly enough in my opinion is that EVERY ingress that might be carrying traffic over the failure MUST take part in this process.

[Bruno] Not certain what you mean:

  *   Having a single node P1 supporting draft-bashandy is enough to avoid micro-loops from P1 up to all its destinations. So I'm not sure I would call it a MUST as per RFC2119
  *   If you want to protect all traffic from all micro-loops, you need all nodes to support draft-bashandy. But deployment can be incremental with incremental benefit

A further thing to note is that it is actually quite difficult to compute the post convergence path
[Bruno] That part is actually extremely simple: it's a simple SPF and this is the SPF already done by the IGP for its normal operation.
What is more difficult is to compute the SR Policies to avoid micro-loops until you reach the Q space. There may be multiple algorithms and different vendors may have chosen different ones. It's mostly a local issue but ideally the network operator would like to know the objectives of the implementation as there are typically trade-offs. Ideally, we would want:

  *   Handle any transition from graph1 to graph2 (link failure is relatively trivial, node failure a bit less, SRLG (any set of link failures) failures a bit less)
  *   Handle any number of consecutives/overlapping IGP convergences (from graph1 to graph2 ... to graph N)
  *   Fast computations (compared to TI-LFA, those computations are performed after the failure to computation time delay the IGP convergence time)
  *   Minimize the number of SIDs (e.g. MPLS labels)
Depending on your implementation/market you may want to optimize for a different thing..


because to do so you need to determine the decision that every node along the path will take and you cannot do that with 100% certainty because you cannot be sure which of the available next hops it will consider using and even if that is not an issue you cannot anticipate the ECMP decision that it will take as that may well be different depending on the MPLS label stack (which will be different in the case of draft-bashandy compared to native transit). Now of course this will not affect the loop free convergence process if this is wrong, but that takes me to the point in the next paragraph.
[Bruno] I'm not sure what you mean by "wrong". We compute and enforce the shortest IP path. If there are ECMP, they are used. Among the ECMPs, the specific path used by a specific flow is not control by the router doing the SPF computation. With or without draft-bashandy-rtgwg-segment-routing-uloop. Due to the extra SR segments/labels, the path of a given flow may be different with a without draft-bashandy-rtgwg-segment-routing-uloop. But in any case, the aggregate traffic is load balanced across all paths

Rather than do the complicated congruence calculation, a very good approximation (and compatible approach) would be to tunnel the traffic into Q space WRT the failure using one or two labels as needed (what draft-bashandy does but without the attempt at the strict constraint constraint).
[Bruno] The congruence calculation is not complicated. That the usual IGP SPF. What's harder is to compute the SR policies to enforce the loopfree path, and you would need this in all cases to safely rech the Q space.
You are referring to 1 or 2 labels, but this is only applicable for a small subset (link failures). In the general case, anyone (post convergence path or not) may need more than 2 labels

Of course if a node chooses to perform the complex calculation to find path congruence it may do so, but this approximate approach will work just as well and interoperably with nodes that chose a simpler approach.  If an  ingress node choses to use nearside tunnelling as far as I can see this would be a perfectly viable alternative and would be compatible with nodes choosing the approach in draft-bashandy.
[Bruno] I should probably refrain from side tracking to nearside tunnelling... But note that in essence, one could see draft-bashandy-rtgwg-segment-routing-uloop as Nearside Tunneling with using SR "tunnels" as tunnels. (note that we usually avoid using the term "tunnels" for SR). But we do specific computations to only use Segments (tunnels) which are not impacted by loops (IOW segments whose paths is not affected)

Now I note that draft-bashandy requires a conservative estimate of the convergence time of the slowest router along the path. That value will change over time (possibly faster possibly slower) as the network evolves, and thought should be given to the protocol work that we started in RTGWG to advertising this parameter some years ago (draft-ietf-rtgwg-routing-timer-param-sync).
[Bruno] yes it uses a timer value. IMHO the exact value is not that important for draft-bashandy-rtgwg-segment-routing-uloop because before and after this timer, all traffic is using the same path (the IGP shortest path). So the only "cost" are the extra labels being pushed (for SR-MPLS) To me, we don't really need to signal it, but yes, one may want to advertise and use it. (using it would requires that all nodes support the advertisement)

So I as far as I can see the requirement in the TiLFA draft needs to be that a network MUST deploy a loop-free convergence strategy.
[Bruno] Not it's not a must. There may be a misunderstanding that I will try to cover in a different thread.

That strategy can be any of the RFC 5715 strategies.
[Bruno] yes. (But in a SR network, I would argue that draft-bashandy-rtgwg-segment-routing-uloop is the best solution. And if you have deployed TI-LFA, you are guaranteed to have SR available.
But let's avoid the discussion about preferences)

--Bruno

If the PLR can be sure that the whole network is using one of the tunnel approaches that is fine, but we should note that an individual ingress router may chose either the nearside or the far side approach using any topology that safely delivers the packet into Q space WRT the failure. If the PLR cannot be sure that the whole network supports a tunnel based approach it may independently finesse this by using the incremental link cost approach.

- Stewart







____________________________________________________________________________________________________________
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.