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

Great discussion!
Huaimo - glad to see good working cooperation! 

Regards,
Jeff

> On Jan 24, 2020, at 23:30, Huaimo Chen <huaimo.chen@futurewei.com> wrote:
> 
> 
> Hi Yimin,
> 
>     Thank you very much for your questions/comments.
>     Our answers/explanations are inline below.
> 
> Best Regards,
> Huaimo
> From: Yimin Shen <yshen@juniper.net>
> Sent: Thursday, January 23, 2020 3:01 PM
> To: Huaimo Chen <huaimo.chen@futurewei.com>; draft-hu-rtgwg-srv6-egress-protection@ietf.org <draft-hu-rtgwg-srv6-egress-protection@ietf.org>; rtgwg@ietf.org <rtgwg@ietf.org>
> 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 <huaimo.chen@futurewei.com>
> Date: Friday, January 17, 2020 at 7:54 PM
> To: Yimin Shen <yshen@juniper.net>, "draft-hu-rtgwg-srv6-egress-protection@ietf.org" <draft-hu-rtgwg-srv6-egress-protection@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
> 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&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cdc68094f998c4624680008d7a03f08c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154064906843548&amp;sdata=763BOw%2F6npr9q64hjiPyuykWw8bI2GV0c%2BdcVhqvfn8%3D&amp;reserved=0
>     
> Best Regards,
> Huaimo
> 
> From: Huaimo Chen <huaimo.chen@futurewei.com>
> Sent: Thursday, January 16, 2020 10:24 AM
> To: Yimin Shen <yshen@juniper.net>; draft-hu-rtgwg-srv6-egress-protection@ietf.org <draft-hu-rtgwg-srv6-egress-protection@ietf.org>; rtgwg@ietf.org <rtgwg@ietf.org>
> 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 <yshen@juniper.net>
> Sent: Wednesday, January 15, 2020 2:22 PM
> To: draft-hu-rtgwg-srv6-egress-protection@ietf.org <draft-hu-rtgwg-srv6-egress-protection@ietf.org>; rtgwg@ietf.org <rtgwg@ietf.org>
> 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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg