Subject: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protection

From: Gregory Mirsky <[email-masked]>
Date: Wed, 12 Feb 2014 23:26:12 +0000

Dear Authors,
I have couple comments to changes made in version 11 of the document:

*         Introduction. A statement that e2e may "provide slow fault recovery" been added. Of course, if an operator to use slower fault detection and opt for service restoration rather than protection, then fault recovery will be slow. But if we to compare apples to apples, then I find this assumption unsubstantiated and hence don't see enough motivation for the proposed solution.

*         Section 1.1 "Exactly how the failure is detected is out of scope for this document." I agree with this as long as you can demonstrate that egress failure can be detected and clearly identified specifically as egress failure in reasonable time.

Regards,
        Greg

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Feb 2014 16:31:56 +0000

Hi Greg,

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

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, February 12, 2014 6:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Mail regarding draft-chen-mpls-p2mp-egress-protection

Dear Authors,

*         Introduction. A statement that e2e may "provide slow fault recovery" been added. Of course, if an operator to use slower fault detection and opt for service restoration rather than protection, then fault recovery will be slow. But if we to compare apples to apples, then I find this assumption unsubstantiated and hence don't see enough motivation for the proposed solution.
[Huaimo:] We just compare two types of methods for protecting an egress of an LSP in section "Introduction".  One type of methods is the existing methods that are used for protecting the egress of the LSP. The other is the methods proposed in the draft for protecting the egress of the LSP.  In your comment above, you said "But if we to compare apples to apples, then I find this assumption unsubstantiated and hence don't see enough motivation for the proposed solution." .  Did you want to say "But if you compare apples to oranges, then I find this assumption unsubstantiated and hence don't see enough motivation for the proposed solution."?

*         Section 1.1 "Exactly how the failure is detected is out of scope for this document." I agree with this as long as you can demonstrate that egress failure can be detected and clearly identified specifically as egress failure in reasonable time.
[Huaimo:] It seems that a similar question is asked and answered in the MPLS mailing list.
Basically, the objective of egress protection is to make sure that the data traffic flows to its destination in the case that the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as egress failure. It seems that it is not a MUST for us to have this kind of method. As long as the data traffic flows to its destination through the use of egress protection when the egress fails or some related failures occur, it should be OK.

Regards,
        Greg