Subject: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05

From: Gregory Mirsky <[email-masked]>
Date: Wed, 21 Mar 2012 10:56:02 -0400

Dear Authors, et al.,
Please find my questions to changes in the latest versions below.
On draft-chen-mpls-p2mp-ingress-protection-05
*       Introduction
   "The first method is a one-to-one backup method, where
   a detour backup P2P LSP for each protected P2P LSP is created at each
   potential point of local repair, which is an intermediate node
   between the ingress node and the egress node of the protected LSP."
I think that your definition excludes ingress node as PLR by saying "potential point of local repair, which is an intermediate node ...". In fact, any node, except for egress LER of course, can be PLR if a detour LSP can be created.
*       Section 4.1 "The time for switching the traffic after R1 fails is within tens of milliseconds." I don't see what supports this statement. I think that switchover depends on LOC detection by Ra and internal processing. The former, BFD interval and DetectMultiplier, i.e. operator selected configuration parameters, would determine only part of switchover performance whereas second part is implementation specific and would likely depends on number of streams Ra and R1 share.
*       Section 4.4
   "In the GMPLS networks where the control plane and data plane are
   physically separated, the detection and localization of failures in
   the physical layer can be achieved by introducing the link management
   protocol (LMP) or assisting by performance monitoring devices."
I assume you refer to MPLS-TP network in this paragraph. I think that it is not clear:
*       on which links you recommend to run LMP or PM
*       what would constitute failure particularly in case of PM being used
*       how failure detection will trigger protection switchover
*       Section 5
   "However, there is not any standard that locally
   protects the ingress of the P2MP LSP.  The ingress local protection
   mechanism described above fills this gap."
I think that the document describes redundancy, not ingress protection.

On draft-chen-mpls-p2mp-eggress-protection-05:
*       Introduction
   "The receiver selects the egress or backup egrss node for receiving
   the traffic according to the route to the source through RPF.  In a
   normal situation, it selects the egress node.  When the egress node
   fails, it selects the backup egress for receiving the traffic since
   the route to the source through the egress node is gone and the route
   to the source through the backup egress node is active."
I think that this clearly describes behavior of redundant connection to CE,1+1 redundancy. The proposed in the document is nevertheless is based on redundant connection of CE.
*       Same as for Section 4.1
*       Same as for Section 4.4
*       Same as for Section 5

        Regards,
                Greg

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 23 Mar 2012 16:11:32 +0000

See my answers inline below.

Regards,
Huaimo
________________________________
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 21, 2012 10:56 AM
To: Huaimo Chen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05

Dear Authors, et al.,
[[Chen,Huaimo]] Will be rephrased.
[[Chen,Huaimo]] This is a local protection. Backup ingress node Ra detects failures in primary ingress node R1 through using the same technical such as BFD as an intermediate node as a PLR detects failures in its next hop node for FRR. If an intermediate node can switch the traffic within tens of milliseconds after its next hop node fails, why not backup ingress Ra?
[[Chen,Huaimo]] Some details may be added.
[[Chen,Huaimo]] What are your definitions of redundancy and protection?

[[Chen,Huaimo]] Same as or similar to the answers above.

        Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 24 Mar 2012 08:46:50 -0400

Dear Huaimo, et al,
please find my notes in-lined tagged by GIM>>.

    Regards,
        Geg

________________________________
From: Huaimo Chen [mailto:[email-masked]]
Sent: Friday, March 23, 2012 9:12 AM
To: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05

Regards,
Huaimo

Dear Authors, et al.,
GIM>> Firstly, Ra would not distinguish between R1 failure and failure of the link between Ra and R1. Hence we might have false positives.
Secondly, PLR detects failure of immediate link and local protection might be of two kinds - link and node. You're not protecting link but try to protect an upstream node. This is not Local Protection per RFC 4090.
GIM>> This is very good question and I'm glad we came to its discussion (perhaps we can use some time at the meeting to it). IMO, need to differentiate between transport and service. Transport protection assumes single connection to client whereas service protection might have redundant connection (multi-homed). I think that one practical example is PW redundancy http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-06. And I'll note that case in Section 3.2.3 Single-homed CE with MS-PW redundancy can be viewed as MS-PW e2e Linear Protection.

        Regards,
                Greg

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 26 Mar 2012 22:14:58 +0000

See my answers (marked by [[Huaimo Chen]] (2nd Round):) inline below.

Regards,
Huaimo
[X]
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Saturday, March 24, 2012 8:47 AM
To: Huaimo Chen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05

Dear Huaimo, et al,

    Regards,
        Geg

[X]

Regards,
Huaimo
[X]

Dear Authors, et al.,

   *                     Introduction

[[Chen,Huaimo]] (2nd Round): A few of people mentioned this special case before; we had considered it and discussed a few of possible solutions.

[[Chen,Huaimo]] (2nd Round): RFC 4090 describes the local protection for the links and intermediate nodes of a TE LSP. It does not specify any local protection for the ingress node of a TE LSP. Thus (of course) this ingress local protection is not the local protection per RFC 4090.
The ingress LOCAL protection detects the failure of the ingress node of the TE LSP LOCALLY (i.e., the failure of the ingress node is detected by the backup ingress node one hop away) and repairs the failure of the ingress node LOCALLY. Thus if a PLR (node) can switch the traffic within tens of milliseconds after its next hop node (an intermediate node) fails, the backup ingress node (e.g., Ra) can do the same (switch the traffic within tens of milliseconds after the ingress node fails).

   *                     Section 4.4

   *                     Section 5

[[Chen,Huaimo]] (2nd Round): In this case, the question you asked here this time is similar or equivalent to the question you asked in previous IETF meetings, which is what are the differences between the PW redundancy and the ingress local protection.

There are a number of differences between the PW redundancy and the ingress local protection.
 At first, a PW and a TE LSP are different. There is a PW working group in which people work on the PW related work and there is a MPLS working group in which people work on TE LSP related work.
Secondly, a PW is not at the same level as a TE LSP. The level of a PW is higher than the level of a TE LSP.
Moreover, (more critically) the method of ingress local protection described in our draft is different from the method of PW redundancy specified in  http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-06 even though we assume that a PW and a TE LSP are the same type of tunnel (of a generic thing).

   *                     Introduction

        Regards,
                Greg