Subject: [mpls] Comment on draft-chen-mpls-p2mp-egress-protection-02

From: Greg Mirsky <[email-masked]>
Date: Mon, 21 Mar 2011 16:52:06 -0700

Dear Authors,
please kindly consider my comments and questions to the document before
upcoming IETF meeting:

   - I believe that referring to the presented use case as LSP egress
   protection is not entirely accurate. The case on the Figure 1 presents
   service protection case as it provides protection from CE perspective, not
   from perspective of LSP itself as new egress nodes/PEs being created as
   result of proposed solution
   - Much of proposed solution is based on assumption that "previous-hop
   node" is able to set up a path to a backup egress node for the given egress
   on p2mp LSP. How the mechanics of the proposed solution changes if the
   immediate upstream node can not set path to backup/redundant egress? Is it
   only the previous-hop node can set up redundant egress or any upstream node
   given that there's OAM session between it and egress node being protected?
   - Would proposed solution of creating redundant egress nodes be equally
   applicable to cases when protected egress node is a bud node?
   - I believe that section 4.3 describes proprietary implementation
   - Section 4.4 discusses OAM sessions between "previous-hop node" and
   protected edge node as well as "previous-hop node" and a CE. I assume that
   the edge node is a downstream node relative to the "previous-hop node" for
   the given p2mp LSP. If that is the case, then I'd encourage Authors to
   expand on OAM part to demonstrate what mechanisms, existing or required
   development, can be used to detect first types of failures mentioned in the
   document.
   - The second class of failures described in the Section 4.4 requires, in
   my view, interworking between service OAM and MPLS LSP OAM. I'd encourage
   Authors to expand on OAM interworking subject if the proposed solution is
   intended to address such type of failures as well
   - Section 4.4 mentions that the "previous-hop node" switches LSP traffic
   towards redundant egress nodes onto the protecting LSP after it detects or
   receives signal that the protected egress node have failed. I believe that
   it is important to address notification toward the CE otherwise switching to
   a redundant egress node would not restore the service.

I hope Authors will find it possible to address my notes before or at the
meeting itself.

Regards,
Greg

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 28 Mar 2011 22:09:07 +0000

Thanks for your comments!

See my answer inline,

Best Regards,
Huaimo

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 21, 2011 6:52 PM
To: Huaimo Chen; So, Ning; [email-masked]
Subject: Comment on draft-chen-mpls-p2mp-egress-protection-02

Dear Authors,
please kindly consider my comments and questions to the document before upcoming IETF meeting:

  *   I believe that referring to the presented use case as LSP egress protection is not entirely accurate. The case on the Figure 1 presents service  protection case as it provides protection from CE perspective, not from perspective of LSP itself as new egress nodes/PEs being created as result of proposed solution
Huaimo: Can you give more details regarding to what you mentioned "LSP egress protection is not entirely accurate"? The egress protection that is described in the draft is to protect the failure of an egress node mainly.

  *   Much of proposed solution is based on assumption that "previous-hop node" is able to set up a path to a backup egress node for the given egress on p2mp LSP. How the mechanics of the proposed solution changes if the immediate upstream node can not set path to backup/redundant egress? Is it only the previous-hop node can set up redundant egress or any upstream node given that there's OAM session between it and egress node being protected?
Huaimo: In the case of that the immediate upstream node of an egress node can not set up a protecting LSP to backup/redundant egress, the protection to the egress node can not be provided or may be transferred to the previous (previous) hop node (we considered this). To allow any previous hop of an egress node to provide protection to the egress node may be complicated.

  *   Would proposed solution of creating redundant egress nodes be equally applicable to cases when protected egress node is a bud node?
Huaimo: Why not?

  *   I believe that section 4.3 describes proprietary implementation
Huaimo: This is just for information.

  *   Section 4.4 discusses OAM sessions between "previous-hop node" and protected edge node as well as "previous-hop node" and a CE. I assume that the edge node is a downstream node relative to the "previous-hop node" for the given p2mp LSP. If that is the case, then I'd encourage Authors to expand on OAM part to demonstrate what mechanisms, existing or required development, can be used to detect first types of failures mentioned in the document.
Huaimo: We may consider this.

  *   The second class of failures described in the Section 4.4 requires, in my view, interworking between service OAM and MPLS LSP OAM. I'd encourage Authors to expand on OAM interworking subject if the proposed solution is intended to address such type of failures as well
Huaimo: We may consider this.

  *   Section 4.4 mentions that the "previous-hop node" switches LSP traffic towards redundant egress nodes onto the protecting LSP after it detects or receives signal that the protected egress node have failed. I believe that it is important to address notification toward the CE otherwise switching to a redundant egress node would not restore the service.
Huaimo: Regarding to the service on the backup egress node, we have had some discussions and considerations. We may write more details in the draft. The backup egress node should have the information about the service on the egress node. It should forward the traffic coming from the protecting LSP in a way which is the same as or similar to the way that the egress does.

I hope Authors will find it possible to address my notes before or at the meeting itself.

Regards,
Greg