Re: Routing Header Insertion

["Voyer, Daniel" <[e-mail]>]

Hi Ron,

> Those need to be put at the end of the line, so that they are visited *after* the nodes in the repair path.

Exactly as defined in the pseudocode. https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-insertion-00#section-3.2

Just to also remind you the context of this email is SRH insertion for TI-LFA as demonstrated by Juniper and other vendors in the EANTA report. Nothing to do with uSID solution.

It’s also nice to know, from the report - obviously, that it interop with the other vendor’s platform.

Thanks
dan

From: ipv6 <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Date: Thursday, May 7, 2020 at 1:46 PM
To: Robert Raszuk <[e-mail]>
Cc: 6man <[e-mail]>
Subject: RE: Routing Header Insertion

Robert,

The problem is that the IPv6 destination address contains 5 uSID that represent 5 nodes yet to be visited. Those need to be put at the end of the line, so that they are visited *after* the nodes in the repair path.



Yes, there are some very clever solutions that you and I understand. But will the guy in the NOC who doesn’t live and breath SR be able to figure it out the first time he sees it.

                                                                             Ron




Juniper Business Use Only
From: Robert Raszuk <[e-mail]>
Sent: Thursday, May 7, 2020 1:28 PM
To: Ron Bonica <[e-mail]>
Cc: Voyer, Daniel <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; 6man <[e-mail]>
Subject: Re: Routing Header Insertion

[External Email. Be cautious of content]

Hi Ron,

>  Yes, the problem can be solved, but not without deep though and vigorous head scratching.

Well don't we still have the indicators of Active, Next and Last uSIDs in SRH ? If so what is so difficult if you keep your original SRH as is and provide FRR using new SRH ? Moreover if you POP the additional SRH @ ptotectied path PHP FRR endpoint may not even noticed he is acting as such endpoint and that is very cool thing.

The problem perhaps becomes a nice exercise to solve how to handle TI-LFA when you have uSID list in DA address of the packets and where there is no SRH at all :) Clearly a valid deployment scenario. But since you are already deep into it I will let you figure it out :)

> When a solution is that complex, it is probably beyond the capability of any operations staff.

Well it would be a mistake to count on all operators doing this handling in P4 code on their own custom platforms. For rest of them a simple knob would be sufficient to enable it and enjoy.

Thx,
R.


On Thu, May 7, 2020 at 7:03 PM Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>> wrote:
Hi Daniel,

TI-LFA with SRH insertion poses problems in the following cases:


  *   When the packet already contains an SRH
  *   When the IPv6 Destination Address contains uSIDs

In the first case, when the packet already contains an SRH, TI-LFA with SRH insertion results in a single packet that contains two SRH’s. No reading of RFC 8200 allows this.

The second case is more complex. Assume that in your uSID strategy:


  *   The uSID block identifier is 32 bits long
  *   Each uSID is 16 bits long
  *   The end-of-carrier marker is also 16 bits long

In this case, you can fit 5 uSIDs in the IPv6 address.

On the first segment, when the destination address still contains 5 uSIDs, a PLR detects link failure and invokes TI-LFA procedures. The repair tunnel contains 3 segments. If the PLR executes TI-LFA with insertion procedures, what does the resulting IPv6 Destination address look like? What does the SRH look like?

Yes, the problem can be solved, but not without deep though and vigorous head scratching. When a solution is that complex, it is probably beyond the capability of any operations staff.

The above-mentioned problems could have been avoided if TI-LFA created its repair tunnel by prepending an IPv6 header with its own SRH.

                                                                                                 Ron


Juniper Business Use Only