Hi Yimin,
Thanks for your comments.
My answers/explanations are inline below.
Best Regards,
Huaimo
________________________________
From: Yimin Shen <[email protected]>
Sent: Saturday, February 22, 2020 9:10 PM
To: Huaimo Chen <[email protected]>; [email protected] <[email protected]>
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 <[email protected]>
Date: Friday, February 21, 2020 at 11:45 PM
To: Yimin Shen <[email protected]>, "[email protected]" <[email protected]>
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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
