Subject: Re: [mpls] Comments on draft-cheung-mpls-tp-mesh-protection-00

From: "Cheung Tae Sik" <[email-masked]>
Date: Tue, 23 Mar 2010 14:28:03 +0900

Dear Greg,

Thank you for valuable comments.

Followings are our responses.

1. Fiugre 1 shows the simplest form of mesh topology. It was included in the document to help understanding the mesh topology and to illustrate Shared Start Node and Shared End Node. In a later version, we will consider to remove it.

2 . In this version, Shared Start and End Nodes are simply defined as "the first and last node of shared protection segment". clearer definitions and desciptions on their roles will be added in the next version. If you have any suggestion, please let us know.

Regards,

Taesik

-----원본 메시지-----
From: "Greg Mirsky" <[email-masked]>
From Date: 2010-03-23 오전 7:46:31
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: Comments on draft-cheung-mpls-tp-mesh-protection-00

Dear Authors,
please find my comments to the document below:

Figure 1 and Figure 2 present very similar topologies. Further in the document, only topology displayed in Figure 2 is being used to illustrate various mesh protection scenarios. Perhaps Figure 1 might be viewed as less informative in the document.

Section 3.2 introduces Shared Start and Shared End Nodes. A node must be aware of its role as termination point of a shared protection segment (that is important in PSC interaction). The role can be assigned by NMS or self-deduced if the Control Plane is used. I think that the formal definition of Shared End Node is required in the document so that node can determine its role in a given shared protection segment.

Regards,
Greg Mirsky

---

From: Biao Lu <[email-masked]>
Date: Fri, 26 Mar 2010 10:21:17 -0700

Taesik:

My comments for the draft:

1.       Operation of mesh protection: how much 1:N linear protection messaging can be reused. Should do an evaluation of linear protection and what need to be extended to support shared mesh protection

2.       Messaging reliability: not sure if this is addressed in mpls-tp in general, how to handle loss of messages (i.e. Protection State Change Notification)

3.       Planning: I think planning should be separated from this draft.

4.       Section 3.3 Figure 3:
I don’t think that you want to do the bridge from Q to A and G since the traffic is from different source. So the direction from Q to A and G should be separate Label (most likely the case) or a selector if the same label is used on R->Q for the two protections LSPs.

Regards,
Biao Lu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cheung Tae Sik
Sent: Monday, March 22, 2010 10:28 PM
To: Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-cheung-mpls-tp-mesh-protection-00

Dear Greg,

Regards,
Taesik

-----원본 메시지-----
From: "Greg Mirsky" <[email-masked]>
From Date: 2010-03-23 오전 7:46:31
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: Comments on draft-cheung-mpls-tp-mesh-protection-00

Dear Authors,

 *   Figure 1 and Figure 2 present very similar topologies. Further in the document, only topology displayed in Figure 2 is being used to illustrate various mesh protection scenarios. Perhaps Figure 1 might be viewed as less informative in the document.
 *   Section 3.2 introduces Shared Start and Shared End Nodes. A node must be aware of its role as termination point of a shared protection segment (that is important in PSC interaction). The role can be assigned by NMS or self-deduced if the Control Plane is used. I think that the formal definition of Shared End Node is required in the document so that node can determine its role in a given shared protection segment.
Regards,
Greg Mirsky

---

From: 정태식 <[email-masked]>
Date: Mon, 29 Mar 2010 17:53:50 +0900

Dear Biao,

Thank you for the comments.

Please see my responses inline.

Regards,

Taesik

From: Biao Lu [mailto:[email-masked]] 
Sent: Saturday, March 27, 2010 2:21 AM
To: 정태식; Greg Mirsky; 류정동; [email-masked]; [email-masked]
Subject: RE: Comments on draft-cheung-mpls-tp-mesh-protection-00

Taesik:

[Taesik] Our mesh protection mechanism is independent of linear protection mechanism. For one protection domain (which is for 1:1 or 1:n), they can use any protocol to achieve the linear protection switching in their own protection domain. Our mesh protection is for multiple of such a protection domain. No modification would be required in the 1:1 or 1:n protection mechanism.

[Taesik]  It was described in Section 4.1 of draft-ietf-mpls-tp-linear-protection. It is a general PSC messaging principle, so it can also be applied for our case.

[Taesik] Yes, mesh protection planning is out of scope of this draft. Section 3.4 is just informative.

4.       Section 3.3 Figure 3: 

[Taesik] The terms bridge and selector were used just considering signal direction. And in the second example of Figure 3, extra traffic should be incorporated. I’ll refine the figure in next version.

Regards,

Biao Lu

Dear Greg,

Regards,

Taesik

-----원본 메시지-----
From: "Greg Mirsky" <[email-masked]>
From Date: 2010-03-23 오전 7:46:31
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 
Subject: Comments on draft-cheung-mpls-tp-mesh-protection-00

Dear Authors,

Regards,
Greg Mirsky