Great discussion! Huaimo - glad to see good working cooperation! Regards, Jeff
> On Jan 24, 2020, at 23:30, Huaimo Chen <[email protected]> wrote: > > > 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 > > 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
