Subject: [mpls] comments on draft-chen-mpls-p2mp-ingress-protection

From: Yimin Shen <[email-masked]>
Date: Fri, 23 Mar 2012 13:20:07 -0400

Authors,

I have following comments for this draft.

The draft allows a primary ingress router to send an "LSP info" message to a backup ingress to set up a backup p2mp LSP. This message defines the leaf nodes and the set of must-traverse intermediate nodes (i.e. the set of 1st hops of the primary p2mp LSP) for the backup p2mp LSP.

[1] Security

The creation of backup p2mp LSP is purely based on an external message. Security must be addressed.

It is unclear in the draft whether a primary ingress and a backup ingress must be one hop away from each other, or may be multi hops away.

[2] P2P LSPs

If the mechanism can apply to p2p LSPs, as claimed, it needs to be addressed in detail.

[3] CSPF

It assumes that the backup ingress can do path computation, e.g. CSPF. What if it cannot? This would affect applicability.

[4] Debuggability

Once a the primary ingress has sent a "LSP info" message to a backup ingress, there is no way for the primary ingress to learn the existence or success/failure/error state of the backup P2MP LSP.

There needs to be some mechanism, such as notification to primary ingress, to facilitate trouble shooting.

[5] No explicit teardown message

Please consider an explicit teardown message that a primary ingress can send to tear down the backup LSP. Time-out based mechanism may be too slow.

[6] Merge point behavior

Detail about merge point behavior:
How to distinguish primary LSP and backup LSP;
How to handle and propagate ResvTear and PathErr received from downstream;

Thanks,

-Yimin Shen

Juniper Networks

Thanks,

-Yimin

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 23 Mar 2012 20:04:33 +0000

See my answers inline below.

Regards,
Huaimo
________________________________
From: Yimin Shen [mailto:[email-masked]]
Sent: Friday, March 23, 2012 1:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-chen-mpls-p2mp-ingress-protection

Authors,

[1] Security

[[Chen,Huaimo]] The primary ingress node and the backup ingress node are in the same trusted network. Normally the backup ingress node is directly connected to the primary ingress node. The LSP info message that the backup ingress node receives is from the primary ingress node, which is in the same trusted network as the backup ingress node. It seems that there is not any security issue in this case.

[[Chen,Huaimo]] The primary ingress node should be directly connected to the backup ingress node. That is that the primary ingress node and the backup ingress node should be one hop away.

[2] P2P LSPs

[[Chen,Huaimo]] Some details may be added in the next version.

[3] CSPF

[[Chen,Huaimo]] If the backup ingress node can not do CSPF, it should have a way to get a path. For example, PCE may be used to compute the path. In a normal situation, how does a router without CSPF capability get a protection path satisfying a given set of constraints?

[4] Debuggability

[[Chen,Huaimo]]This will be considered.

[[Chen,Huaimo]] It seems that time is critical here.

[6] Merge point behavior

[[Chen,Huaimo]] Some details may be added in the next version.

Thanks,

-Yimin Shen

Juniper Networks

Thanks,

-Yimin

---

From: Yimin Shen <[email-masked]>
Date: Tue, 27 Mar 2012 10:26:50 -0400

Huaimo,

The following items from your clarification for my comment [1] and [3] may impact the applicability of the draft.

-    The primary ingress node should be directly connected to the backup ingress node. That is that the primary ingress node and the backup ingress node should be one hop away.

-    If the backup ingress node can not do CSPF, it should have a way to get a path. For example, PCE may be used to compute the path. In a normal situation, how does a router without CSPF capability get a protection path satisfying a given set of constraints?

Two more comments:

[7] TE constraints for CSPF on backup ingress PE

Are the TE constraints used by a backup ingress PE for CSPF same or different than those used by the primary ingress PE?

Either case, how does a backup ingress PE know about the TE constraints ? The "LSP info" message is basically a copy of Path message of the primary P2MP LSP, and it contains only bandwidth info. What about other TE constraints that the backup PE must consider ?

[8] Reversion

Please describe all possible revertive modes. I have the following concern, as the reversion would be driven by the two PEs, rather than a single CE.

When the primary ingress PE is restored, it will make an independent decision to start forwarding traffic again over the primary P2MP LSP. Likewise, the backup ingress PE will detect the active state of the primary PE and make an independent decision to stop forwarding traffic. It seems unavoidable that there would be a window where both PEs are forwarding traffic at the same time. This would generate duplicate traffic in the network. How do you handle such kind of scenario ?

Thanks,

-Yimin Shen

Juniper Networks

From: Huaimo Chen [mailto:[email-masked]]
Sent: Friday, March 23, 2012 4:05 PM
To: Yimin Shen; [email-masked]
Cc: [email-masked]
Subject: RE: comments on draft-chen-mpls-p2mp-ingress-protection

Regards,
Huaimo

Authors,

[1] Security

[2] P2P LSPs

[3] CSPF

[4] Debuggability

[6] Merge point behavior

Thanks,

-Yimin Shen

Juniper Networks

Thanks,

-Yimin