Re: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

[Gregory Mirsky <[e-mail]>]

Hi Huaimo, et. al,
apologies for such very late response. I've read the -02 version and below you'll find my notes to changes I've found. My responses to our discussion are in-line and tagged GIM>>.
Notes to -02 version:

*         section 5.1 states
   A backup egress SHOULD be configured on the ingress of an LSP to
   protect a primary egress of the LSP.
Are there scenario when this SHOULD NOT be done, when the backup egress(es) are not configured?
And if this is such strong requirement, then the same is applicable to the next sentence that currently reads as "...optional egress backup descriptor list for protecting egresses of the LSP". I think that the descriptor list SHOULD be included in the Path message by the ingress.

*         section 5.2 states:
   If the transit node is the upstream node of a primary egress to be
   protected, it determines the backup egress, obtains a path for the
   backup LSP and sets up the backup LSP along the path.
Which, in my view, contradicts with the statement in section 5.1 that backup egress(es) SHOULD be configured at LSP ingress.



                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Monday, April 13, 2015 8:19 PM
To: Gregory Mirsky; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

Hi Greg,

Thanks for your comments.
My answers/explanations are inline below.

Best Regards,
Huaimo
From: mpls [mailto:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.
GIM>> I think that distance, whether in number of intermediate hops or miles, does not affect guaranteed defect detection time when continuity check protocol being used. In that case detection time depends only on definition of Loss of Continuity defect for the given protocol. For example, in CFM it is period of time between 3.25 and 3.5 CCM intervals when no CCM received from remote MEP. BFD is little different and DetectMultiplier can be negotiated between end points of the given BFD session. But regardless of these differences, using CFM or BFD enables detection of LoC defect within 10 ms regardless of the distance between end-points.

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.
GIM>> I couldn't find in the document statement that the PLR R3 MUST be upstream to the egress. If this is the requirement, then it must be explicitly stated as, in my view, it is restrictive and limits number of networks where proposed method can be used.

*         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.
GIM>> As commented above to section 5.2, this contradicts statement made in section 5.1 that backup egress(es) SHOULD be configured at LSP ingress.


Regards,
                Greg