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

Hi Sasha,
thank you for bringing the procedure a PLR to the discussion and providing
your understanding of the procedure at PLR:

a.       Push a new IPv6 header and a new SRH on the original packet.
                                                               i.      The
new SRH would include the Node SID of the Protector node and the Mirror SID
                                                             ii.      The
destination IPv6 address would be the address of the Protector node
                                                           iii.      The
Next Header value in the SRH would be IPv6
b.       Decrement the TTL in the inner IPv6 header
c.       Forward the packet towards the Protector node.

is very much different from the text in the draft:

P1 modifies the packet before
sending it to PE4.  The modified packet has destination PE4 with
mirror SID A4:1::3, and SRH with PE3's VPN SID A3:1::B100 and the
mirror SID A4:1::3 (i.e., "A3:1::B100, A4:1::3; SL=1").

The former text describes what can be characterized as bypass tunneling,
while the latter is not. And I'm very much concerned that the procedure, as
described in the draft, breaks immutability of SRH and thus violates RFC
8200.
I'm looking forward to hearing from the authors how PLR procedure really
works - as described by you or as documented in the text.
That said, I do not support the adoption of the draft at this point.

Regards,
Greg

On Sun, Feb 23, 2020 at 4:01 AM Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

> Dear all,
>
> I concur with Yimin's comments in his last email.
>
>
>
> I have also an additional concern regarding support of a Mirror SID in
> SRv6. This concern is based on the following observations:
>
> 1.       As per RFC 8402, a Mirror SID is a special case of the Binding
> SID
>
> 2.       In SR-MPLS, a Mirror SID is defined as a generalization of the
> Context label  as defined RFC 5331. If it is not the last label in the
> label stack, then, to the best of my understanding, it is just the Context
> label identifying the context label space in which the next label
> (representing the next SID in the list) is looked up. in other words, *ability
> of SR-MPLS to support Mirror SID is based on support of context labels and
> context label spaces in the MPLS DP*. IMHO and FWIW it would not work
> with the MPLS DP as defined in RFC 3031 and 3032.
>
> 3.       As mentioned in the email by Zhibo Hu
> <https://mailarchive.ietf.org/arch/msg/rtgwg/J2fJ3PF-bIYIeRzeWG83QpqpAR4/>,
> “The behavior of PLR encapsulating Mirror Sid is the same as that of SRv6
> Ti-LFA。draft-ietf-spring-srv6-network-programming section 5.1 has been
> mentioned that H.Encap is used to encapsulate the TiLFA Repair List”.  I
> assume that this what the draft in question intends to do, i.e.,:
>
> a.       Push a new IPv6 header and a new SRH on the original packet.
>
>                                                                i.      The
> new SRH would include the Node SID of the Protector node and the Mirror SID
>
>                                                              ii.      The
> destination IPv6 address would be the address of the Protector node
>
>                                                            iii.      The
> Next Header value in the SRH would be IPv6
>
> b.       Decrement the TTL in the inner IPv6 header
>
> c.       Forward the packet towards the Protector node.
>
> 4.       This technique would work just fine in the case when the
> inserted SID refers to a topological instruction (as in the case of Ti-LFA
> or in the case when a binding SID represented an SR policy.  *But I do
> not understand how it could be used with SIDs that are not topological
> instructions* without any updates to IPv6 data plane.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> -----Original Message-----
> From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of Yimin Shen
> Sent: Sunday, February 23, 2020 4:10 AM
> To: Huaimo Chen <huaimo.chen@futurewei.com>; rtgwg@ietf.org
> 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.
>
>
>
> >>    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 ?
>
>
>
> >>    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.
>
>
>
>
>
> Thanks,
>
> -- Yimin
>
>
>
>
>
> From: Huaimo Chen <huaimo.chen@futurewei.com>
>
> Date: Friday, February 21, 2020 at 11:45 PM
>
> To: Yimin Shen <yshen@juniper.net>, "rtgwg@ietf.org" <rtgwg@ietf.org>
>
> 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
>
> rtgwg@ietf.org
>
>
> https://clicktime.symantec.com/3F1LB8RvcSLpHAYLrEmGjgH6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> ___________________________________________________________________________
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>