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 From: Huaimo Chen <[email protected]> Date: Friday, January 24, 2020 at 5:30 PM To: Yimin Shen <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection Hi Yimin, Thank you very much for your questions/comments. Our answers/explanations are inline below. Best Regards, Huaimo ________________________________ From: Yimin Shen <[email protected]> Sent: Thursday, January 23, 2020 3:01 PM To: Huaimo Chen <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection Hi Huaimo, authors, I have some further comments and questions about this draft. Some of them are fundamental. In section 3: >>> Node P1's pre-computed TI-LFA backup path for PE3 is from P1 to PE4 via P2. You cannot rely on TI-LFA to compute a backup path for egress node protection. In egress node protection, there may not be a TI-LFA path (e.g. if you remove the link between P3 and P4), but P4 should still be able to provide the protection. I think the draft should support this case and this kind of topologies. [HC]: This is a good catch. We will use backup path instead of TI-LFA backup path for egress node protection. The draft has been updated accordingly. >>> PE3 has a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator >>> A4:1::/64 and a VPN SID A4:1::B100. I'm not sure if you can assume that locator and service SID are de-coupled. If you read draft-ietf-spring-srv6-network-programming and draft-ietf-bess-srv6-services, locator is embedded in service SID. How do you handle this ? [HC]: In fact, in the text above as you mentioned, the locator A3:1::/64 that PE3 has is a part of the VPN SID A3:1::B100; the locator A4:1::/64 is a part of the VPN SID A4:1::B100. >>> When PE3 fails, node P1 protects PE3 through sending the packet to PE4 via >>> the backup path pre-computed. 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"). How does P1 know about the mirror SID ? [HC]: The mirror SID is distributed by IGP (OSPF or IS-IS). P1 knows the mirror SID through IGP. >>> For protecting the egress link between PE3 and CE2, when the link fails, >>> PE3 acting as PLR like P1 detects the failure and forwards the packet to >>> PE4 via the pre-computed backup path from PE3 to PE4. When PE4 receives >>> the packet, it sends the packet to the same CE2. What does the encapsulation look like, in terms of IPv6 DA and SRH ? How does PE3 know about the mirror SID ? [HC]: PE3 also knows the mirror SID through IGP, which distributes the mirror SID. When the link fails, PE3 as a PLR encapsulates/modifies the packet as follows: 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. Thanks, -- Yimin From: Huaimo Chen <[email protected]> Date: Friday, January 17, 2020 at 7:54 PM To: Yimin Shen <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection Hi Yimin, Thanks very much for your suggestions/comments. The draft has been updated accordingly. https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-rtgwg-srv6-egress-protection%2F__%3B!!NEt6yMaO-gk!TDva0v6bD2UzkBVmAXlu3SHbiLLda_7eyqu28BCLs97rtLsnzRTaNah22w8KUjA%24&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cdc68094f998c4624680008d7a03f08c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154064906843548&sdata=763BOw%2F6npr9q64hjiPyuykWw8bI2GV0c%2BdcVhqvfn8%3D&reserved=0<https://urldefense.com/v3/__https:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-hu-rtgwg-srv6-egress-protection*2F__*3B!!NEt6yMaO-gk!TDva0v6bD2UzkBVmAXlu3SHbiLLda_7eyqu28BCLs97rtLsnzRTaNah22w8KUjA*24&data=02*7C01*7Chuaimo.chen*40futurewei.com*7Cdc68094f998c4624680008d7a03f08c7*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637154064906843548&sdata=763BOw*2F6npr9q64hjiPyuykWw8bI2GV0c*2BdcVhqvfn8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!ShXW6GjWY5lV87iok-x1N-GVG93aRcHLoACviUYabpelXA07ZNvYHmmPl9U9M6k$> Best Regards, Huaimo From: Huaimo Chen <[email protected]> Sent: Thursday, January 16, 2020 10:24 AM To: Yimin Shen <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-protection Hi Yimin, Thank you very much for your suggestions/comments. I will add reference RFC 8679 with some texts into the draft. Best Regards, Huaimo From: Yimin Shen <[email protected]> Sent: Wednesday, January 15, 2020 2:22 PM To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Mail regarding draft-hu-rtgwg-srv6-egress-protection Hi authors, I’d like to suggest this draft to reference RFC 8679. In particular, RFC 8679 as a generic EP framework with a lot of general discussions (see the points below), which are applicable to both MPLS and IPv6 data plane, and all types of transport tunnels. However, this draft seems to have almost no consideration or discussion on these topics. I don’t think the draft needs to repeat these discussions, but I suggest to add a section(s) to discuss these points generally by referencing RFC 8679. • general scope and requirements • transport layer failure/protection vs. service layer failure/protection • applicability • failure detection mechanisms • egress node protection • egress link protection • relationship between EP and global repair • co-existing of different types of transport tunnels and bypass tunnels • security Thanks, -- Yimin Shen Juniper Networks
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
