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
