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

[Yimin Shen <[e-mail]>]

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.

>>> 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 ?

>>> 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 ?

>>>   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 ?

Thanks,

-- Yimin


From: Huaimo Chen <[e-mail]>
Date: Friday, January 17, 2020 at 7:54 PM
To: Yimin Shen <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hu-rtgwg-srv6-egress-protection/__;!!NEt6yMaO-gk!TDva0v6bD2UzkBVmAXlu3SHbiLLda_7eyqu28BCLs97rtLsnzRTaNah22w8KUjA$
    
Best Regards,
Huaimo

From: Huaimo Chen <[e-mail]>
Sent: Thursday, January 16, 2020 10:24 AM
To: Yimin Shen <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]>
Sent: Wednesday, January 15, 2020 2:22 PM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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