Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection

[Huaimo Chen <[e-mail]>]

Hi Yimin,

    Thanks for your comments.
    My answers/explanations are inline below.

Best Regards,
Huaimo
________________________________
From: Yimin Shen <[e-mail]>
Sent: Saturday, February 22, 2020 9:10 PM
To: Huaimo Chen <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection

Hi Huaimo, Authors,

>> Step 1:  Find the P-Space P(Z, X) and the Q-Space Q(Y, X), which are similar to those in [RFC7490];

Unfortunately this is not a right solution. As I mentioned before, in egress protection, bypass path computation should not rely on LFA, because it is not finding a path to merge back to the protected/primary router. I have already suggested in a previous email to remove the link between PE3 and PE4, to make your discussion more generic. Similarly, the draft should not assume there is a multi-hop path from PE4 to PE3 which does not traverse P1. Your  mechanism must be able to return a bypass path in these cases. My suggestion is to take the guidelines in RFC 8679, and use context-IDs as locators.

[HC]: This is for finding a backup path to the backup egress node, where Y in Q(Y, X) is the backup egress node. Removing the link between PE3 and PE4 that you suggested is covered by considering (or removing resource X) in Q(Y, X), which seems more generic than removing the link (between PE3 and PE4), which is attached to X (e.g., PE3).

>>    Step 5:  Try to find a shortest path from Z to Y without going through X;

As a transit router, Z is supposed to perform generic bypass calculation for X (like other IPv6 addresses), based on a general FRR logic. So, how would Z even know to "Try" in this step ? What is it trying ? Isn't this "shortest path from Z to Y without going through X" the bypass path you are looking for in Step 1 - 3 ?

[HC]: Node Z as the PLR and the direct previous hop of the egress node, it calculates a backup path to the backup egress node. At first, the procedure finds a backup path to the backup egress node in a way similar to the one in SR TI-LFA. If a backup path is found in this way, then the path is returned; otherwise, it finds a shortest path from Z to Y without going through X (e.g., egress node PE3).

>>    For a (primary) locator associated with the (primary) egress node of a SR path/tunnel, most often the locator is routable.  This is the case we assumed,

Non-routable locator should be supported, and it can be supported. In this case, bypass path calculation should be based on BGP nexthop. Again, please refer to RFC 8679 regarding how to use context-ID as BGP nexthop for a solution.

[HC]:  The backup egress node used by the backup path calculation may be determined based on BGP nexthop and locator. Using BGP nexthop will be included in the next version of the draft.

Thanks,
-- Yimin


From: Huaimo Chen <[e-mail]>
Date: Friday, February 21, 2020 at 11:45 PM
To: Yimin Shen <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection

Hi Yimin,
    Thanks much for your comments.
    The procedure with details that a PLR uses to compute a backup path has been added into the draft, which has been uploaded.
Best Regards,
Huaimo
Hi Huaimo, authors,

>>> Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2.

I’m still concerned that there is no details in this draft about the procedures how a PLR computes a backup path to the protector, in both of the two cases below.

[1] the primary locator is routable.
[2] the primary locator is not routable.

Thanks,
-- Yimin