Hi Greg, Thanks for your comments. My answers/explanations are inline below.
Best Regards, Huaimo From: mpls [mailto:[email protected]] On Behalf Of Gregory Mirsky Sent: Monday, April 13, 2015 2:58 PM To: [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slower to detect failure and perform switchover then an arbitrary local protection method. I believe that that is not the case and, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. [Huaimo] It seems that the statement in the paragraph is true. For a global protection (or an end-to-end protection), it may take more time since the time includes the propagation time and processing time. The propagation time may depend on the size of the network. In general, the bigger the network, the longer the propagation delay. The processing time may comprise the related processing time on every node along the path from the egress node to a node interesting the failure and doing switchover. o The last in Section 1.1 suggests that node R3 may detect failure of the node L1 through monitoring BFD session between two nodes. Firstly, if this is multi-hop BFD session over IP network, then there's no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that RFC 5884 may be used, I have to remind, that RFC 5884 operates between LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME) co-routed with the segment R1-L3 MUST be established. [Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-hop BFD session between R3 and L1. This current version of the document focuses on extending the protection of RFC 4090 from a transit node to an egress node. It seems that it is better to have another document for others if needed. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD select it locally and record it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is required when selecting backup egress. That is serious security concern and must be properly addressed in Security Considerations section of the draft. [Huaimo] This paragraph says that the upstream node of the primary egress knows/determines that there is not any backup egress given for the primary egress. In this case, the upstream node selects a backup egress according to a local policy. The upstream node may not need to be aware of any services or CEs. Regards, Greg
