Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 1 Oct 2012 07:55:28 +0000

Hi Jia,

Could you please elaborate your commnent? Which deficiencies are you talking about?

BR
Daniele 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Hejia
>Sent: sabato 29 settembre 2012 12.53
>To: Loa Andersson
>Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc 
>team; [email-masked]
>Subject: Re: [mpls] Working group last call on 
>draft-ietf-mpls-tp-ring-protection
>
>Do not support.
>
>Based on the analysis in Section 2.4 of 
>draft-ietf-mpls-tp-ring-protection-02, the ring protection 
>scheme using SPME as described, either wrapping or steering, 
>does have deficiencies, which IMHO should be better 
>reconsidered and solved if possible.
>
>
>B.R.
>Jia
>
>-----邮件原件-----
>发件人: [email-masked] [mailto:[email-masked]] 代表 
>Loa Andersson
>发送时间: 2012年9月19日 18:49
>抄送: [email-masked]; MPLS-TP ad hoc team; 
>[email-masked]; 
>[email-masked]
>主题: [mpls] Working group last call on 
>draft-ietf-mpls-tp-ring-protection
>
>Working Group,
>
>this is to start a two week working group last call on 
>draft-ietf-mpls-tp-ring-protection-02-txt.
>
>Please note that there are two IPR disclosures # 1462 and  # 
>1872 related to this document.
>
>Please send your comments to the mpls working group mailing 
>lists ([email-masked]).
>
>The working group last call ends October 3, 2012.
>
>/Loa
>for the mpls wg co-chairs
>
>
>-- 
>
>
>Loa Andersson                         email: [email-masked]
>Sr Strategy and Standards Manager            [email-masked]
>Ericsson Inc                          phone: +46 10 717 52 13
>                                              +46 767 72 92 13 
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 1 Oct 2012 14:27:01 +0200

Do not support

According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution.
It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654.

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro Gerardo D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
([email-masked]).

/Loa

--

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 1 Oct 2012 11:53:25 -0400

Dear Authors, Editors, WG Chairs, et al.,
Please find my comments to the document below:
*       Section 2.1
*       Verbal explanation of the wrapping in the first paragraph might benefit if LSRs be referenced as in Figure 1.
*       As described, wrapping can provide local protection of bi-directional co-routed LSP only in case of link failure. If node protection requested, as mentioned in the third sentence of the first para, MP is not the downstream LSR but next down to downstream. If we expect that PLR in forward direction is MP in reverse direction of given bi-directional LSP, then we have case of segment, not local protection. (Same, I believe, applies to FRR of bi-directional co-routed p2p LSP).
*       s/arounf/around/
*       Figure 1 I think that this figure illustrates wrapping of a single direction in case of local link protection. If that is the intention, then caption might explicitly state that. If a case of a bi-directional LSP to be illustrated for local link protection, then another wrapped data path F-E-D-C-B-A might be added.
*       "If protecting both the links and the nodes of a LSP, then, for a ring with N nodes, there is a need for O(2N) alternate paths." I assume that this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP implies coordinated protection which, as mentined before, can not be achieved for node protection with local protection. Coordinated node protection, if not end-to-end, can be in form of segment protection.
*       Section 2.2
*       "The process of notifying the ingress node adds to the latency of the protection switching process, after the detection of the fault condition." I think that that is not necessarily true as ingress notification doesn't have to be explicit but can be implicit if e2e CC/CV monitors working and protecting paths.
*       Very last para "... there is the necessity for the ring to maintain enough capacity for all of the data in both directions around the ring" seems as too strong requirement considering cases of 1:N linear and shared mesh protection, where bandwidth of a protection path shared.
*       Section 2.3
*       "... since we will perform all of the OAM functionality on the SPME configured for the traffic, we can minimize the number of OAM sessions needed to monitor the data traffic of the ring - rather than monitoring each individual LSP." Such improvement in OAM scale doesn't come for free as SPME OAM might introduce or hide connectivity and/or continuity defects of enclosed LSPs.
*       "In all of the following subsections, we use 1:1 linear protection [SurvivFwk] [LinProtect] to perform protection switching and coordination when a signal fault is detected." For 1:1 linear protection scope of the RFC 6378 is limited to bi-directional p2p MPLS-TP constructs. "Applicability of the protocol for 1:1 unidirectional protection and for 1:n protection schemes may be documented in a future document and is out of scope for this document", stated in section 1.2. Thus use of PSC for unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned and reflected in change of the scope of the document.
*       Section 2.3.1
*       First para "... each one acts as the ingress and egress in one direction of the bidirectional SPME". I think that terminology "ingress/egress MEP" is not the best and perhaps view of nodal MEP per LSP is sufficient, so that no need to split MEP on given LSP per direction.
*       Section 2.3.2
*       I think that title of the section needs to say explicitly that link protection by wrapping is discussed in the section (node protection in the 2.3.3)
*       Section 2.3.3
*       As mentioned, in case of bi-directional co-routed LSP to which node protection required (Figure 4) SPME approach is, effectively, segment, not local protection. SPME level OAM between LSR A and LSR E monitors not only link between LSR A and LSR F and LSR F but link between LSR F and LSR E as well (from LSP POV). The primary SPME, effectively, changes ring topology by excluding LSR F from topology as LSR F would not be processing LSP's outer label but process only SPME's outer label.
*       Section 2.3.4
*       Local node protection monitors immediate link for link as well as node protection. The difference between these protection modes in selection of a MP, whether immediate neighbor can (link protection) or can not (node protection) be used as MP. The section seems based on misunderstanding of difference between local link and node protection and might be removed.
*       Section 2.4
*       s/steeing/steering/
*       What are three OAM sessions that each ring node will have if wrapping used to protect the ring? I see two OAM sessions: immediate link to downstream LSR; around ring to the same LSR. Where the third OAM session?
*       "Special consideration" seems as unfounded:
*       Not clear why CC/CV OAM in case of SPME steering viewed as insufficient for fast defect detection.
*       Local node and link protection are not mutualy exclusive. Local node protection provides link protection as part of node protection. The problem, from my POV, is that bi-directional co-routed LSP can not have local node protection but only segment protection.
*       Section 3
*       As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear protection of unidirectional MPLS-TP constructs, including unidirectional p2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs. What mechanism(s) could be used to perform defect detection, coordination and protections switchover?
*       Section 4
*       As as stated in RFC 6378 "Applicability of the protocol [PSC, my note] for 1:1 unidirectional protection and for 1:n protection schemes may be documented in a future document and is out of scope for this document".
A note on textual conventions:
*       References are both direct RFC, e.g. [RFC4090], and content-based, i.e. [TPReqs]. May consider choosing single style of referencing.

Thank you for your kind consideration.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3:49 AM
Cc: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872 related to this document.

Please send your comments to the mpls working group mailing lists ([email-masked]).

/Loa

--

                                              +46 767 72 92 13 _______________________________________________

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 2 Oct 2012 08:39:19 +0000

+1

________________________________
보낸 사람 : "D'Alessandro Alessandro Gerardo" <[email-masked]>
보낸 날짜 : 2012-10-01 21:38:58 ( +09:00 )
받는 사람 : Loa Andersson <[email-masked]>
참조 : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, MPLS-TP ad hoc team <[email-masked]>, [email-masked] <[email-masked]>
제목 : [AHMPLS-TP] R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Cavazzoni Carlo <[email-masked]>
Date: Tue, 2 Oct 2012 10:57:41 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: lunedì 1 ottobre 2012 14:27
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 02 Oct 2012 11:02:56 +0200

Do not support.

Same reasons as mentioned below.

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Di Giglio Andrea <[email-masked]>
Date: Tue, 2 Oct 2012 11:51:11 +0200

+1

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Cavazzoni Carlo
Inviato: martedì 2 ottobre 2012 10:58
A: D'Alessandro Alessandro Gerardo; Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: lunedì 1 ottobre 2012 14:27
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Oct 2012 11:04:53 +0100

Alessandro,  Di Giglio, Huub,

Please could you be more precise by specifying the optimizations
that you believe are achievable.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Larry <[email-masked]>
Date: Tue, 2 Oct 2012 18:41:28 +0800 (CST)

not support!
It doesn't satisfy some requirements of the operators. The configuration is too complex and needs too many labels and OAM sessions. There are risks that protection switch time exceed 50ms.

*************************************************************************
Han Li, Ph.D 
China Mobile Research Institute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China 
Fax: +86 10 63135159 
MOBILE: 13501093385 
*************************************************************************

--- 12年10月2日，周二, Huub van Helvoort <[email-masked]> 写道：

> 发件人: Huub van Helvoort <[email-masked]>
> 主题: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection
> 收件人: "D'Alessandro Alessandro Gerardo" <[email-masked]>
> 抄送: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "MPLS-TP ad hoc team" <[email-masked]>, "[email-masked]" <[email-masked]>
> 日期: 2012年10月2日,周二,下午5:02
> Do not support.
> 
> > According to the optimization criteria for ring
> protection specified in Section 2.5.6.1 in RFC5654, the
> MPLS-TP ring protection should be optimized for
> simplification of the ring operation and the resources
> consumption around the ring. It is not the case of the
> proposed solution.
> > It is actually simply an applicability statement of a
> linear protection mechanism but it cannot be consider a
> solution that addresses the requirements for protection of
> ring topologies for Multi-Protocol Label Switching Transport
> Profile (MPLS-TP) as specified in RFC5654.
> >
> > Best regards,
> > Alessandro
> >
> >
> > Da: [email-masked]
> [mailto:[email-masked]]
> Per conto di Hejia
> > Cc: [email-masked]; [email-masked];
> MPLS-TP ad hoc team; [email-masked]
> > 发件人: [email-masked]
> [mailto:[email-masked]]
> 代表 Loa Andersson
> > 发送时间: 2012年9月19日 18:49
> > 抄送: [email-masked];
> MPLS-TP ad hoc team; [email-masked];
>              email:
> [email-masked]
> > Ericsson Inc           
>               phone: +46
> 10 717 52 13
>                 +46
> 767 72 92 13

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Oct 2012 16:04:21 +0200

Alessandro and others that supported the below,
Your statement below does not provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed.....
Hence it is impossible to refer to or consider such LC comment as such, unless you provide technical arguments that we can discuss and consider. 
Best regards,
Nurit

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Eric Gray <[email-masked]>
Date: Tue, 2 Oct 2012 10:09:43 -0400

Forwarded...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi All,

I think we should address all the issues that ITU liaison mentioned.

BR,
Jian

             Loa Andersson                                                 
             <[email-masked]>                                                   
             发件人:                                                收件人 
             mpls-bounces@i                                                
             etf.org                                                  抄送 
                                    "[email-masked]" <[email-masked]>,       
                                    MPLS-TP ad hoc team                    
             2012-09-19             <[email-masked]>,             
             18:48                  draft-ietf-mpls-tp-ring-protection@too 
                                    ls.ietf.org,                           
                                    "[email-masked]"           
                                    <[email-masked]>           
                                                                      主题 
                                    [mpls] Working group last call on      
                                    draft-ietf-mpls-tp-ring-protection     

                                                                           

Working Group,

/Loa

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Oct 2012 16:50:17 +0200

Dear Han Li,
Thanks for your comment. 
·         Can you please explain why do you think there are risks that protection switch time exceeds 50ms ("from the moment of fault detection in a         network with a 16-node ring with less than 1200 km of fiber" as required in RFC 5654)? What in the proposed solution make you think there are risks? 
·         Can you please indicate why do you think the configuration is too complex and why it requires too many labels and OAM sessions...and how do you think this could be better optimized? 
In order to refer to this as a LC comment, the technical arguments should be presented and elaborated. 
Thanks and best regards,
Nurit
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Larry
Sent: Tuesday, October 02, 2012 12:41 PM
To: D'Alessandro Alessandro Gerardo; [email-masked]
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection
 
not support!

--- 12年10月2日，周二, Huub van Helvoort <[email-masked] <mailto:[email-masked]> > 写道：
 
> 发件人: Huub van Helvoort <[email-masked] <mailto:[email-masked]> >
> 收件人: "D'Alessandro Alessandro Gerardo" <[email-masked] <mailto:[email-masked]> >
> 抄送: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "MPLS-TP ad hoc team" <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
> 日期: 2012年10月2日,周二,下午5:02
> Do not support.
> 
> > Da: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ]
> Per conto di Hejia
> > Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;
> MPLS-TP ad hoc team; [email-masked] <mailto:[email-masked]> 
> > 发件人: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ]
> 代表 Loa Andersson
> > 发送时间: 2012年9月19日 18:49
> > 抄送: [email-masked] <mailto:[email-masked]> ;
> MPLS-TP ad hoc team; [email-masked] <mailto:[email-masked]> ;
> [email-masked] <mailto:[email-masked]> 
> > ([email-masked] <mailto:[email-masked]> ).
> >
> [email-masked] <mailto:[email-masked]> 
> > Sr Strategy and Standards Manager     
>       [email-masked] <mailto:[email-masked]> 
> > Ericsson Inc           
>               phone: +46
> 10 717 52 13
> >               
>                
>                 +46
> 767 72 92 13
> > [email-masked] <mailto:[email-masked]> 
> > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls> 
> > [email-masked] <mailto:[email-masked]> 
> > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls> 
> 
> -- 
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls> 
> 
_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Oct 2012 16:51:23 +0200

Did I miss any liaison on this?
To what issue do you refer?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Eric Gray
Sent: Tuesday, October 02, 2012 4:10 PM
To: [email-masked]
Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection

Forwarded...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi All,

BR,
Jian

             Loa Andersson                                                 
             <[email-masked]>                                                   
             发件人:                                                收件人 
             mpls-bounces@i                                                
             etf.org                                                  抄送 

                                                                           

Working Group,

/Loa

--

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Tue, 2 Oct 2012 16:57:31 +0200

The optimizations I refer are described in RFC5654, Section 2.5.6.1, among the other in the paragraph that start as " Within the context of recovery in MPLS-TP networks, the optimization criteria considered in ring topologies are as follows ...."

Best regards,
Alessandro

-----Messaggio originale-----
Da: Stewart Bryant [mailto:[email-masked]] 
Inviato: martedì 2 ottobre 2012 12:05
A: Di Giglio Andrea
Cc: Cavazzoni Carlo; D'Alessandro Alessandro Gerardo; Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: R: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Stewart

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Tue, 2 Oct 2012 17:10:23 +0200

Dear Nurit, 
There are many points we can discuss about the proposed draft but let me point out initially just R100, RFC5654.

Best regards,
Alessandro

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: [email-masked]
Date: Tue, 2 Oct 2012 12:46:44 -0400

I expect that this liaison will be posted in the next few days.

ITU members can find the liaison as Annex I of TD744/PLEN.

Regards,

Malcolm

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
Sent by: [email-masked]
02/10/2012 10:51 AM

To
<[email-masked]>
cc

Subject
Re: [mpls] FW: Working group last call on 
draft-ietf-mpls-tp-ring-protection

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
ext Eric Gray
Sent: Tuesday, October 02, 2012 4:10 PM
To: [email-masked]
Subject: [mpls] FW: Working group last call on 
draft-ietf-mpls-tp-ring-protection

Forwarded...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: [mpls] Working group last call on 
draft-ietf-mpls-tp-ring-protection

Hi All,

BR,
Jian

             Loa Andersson 
             <[email-masked]> 
             发件人:                                                收件人 

             mpls-bounces@i 
             etf.org                                                  抄送 

                                    ls.ietf.org, 

 

Working Group,

Please note that there are two IPR disclosures # 1462 and  # 1872 related 
to this document.

/Loa

--

---

From: [email-masked]
Date: Tue, 2 Oct 2012 12:51:38 -0400

Do not support.

All of the issues identified in the liaison statement from the September 
2012 meeting of SG15 must be addressed.

Regards,

Malcolm

Loa Andersson <[email-masked]> 
Sent by: [email-masked]
19/09/2012 06:48 AM

To

cc
"[email-masked]" <[email-masked]>, MPLS-TP ad hoc team 
<[email-masked]>, 
[email-masked], 
"[email-masked]" <[email-masked]>
Subject
[mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Oct 2012 18:11:18 +0100

The text in 100 says:

"100  Recovery techniques in a ring SHOULD be identical (or as similar
       as possible) to those in general transport networks to simplify
       implementation and operations.  However, this MUST NOT override
       any other requirement."

The MUST is that all other requirements MUST be met, and the SHOULD
is that the solution SHOULD be those in general transport networks,
which is actually is not a ring specific statement. Indeed by
reusing the mesh approach (RFC6378) we comply with that requirement
since the mesh solution are by definition "identical to those in
general transport networks".

A more productive review approach might be to point to an IETF
draft that proposes an alternative solution and provide a point
by point evaluation of how well each solution addresses the numbered
requirements 92..109.

Stewart (as an individual contributor)

On 02/10/2012 16:10, D'Alessandro Alessandro Gerardo wrote:
> .

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Oct 2012 19:12:17 +0200

Dear Alesandro,
Thank you for pointing to R.100 ("Recovery techniques in a ring SHOULD be identical (or as similar
        as possible) to those in general transport networks to simplify
        implementation and operations.  However, this MUST NOT override
        any other requirement."). 
draft-ietf-mpls-tp-ring-protection supports the two protection architecture mechanisms for ring topologies, based on SDH specifications [G.841], that have been proposed in various forums to perform recovery of a topological ring network - "wrapping" and "steering". 
So it will be good to understand better your technical concern on R100. 
Best regards,
Nurit

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2012 5:10 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Dear Nurit, 

Best regards,
Alessandro

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Oct 2012 19:13:42 +0200

Thank you Malcolm!
Obviously it is impossible to consider something that was not posted. 
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, October 02, 2012 6:47 PM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection

Regards, 

Malcolm 

Subject
Re: [mpls] FW: Working group last call on        draft-ietf-mpls-tp-ring-protection

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of ext Eric Gray
Sent: Tuesday, October 02, 2012 4:10 PM
To: [email-masked]
Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection

Forwarded...

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi All,

BR,
Jian

            Loa Andersson                                                 
            <[email-masked]>                                                   
            发件人:                                                收件人 
            mpls-bounces@i                                                
            etf.org                                                  抄送 

                                                                          

Working Group,

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Oct 2012 18:18:04 +0100

Malcolm

There is no liaison statement posted, so that we can have a productive 
discussion, please can you cut and paste the substantive text and send 
it as an email to this list.

On 02/10/2012 17:51, [email-masked] wrote:
> Do not support.
>
> All of the issues identified in the liaison statement from the 
> September 2012 meeting of SG15 must be addressed.
>
> Regards,
>
> Malcolm
>
>
>
> *Loa Andersson <[email-masked]>*

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 2 Oct 2012 21:19:05 +0000

With chair hat on!

A WG last call is not at all like a call for workgroup adoption.  It is a time to point out and discuss specific issues with a draft.  The object is to fix the draft so that WG consensus can be achieved to move it forward.

If there are valid deficiencies, these need to be openly discussed and then addressed by the authors.  If the WG consensus is that there are deficiencies and that the authors have failed to address them then we would not have consensus.

A +1, statement of "Support" or "Do not support" is neither appropriate nor helpful in a WG last call.  Neither are general positive or negative comments.

Please be very specific in describing any issues that you have with the draft.

///George

From: <Ryoo>, Jeong-dong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 2, 2012 4:39 AM
To: D'Alessandro Alessandro Gerardo <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, MPLS-TP ad hoc team <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] 회신: Working group last call on draft-ietf-mpls-tp-ring-protection

+1

________________________________
보낸 사람 : "D'Alessandro Alessandro Gerardo" <[email-masked]<mailto:[email-masked]>>
보낸 날짜 : 2012-10-01 21:38:58 ( +09:00 )
받는 사람 : Loa Andersson <[email-masked]<mailto:[email-masked]>>
참조 : [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, MPLS-TP ad hoc team <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
제목 : [AHMPLS-TP] R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

Please send your comments to the mpls working group mailing lists
([email-masked]<mailto:[email-masked]>).

/Loa

--

Loa Andersson email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager [email-masked]<mailto:[email-masked]>
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Larry <[email-masked]>
Date: Wed, 3 Oct 2012 08:58:39 +0800 (CST)

Dear Nurit:
       China Mobile presented several contributions about ring protection in last ITU-T SG15 plenary meeting. We compared the complexity and resources requirement (labels and OAM sessions) of different schemes. After discussion, we summerized the requirements in the liason to IETF. Thank you!
Best regards,
                             Han Li

Han Li, Ph.D 

Fax: +86 10 63135159 

MOBILE: 13501093385 

--- 12年10月2日，周二, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]> 写道：

发件人: Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]>
主题: RE: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection
收件人: "ext Larry" <[email-masked]>, "D'Alessandro Alessandro Gerardo" <[email-masked]>, [email-masked]
抄送: [email-masked], [email-masked], "MPLS-TP ad hoc team" <[email-masked]>, [email-masked]
日期: 2012年10月2日,周二,下午10:50

Dear Han Li,Thanks for your comment. ·         Can you please explain why do you think there are risks that protection switch time exceeds 50ms ("from the moment of fault detection in a         network with a 16-node ring with less than 1200 km of fiber" as required in RFC 5654)? What in the proposed solution make you think there are risks? ·         Can you please indicate why do you think the configuration is too complex and why it requires too many labels and OAM sessions...and how do you think this could be better optimized? In order to refer to this as a LC comment, the technical arguments should be presented and elaborated. Thanks and best regards,Nurit  -----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Larry
Sent: Tuesday, October 02, 2012 12:41 PM
To: D'Alessandro Alessandro Gerardo; [email-masked]
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection  not support!It doesn't satisfy some requirements of the operators. The configuration is too complex and needs too many labels and OAM sessions. There are risks that protection switch time exceed 50ms.  *************************************************************************Han Li, Ph.D China Mobile Research Institute32 Xuanwumen West Street, Xicheng District, Beijing 100053, China Fax: +86 10 63135159 MOBILE: 13501093385 *************************************************************************    --- 12年10月2日，周二, Huub van Helvoort <[email-masked]> 写道：  > 发件人: Huub van Helvoort <[email-masked]>> 主题: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection> 收件人: "D'Alessandro Alessandro Gerardo" <[email-masked]>> 抄送: "[email-masked]" <[email-masked]>,
 "[email-masked]" <[email-masked]>, "MPLS-TP ad hoc team" <[email-masked]>, "[email-masked]" <[email-masked]>> 日期: 2012年10月2日,周二,下午5:02> Do not support.> > Same reasons as mentioned below.> > Regards, Huub.> > On 01-10-12 14:27, D'Alessandro Alessandro Gerardo wrote:> > Do not support> >> > According to the optimization criteria for ring> protection specified in Section 2.5.6.1 in RFC5654, the> MPLS-TP ring protection should be optimized for> simplification of the ring operation and the resources> consumption around the ring. It is not the case of the> proposed solution.> > It is actually simply an applicability statement of a> linear protection mechanism but it cannot be consider a> solution that addresses the requirements for protection of> ring topologies for Multi-Protocol Label Switching Transport> Profile (MPLS-TP) as specified
 in RFC5654.> >> > Best regards,> > Alessandro> >> >> ------------------------------------------------------------------> > Telecom Italia> > Alessandro Gerardo D'Alessandro> > Transport Innovation> > Via Reiss Romoli, 274 - 10148 Torino> > phone:  +39 011 228 5887> > mobile: +39 335 766 9607> > fax: +39 06 418 639 07> >> >> > -----Messaggio originale-----> > Da: [email-masked]> [mailto:[email-masked]]> Per conto di Hejia> > Inviato: sabato 29 settembre 2012 12:53> > A: Loa Andersson> > Cc: [email-masked]; [email-masked];> MPLS-TP ad hoc team; [email-masked]> > Oggetto: Re: [mpls] Working group last call on> draft-ietf-mpls-tp-ring-protection> >> > Do not support.> >> > Based on the analysis in Section 2.4 of> draft-ietf-mpls-tp-ring-protection-02, the ring protection> scheme using SPME as described, either wrapping or steering,> does have deficiencies, which IMHO should be better> reconsidered
 and solved if possible.> >> >> > B.R.> > Jia> >> > -----邮件原件-----> > 发件人: [email-masked]> [mailto:[email-masked]]> 代表 Loa Andersson> > 发送时间: 2012年9月19日 18:49> > 抄送: [email-masked];> MPLS-TP ad hoc team; [email-masked];> [email-masked]> > 主题: [mpls] Working group last call on> draft-ietf-mpls-tp-ring-protection> >> > Working Group,> >> > this is to start a two week working group last call on> > draft-ietf-mpls-tp-ring-protection-02-txt.> >> > Please note that there are two IPR disclosures # 1462> and  # 1872> > related to this document.> >> > Please send your comments to the mpls working group> mailing lists> > ([email-masked]).> >> > The working group last call ends October 3, 2012.> >> > /Loa> > for the mpls wg co-chairs> >> >> > --> >> >> > Loa Andersson           >              email:> [email-masked]> > Sr Strategy and
 Standards Manager     >       [email-masked]> > Ericsson Inc           >               phone: +46> 10 717 52 13> >               >                >                 +46> 767 72 92 13> > _______________________________________________> > mpls mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/mpls> > _______________________________________________> > mpls mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/mpls> > -- > *****************************************************************>            >    请记住，你是独一无二的，就像其他每一个人一样> _______________________________________________> mpls mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/mpls> _______________________________________________mpls mailing [email-masked]://www.ietf.org/mailman/listinfo/mpls

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 3 Oct 2012 08:30:19 +0200

Dear Han Li,
Thanks for your introduction. 
Obviously it is not possible to refer or discuss something that has not been posted or presented….
Best regards,
Nurit
 
From: ext Larry [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2012 2:59 AM
To: D'Alessandro Alessandro Gerardo; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: RE: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection
 
Dear Nurit:

Best regards,
 
                             Han Li

 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Larry
Sent: Tuesday, October 02, 2012 12:41 PM
To: D'Alessandro Alessandro Gerardo; [email-masked]
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection
 
not support!

--- 12年10月2日，周二, Huub van Helvoort <[email-masked]> 写道：
 
>       [email-masked]

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 3 Oct 2012 15:55:39 +0200

Dear Stewart, dear Nurit,

Citing Stewart’s answer

 “The MUST is that all other requirements MUST be met, and the SHOULD

general transport networks"”

indeed I do not believe that we comply with the requirements “MUST” refers to.

More specifically, as an example,
RFC 5654, Req. 106B:  “MPLS-TP recovery mechanisms in a ring SHOULD protect against multiple failures”
Do we comply with that requirement?  What is the solution (and relevant operation/configuration cost) in the proposed draft when two adjacent nodes fail? Did we investigate further approaches before considering current draft as the protection solution for ring topologies?

Another example:
RFC 5654, Req. 105:  “It MUST be possible to lockout (disable) protection mechanisms on selected links (spans) in a ring”
Do we comply with that requirement?  What is the proposed solution (and relevant operation/configuration cost) to satisfy the requirement?

If we look into the draft-ietf-mpls-tp-ring-protection, e.g. for the wrapping solution, we find the following:

Section 1.  Introduction
“We show that this mechanism provides the ability to    protect all of the basic conditions within a reasonable time frame    and does optimize the criteria set out in [TPReqs] as summarized    above.”
Does the proposed solution optimize the criteria as specified in  [TPReqs]? I rose the point in a previous email on October 2nd to Stewart Bryant.
Was the proposed solution compared with other approaches to better understand pro and cons (e.g. respect to the criteria above mentioned and respect to the overall behavior and complexity)?

Section 1.1.  Problem statement
“In either of these two situations, there is a need to address the   following different cases  -
3.  An operator command is issued to a specific ring node.  A  description of the different operator commands is found in Section 4.12 of [RFC4427].  Examples of these commands include  Manual Switch, Forced Switch, or Clear operations.”
I did not find the Freeze command as specified in section 4.13 of RFC 4427 in the proposed solution. What are the commands that draft-ietf-mpls-tp-ring-protection support?
Obs:  reference should be to section 4.13 of RFC4427 and not to section 4.12

Section 2.1.  Wrapping
“Configuration of the protection being performed (i.e.   link protection or node protection) needs to be performed    a-priori, since the configuration of the proper protection path is   dependent upon this decision.”
I believe this is a consequence of the proposed solution and not the general behavior that operator should expect for ring based protection. That clearly  shows  draft-ietf-mpls-tp-ring-protection limitations in terms of optimization for ring based  topology it is intended for

Section 2.3.4.  Wrapping for link and node protection
  “ In addition, the neighboring LSR, that detects the fault,    cannot readily differentiate between a link failure or a node    failure.
   It would be possible to configure extra SPME to protect both for link    and node failures, arriving at a configuration of the ring that is    shown in Figure 5.  Choosing the SPME to use for the wrapping would,  however, then involve considerable effort and could result in the    protected traffic not sharing the same protection path in both    directions.”
Self-explaining… anyway I believe this is a consequence of the proposed solution and not the general behavior that operator should expect for ring based protection. That clearly shows  draft-ietf-mpls-tp-ring-protection limitations in terms of optimization for ring topology it is intended for

So, there are two main points I rose:

1.       Compliance to requirements

2.       Limitations and complexity that are clearly stated in the document itself

Those points bring me to consider the draft not still mature.

Best regards,
Alessandro

Da: Stewart Bryant [mailto:[email-masked]]
Inviato: martedì 2 ottobre 2012 19:11
A: D'Alessandro Alessandro Gerardo
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [AHMPLS-TP] R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

The text in 100 says:

      any other requirement."

requirements 92..109.

Dear Nurit,

Best regards,

Alessandro

Telecom Italia

Transport Innovation

phone:  +39 011 228 5887

mobile: +39 335 766 9607

fax: +39 06 418 639 07

-----Messaggio originale-----

Best regards,

Nurit

-----Original Message-----

To: Loa Andersson

Do not support

Best regards,

Alessandro

Telecom Italia

Transport Innovation

phone:  +39 011 228 5887

mobile: +39 335 766 9607

fax: +39 06 418 639 07

-----Messaggio originale-----

A: Loa Andersson

Do not support.

B.R.

Jia

-----邮件原件-----

发送时间: 2012年9月19日 18:49

Working Group,

/Loa

--

                                              +46 767 72 92 13

mpls mailing list

mpls mailing list

.

--

---

From: Rui Costa <[email-masked]>
Date: Wed, 3 Oct 2012 17:09:11 +0100

Hello,	

1. RFC1958 states "If a previous design, in the Internet context or elsewhere, has successfully solved the same problem [...]".	

2. This draft looks quite different from G.841's sections about rings (or G.8132.1 draft), IMHO. If there's a problem with the liaison accessibility, perhaps the expired comparison http://tools.ietf.org/html/draft-yang-mpls-tp-ring-protection-analysis helps.	

3. Could the authors explain, remembering the RFC1958 quote above ("Internet context or ELSEWHERE"), what's the benefit of this draft versus existing G.841 (Jul/1995)/G.8132.1 draft/draft-helvoort-mpls-tp-ring-protection-switching?	

4. What is the benefit of RFC6378 (Feb2012) versus existing G.841(Jul/1995)/G.8131.1 draft (again, remembering RFC1958...)? What new brings PSC versus APS?	

5. Why did we approve RFC6670, essentially saying "1 standard's better than 2", but create 2 completely new protection standards, alternate to options architecturally similar to those we have in the field for almost 20years?	

6. Why isn't the intersection of the authors of this draft, RFCs 6378 and 6670, the empty set?	

Regards,	
Rui	

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: terça-feira, 2 de Outubro de 2012 18:12
To: ext D'Alessandro Alessandro Gerardo
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Dear Alesandro,

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]]
Sent: Tuesday, October 02, 2012 5:10 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Dear Nurit,

Best regards,
Alessandro

-----Messaggio originale-----
Da: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Inviato: martedì 2 ottobre 2012 16:04
A: D'Alessandro Alessandro Gerardo; Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Alessandro and others that supported the below, Your statement below does not provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed.....
Hence it is impossible to refer to or consider such LC comment as such, unless you provide technical arguments that we can discuss and consider. 
Best regards,
Nurit

-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:[email-masked]]
Sent: Monday, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Rui Costa <[email-masked]>
Date: Wed, 3 Oct 2012 17:10:47 +0100

Understood, once we’re quoting another SDO’s document, but more important is being coherent with ourselves: we can’t criticize today commenting another SDO’s documents/events when we did that same thing yesterday (http://www.ietf.org/mail-archive/web/ietf/current/msg71174.html), incoherently with what we had written the day before (http://www.ietf.org/mail-archive/web/mpls/current/msg06755.html).

A subjective position brings contradiction and loss of logic, and hence our references to the word “technical” lose their semantics.

Regards,
Rui

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: terça-feira, 2 de Outubro de 2012 18:14
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection

Thank you Malcolm!

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 02, 2012 6:47 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection

Regards,

Malcolm

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]<mailto:[email-masked]>>
Sent by: [email-masked]<mailto:[email-masked]>

02/10/2012 10:51 AM

To

<[email-masked]<mailto:[email-masked]>>

cc

Subject

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Eric Gray
Sent: Tuesday, October 02, 2012 4:10 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection

Forwarded...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: 答复: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi All,

BR,
Jian

            Loa Andersson
            <[email-masked]<mailto:[email-masked]>>
            发件人:                                                收件人
            mpls-bounces@i
            etf.org                                                  抄送
                                   "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
                                   MPLS-TP ad hoc team
            2012-09-19             <[email-masked]<mailto:[email-masked]>>,
            18:48                  draft-ietf-mpls-tp-ring-protection@too
                                   ls.ietf.org,
                                   "[email-masked]<mailto:[email-masked]>"
                                   <[email-masked]<mailto:[email-masked]>>
                                                                     主题
                                   [mpls] Working group last call on
                                   draft-ietf-mpls-tp-ring-protection

Working Group,

Please send your comments to the mpls working group mailing lists ([email-masked]<mailto:[email-masked]>).

/Loa

--

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 3 Oct 2012 15:16:16 -0400

Dear All,
I wanted to add a proposal to my comments:
*       As the document essentially describes application of MPLS-TP Linear Protection to ring toplogies, it might be reasonable to have scope of this document match scope of the RFC 6378:
*       1:1 protection of bi-directional p2p LSP
*       1+1 protection of unidirectional p2p LSP
Unidirectional p2mp LSP, both 1+1 and 1:1, as well as 1:1 protection of unidirectional p2p can be set for further study.

        Regards,
                Greg
_____________________________________________
From:   Gregory Mirsky
Sent:   Monday, October 01, 2012 8:53 AM
To:     [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject:        RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3:49 AM
Cc: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Yoshinori Koike <[email-masked]>
Date: Thu, 04 Oct 2012 06:59:43 +0900

Hello,

Followings are my comments and questions.

1)It seems necessary to develop a ring protection mechanism to meet 
requirements of ring protection in RFC5654. This document doesn’t seem 
to specify a ring protection.
2)It seems that this document intends to address only parts of 
requirements for protection of ring topologies; therefore I would 
suggest that the term “ring protection” (total 12 in this document) 
should be modified to an appropriate expression such as “a protection 
for a ring topology”. Title and the first sentence in abstract seem to 
be appropriate.
3)In the second paragraph of clause 1, this document refers to RFC5654. 
However, 5 requirements are not consistent with RFC5654. When they are 
intentionally changed, it seems necessary to clearly explain them and 
the reason. Otherwise, they are confusing. The followings are differences.
a.“minimize” is missing
b.“minimize” is missing
c.“minimize” is missing
d.“recovery operation” is used instead of “maintenance operation”
e.“during protection” is missing,
4)In 1st paragraph of section 2.1, what is the objective/intention of 
including the sentence “Wrapping behavior is similar to MPLS-TE FRR as 
defined in [RFC4090] using either bypass or detour tunnels.”? Is it a 
caution in terms of operation? Could you be more specific on the draft, 
please?
5)In 3rd paragraph of section 2.1, the following sentence is not clear. 
“Coordination would only be needed (where?) to maintain co-routed 
bidirectional traffic (why and when?) even in cases(why plural?) of a 
unidirectional fault condition.” Could you be more specific on this 
point, please?
6)In the 5th bullet in section 2.1, it is not clear what is problematic. 
Probably, it is meant that in-efficiency of resource allocation is 
problematic. If it is correct, it seems better to clearly describe that 
point.

[Editorial]
-In the item 3 in section 1.1 on page 4, section 4.12 of RFC 4427 is 
referred. However, external commands are defined in section 4.13, correctly.
-In the example 2 on page 5, a description of index “1” is missing in 
the explanation of [PB1(G)|LE].
-In the first paragraph of section 2.1, in the third line from the 
bottom, “arounf” should be “around”.
-In figure 1, wrapped data path”@@@” is not described between LSR E & LSR F.
-In figure 8, branches at C, F, G, J, K and A should be removed for 
aligning with the example shown in 3.2.2.
-In the first sentence of section 5, “prevelant” should be “prevalent”.

Best regards,

Yoshinori

-- 
Yoshinori Koike
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Thu, 04 Oct 2012 09:01:44 +0200

Folks,

I've three comments that is not really "technical" but has more to do
with ID format and guidelines.

1. There are too many authors listed on the first page is too high, the
    guideline from the RFC Editor is a maximum of 5
2. The security section says "To be added in future version"
3. The acknowledgment section  includes incorrectly named and
    non-existing groups.

/Loa

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 4 Oct 2012 11:24:49 +0200

Dear Rui,
I have to admit that I am a bit lost here…….and I do not get what your point is…..and how all this relates…..
I am looking for pure technical discussion and cannot see how the below contributes to that…..
I warmly encourage you to provide technical input for the discussion in order to allow us to fruitfully consider and discuss that…
Best regards,
Nurit

From: ext Rui Costa [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2012 6:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] FW: Working group last callondraft-ietf-mpls-tp-ring-protection

 
Regards,              
Rui          

Thank you Malcolm!

Regards, 

Malcolm 

Subject

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of ext Eric Gray
Sent: Tuesday, October 02, 2012 4:10 PM
To: [email-masked]
Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection

Forwarded...

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Saturday, September 29, 2012 5:15 AM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi All,

BR,
Jian

            Loa Andersson                                                 
            <[email-masked]>                                                   
            发件人:                                                收件人 
            mpls-bounces@i                                                
            etf.org                                                  抄送 

                                                                          

Working Group,

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Oct 2012 10:55:09 +0100

Hi,

<individual contributor mode>

I've now had the opportunity to read through the most recent version of this
document.

While I support this work as a useful indication of how RFC 6378 can be used in
a ring topology, and while I would like to see this document progress to be
published as an Informational RFC in a timely manner, I think that the document
needs more polish. Normally I hold off from polish-inducing reviews until the
publication request reaches me as AD, but in this case I think that there are
some significant wrinkles that the WG needs to address before even starting WG
last call!

I agree with Paul's analysis that this is a useful document because it explains
how you run linear protection on a ring topology and shows what can be achieved
in terms of offering protection on a ring without developing or using another
mechanism. This seems to be valuable for operators (who have to choose between
mechanisms) and does not appear to be in contradiction to RFC 5654 or RFC 6372.
It should be noted that the ring protection section of 5654 is talking about the
requirements that have to be met by a protection solution developed to provide
ring protection (i.e. an topology-specific optimized solution) whereas this I-D
is explaining what you get when you apply linear protection on a ring. Thus, I
think it is an over-reaction to suggest that this I-D is defining a new
mechanism (where others may exist) and I think it may demonstrate unwarranted
paranoia (instead of the normal type) to imply that the progression of this
document halts or bars any other work on ring-specific solutions.

However, I feel that the current version of the draft is not clear enough about
its objectives. In that context, the document filename is unfortunate: I would
have chosen something different, but it is not so very important once the
document has become an RFC. I think the Abstract could usefully be rewritten.
Something like:
OLD
   This document presents an applicability statement to address the
   requirements for protection of ring topologies for Multi-Protocol
   Label Switching Transport Profile (MPLS-TP) Label Switched Paths
   (LSP) on multiple layers.  The MPLS-TP Requirements document
   specifies specific criteria for justification of dedicated protection
   mechanism for particular topologies, including optimizing the number
   of OAM entities needed, minimizing the number of labels for
   protection paths, minimizing the number of recovery elements in the
   network, and minimizing the number of control and management
   transactions necessary.  The document proposes a methodology for ring
   protection based on existing MPLS-TP survivability mechanisms,
   specifically those defined in MPLS-TP Linear Protection, without the
   need for specification of new constructs or protocols.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network as
   defined by the ITU-T.
NEW
   This document presents an applicability of linear protection 
   mechanisms for Multi-Protocol Label Switching Transport Profile 
   (MPLS-TP) in ring topologies. Those topologies may be physical or
   logical rings.

   Protection on rings offers a number of opportunities for optimization
   as the protection choices are starkly limited (all traffic traveling 
   one way around a ring can only be switched to travel the other way on
   the ring), but also suffers from some complications caused by the 
   limitations of the topology.

   Requirements for MPLS-TP protection and specifically for protection in
   ring topologies are discussed in "Requirements of an MPLS Transport 
   Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
   Survivability Framework" (RFC 6372). This document shows how MPLS-TP
   linear protection as defined in RFC 6378 can be applied in ring
   topologies, discusses how the requirements are met, and describes 
   scenarios in which the function provided by linear protection in a
   ring topology falls short of some of the requirements.
END

Of course, having made that change, we would need to reflect the change in the
document. To some extent, that involves picking up the scenarios and issues
raised in other emails on this thread (such as Cheng Weiqiang's concern about
second-order failures) and either demonstrating how they can be addressed using
linear protection, or calling them out as scenarios where LP is not a perfect
solution. I think it would also be helpful if the I-D had a section listing the
requirements and noting how they are met (or not).

Loa's three points are valid, and I am particularly worried that there is a
whole section marked TBD in a document that went to last call. Makes me wonder
whether authors read their own document :-(

I thought Yoshinori's email was particularly constructive. Using the words
"protection in a ring topology" in place of "ring protection" seems like a great
gain because it avoids the overloaded terminology and will avoid countless
sensitivities.

There are plenty of editorial nits that need work. I don't think I will list
them at this time because many have been caught by others (Yoshinori has a great
list, Alessandro spotted the bug in figure 1) and I hate duplicated work
especially when the text may be going to change considerably to address other
issues. Maybe we can come back and review a later version of the document for
any remaining nits.

= = = = =

Summary. I support the idea of publishing such a document as an Informational
RFC, but this version is not ready.

Thanks,
Adrian

---

From: Loa Andersson <[email-masked]>
Date: Thu, 04 Oct 2012 15:33:50 +0200

Working group,

<working group chair hat on>
Please find included my comments as a working group chair on
draft-ietf-mpls-tp-ring-protection, the comments were sent to
the authors earlier, but since they were not addressed in the
version we working group last called the authors need
to address them as part of the working group last call comment
resolution process.

<working group chair hat off>

I would also state that I'm in favor of progressing this draft
and publish an Informational RFC. Also I believe that there quite
a bit work to to complete the document.

/Loa

--

---

From: Allasia Andrea <[email-masked]>
Date: Mon, 1 Oct 2012 17:14:32 +0200

+1

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di D'Alessandro Alessandro Gerardo
Inviato: lunedì 1 ottobre 2012 14:27
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: [email-masked]; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

B.R.
Jia

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2012年9月19日 18:49
抄送: [email-masked]; MPLS-TP ad hoc team; [email-masked]; [email-masked]
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

/Loa

--

---

From: Elton huang <[email-masked]>
Date: Wed, 17 Oct 2012 02:13:33 +0000

+1

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Mon, 1 Oct 2012 17:14:32 +0200
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection
> 
> +1
>

---

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 28 Oct 2012 13:31:54 +0200

Greg, hi

Thank you for your comments regarding the draft - after some consideration
I would like to provide answers to your comments, inline (prefixed by yw>>)
below.  Note that I will upload a new version within the next weeks.

Hope this helps,
yaacov

On Mon, Oct 1, 2012 at 5:53 PM, Gregory Mirsky
<[email-masked]>wrote:

>    - Section 2.1
>    - Verbal explanation of the wrapping in the first paragraph might
>    benefit if LSRs be referenced as in Figure 1.
>
> yw>> Will update according to your suggestion, although the explanation is
meant to be a general explanation.

>
>    - As described, wrapping can provide local protection of
>    bi-directional co-routed LSP only in case of link failure. If node
>    protection requested, as mentioned in the third sentence of the first para,
>    MP is not the downstream LSR but next down to downstream. If we expect that
>    PLR in forward direction is MP in reverse direction of given bi-directional
>    LSP, then we have case of segment, not local protection. (Same, I believe,
>    applies to FRR of bi-directional co-routed p2p LSP).
>
> yw>> Not sure that I understand the implications of what you are saying
(to me it seems that you are raising a semantic point) - would help if you
could provide either a suggestion for better text or a direction that you
think we should go to, referencing also the text in section 2.3.3

>    - s/arounf/around/
> yw>> Corrected

>
>    - Figure 1 I think that this figure illustrates wrapping of a single
>    direction in case of local link protection. If that is the intention, then
>    caption might explicitly state that. If a case of a bi-directional LSP to
>    be illustrated for local link protection, then another wrapped data path
>    F-E-D-C-B-A might be added.
>
> yw>> To the best of my understanding, the same SPME (which, by defintion,
is bi-directional) would protect both directions. There is an error in
Figure 1 that has been pointed out to the authors and is corrected in the
upoming revision that extends the SPME to end at F rather than at E.

>
>    - "If protecting both the links and the nodes of a LSP, then, for a
>    ring with N nodes, there is a need for O(2N) alternate paths." I
>    assume that this estimate is for bi-directional co-routed p2p LSP. But
>    co-routed LSP implies coordinated protection which, as mentined before, can
>    not be achieved for node protection with local protection. Coordinated node
>    protection, if not end-to-end, can be in form of segment protection.
>
> yw>> As above, it would help if you could provide some more guidance on
the implications for this draft or better text.

>
>    - Section 2.2
>
>
>    - "The process of notifying the ingress node adds to the latency of
>    the protection switching process, after the detection of the fault
>    condition." I think that that is not necessarily true as ingress
>    notification doesn't have to be explicit but can be implicit if e2e CC/CV
>    monitors working and protecting paths.
>
> yw>> This may be true if the network is completely reliant on CC/CV for
its indications. However,  as is mentioned in RFC6378, the indications my
originate from other sources, e.g. control plane,or a lower (e.g. physical)
layer.

>
>    - Very last para "… there is the necessity for the ring to maintain
>    enough capacity for all of the data in both directions around the ring"
>    seems as too strong requirement considering cases of 1:N linear and shared
>    mesh protection, where bandwidth of a protection path shared.
>
> yw>> I am not sure that I understand the relevance to this document that
is addressing protection on a "ring" - not sure that there is a requirement
in a ring to support these additional (1:n or SMP) protection.

>
>    - Section 2.3
>
>
>    - "… since we will perform all of the OAM functionality on the SPME
>    configured for the traffic, we can minimize the number of OAM sessions
>    needed to monitor the data traffic of the ring - rather than monitoring
>    each individual LSP." Such improvement in OAM scale doesn't come for free
>    as SPME OAM might introduce or hide connectivity and/or continuity defects
>    of enclosed LSPs.
>
> yw>> Can you elaborate on this?  Seems that this comment should be related
to the MPLS-TP Framework document

>
>    - "In all of the following subsections, we use 1:1 linear protection
>    [SurvivFwk] [LinProtect] to perform protection switching and coordination
>    when a signal fault is detected." For 1:1 linear protection scope of the
>    RFC 6378 is limited to bi-directional p2p MPLS-TP constructs.
>    "Applicability of the protocol for 1:1 unidirectional protection and for
>    1:n protection schemes may be documented in a future document and is out of
>    scope for this document", stated in section 1.2. Thus use of PSC for
>    unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this
>    has to be mentioned and reflected in change of the scope of the document.
>
> yw>> As mentioned above (and in conjunction with the text referred to in
your previous comment), the SPME is, by defintion, bi-directional

>
>    - Section 2.3.1
>
>
>    - First para "… each one acts as the ingress and egress in one
>    direction of the bidirectional SPME". I think that terminology
>    "ingress/egress MEP" is not the best and perhaps view of nodal MEP per LSP
>    is sufficient, so that no need to split MEP on given LSP per direction.
>
> yw>> There was no intention of splitting the MEP relative to its position
on the node, will try and find a better way of referring to the MEP at the
ingress and egress points of the SPME.

>
>    - Section 2.3.2
>
>
>    - I think that title of the section needs to say explicitly that link
>    protection by wrapping is discussed in the section (node protection in the
>    2.3.3)
>
> yw>> Corrected

>
>    - Section 2.3.3
>
>
>    - As mentioned, in case of bi-directional co-routed LSP to which node
>    protection required (Figure 4) SPME approach is, effectively, segment, not
>    local protection. SPME level OAM between LSR A and LSR E monitors not only
>    link between LSR A and LSR F and LSR F but link between LSR F and LSR E as
>    well (from LSP POV). The primary SPME, effectively, changes ring topology
>    by excluding LSR F from topology as LSR F would not be processing LSP's
>    outer label but process only SPME's outer label.
>
> yw>> Not sure what correction you are looking for in relation to this
comment!

>
>    - Section 2.3.4
>
>
>    - Local node protection monitors immediate link for link as well as
>    node protection. The difference between these protection modes in selection
>    of a MP, whether immediate neighbor can (link protection) or can not (node
>    protection) be used as MP. The section seems based on misunderstanding of
>    difference between local link and node protection and might be removed.
>
> yw>> Can you provide some more detail or be more specific?

>    - Section 2.4
>    - s/steeing/steering/
> yw>> Corrected

>
>    - What are three OAM sessions that each ring node will have if
>    wrapping used to protect the ring? I see two OAM sessions: immediate link
>    to downstream LSR; around ring to the same LSR. Where the third OAM session?
>
> yw>> This takes into account both link and node protection which would
require an OAM session on the alternate protection SPME.  Will calrify in
the next revision if this is OK with you.

>
>    - "Special consideration" seems as unfounded:
>
>
>    - Not clear why CC/CV OAM in case of SPME steering viewed as
>    insufficient for fast defect detection.
>
> yw>> Alarm reporting is justified in the OAM requirements document on the
basis of this argument that is merely repeated here.

>
>    - Local node and link protection are not mutualy exclusive. Local node
>    protection provides link protection as part of node protection. The
>    problem, from my POV, is that bi-directional co-routed LSP can not have
>    local node protection but only segment protection.
>
> yw>> Again the question of whether this goes beyond a question of
semantics.

>
>    - Section 3
>
>
>    - As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear
>    protection of unidirectional MPLS-TP constructs, including unidirectional
>    p2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs. What
>    mechanism(s) could be used to perform defect detection, coordination and
>    protections switchover?
>
> yw>> Could you be more specific regarding which text you would like to see
corrected?  In general, the protection over the ring is based on the use of
a bi-directional SPME, and for the p2mp cases use of Context-labels to
allow distribution to the specific egress points  of the underlying LSPs.

>
>    - Section 4
>
>
>    - As as stated in RFC 6378 "Applicability of the protocol [PSC, my
>    note] for 1:1 unidirectional protection and for 1:n protection schemes may
>    be documented in a future document and is out of scope for this document".
>
> yw>> And as  stated above in several comments, SPME are bi-directional.

>    - References are both direct RFC, e.g. [RFC4090], and content-based,
>    i.e. [TPReqs]. May consider choosing single style of referencing.
>
> yw>> This will be corrected prior to publication, it is just tedious
during the progression of the document, while some of the other documents
were still drafts.

> From: [email-masked] [*mailto:[email-masked]*<[email-masked]>]
> On Behalf Of Loa Andersson
> Cc: [email-masked]; MPLS-TP ad hoc team;
>                                               +46 767 72 92 13_______________________________________________
> mpls mailing list
> [email-masked]
> *https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
>
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 28 Oct 2012 13:52:26 +0200

Jian, hi

Thank you for your consideration of the draft and comment during the WGLC.
 After consideration of the many comments and reading of the LS received
from the ITU I would like to provide my feedback to your comments.

After careful reading of the ITU liaison statement, I do not see very many
issues raised in that document that are relevant to this draft.  The LS
points to some scenarios of multiple failures across interconnected rings
and claims that the mechanisms suggested in this draft cannot protect for
these situations.  However -
1. The specific scenarios mentioned in the LS seem to be easily covered by
applying the mechanisms in this draft to each of the interconnected rings
separately.
2. There is text at the end of the Introduction that clearly states that
interconnected rings is for further study due to the large number of
different scenarios that need to be addressed.

Aside from this issue the LS includes a table of comparison between the
mechanism that is provided in this draft with two other solutions that are
not provided in the LS.  The table itself contains what seem to be rather
subjective judgements of the different mechanisms but nowhere indicates
that the mechanisms mentioned in this draft are not workable.  Seeing as
this draft is an applicability statement and does not preclude any other
mechanism from being developed, within the IETF, I am not sure what you are
suggesting be addressed by the draft to satisfy your comments.

Your clarification would be helpful.

Thank you and BR,
yaacov weingarten

*Still looking for new opportunity.*

-- 
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 28 Oct 2012 14:12:36 +0200

Jia, hi

Thank you for your comment regarding the draft.  In preparing an updated
version that would address your comments.  However, while the analysis that
you refer to does include descriptions of considerations that should be
known, I do not see that there are any "deficiencies" that need to be
"solved".  In addition, the section does point to an operative conclusion,
i.e. for efficiency use of Steering is recommended, on a working protection
method based on the application of LP to a ring.

If you could be more specific about what correction could be made to the
document, it would be helpful.

Please keep in mind that this document is an applicability statement.

Thank you and BR,
yaacov weingarten

On Sat, Sep 29, 2012 at 12:53 PM, Hejia <[email-masked]> wrote:

> draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using
> SPME as described, either wrapping or steering, does have deficiencies,
> which IMHO should be better reconsidered and solved if possible.
>
>
> B.R.
> Jia
>
> -----邮件原件-----

-- 
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 28 Oct 2012 14:32:57 +0200

Greg, hi

Thank you for your further comments to the ring-protection applicability
document.  However, as I pointed out in my previous message, the
applicability of linear protection is based on the use of SPME as the
working and protection paths and being as these are bi-directional and
seeing as this scope limitation (that you mention) is really to RFC6378 and
should be known to the reader of this draft, I am not sure that it is
appropriate to this document, although we will naturally follow the WG
instructions.

Thanx and BR,
yaacov

On Wed, Oct 3, 2012 at 9:16 PM, Gregory Mirsky
<[email-masked]>wrote:

>     - As the document essentially describes application of MPLS-TP Linear
>    Protection to ring toplogies, it might be reasonable to have scope of this
>    document match scope of the RFC 6378:
>
>
>     - 1:1 protection of bi-directional p2p LSP
>    - 1+1 protection of unidirectional p2p LSP
>
> Unidirectional p2mp LSP, both 1+1 and 1:1, as well as 1:1 protection of
> unidirectional p2p can be set for further study.
>
>         Regards,
>                 Greg
> *From:    *Gregory Mirsky
> *Sent:   *Monday, October 01, 2012 8:53 AM
> *To:     [email-masked]; [email-masked];
> MPLS-TP ad hoc team; [email-masked]
> *Subject:        *RE: [mpls] Working group last call on

-- 
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Sun, 28 Oct 2012 15:45:35 +0200

Dear Alessandro,

Thank you for your detailed list of comments regarding the ring-protection
applicability draft.  As I mentioned in my earlier response, I am trying to
prepare a new version of the draft that will address your concerns, if
possible.  Please see my comments below inline (prefixed by "yw>>")

Thank you and BR,
yaacov weingarten

On Wed, Oct 3, 2012 at 3:55 PM, D'Alessandro Alessandro Gerardo <
[email-masked]> wrote:

> Dear Stewart, dear Nurit,****
>
> ** **
>
> Citing Stewart’s answer****
>
> ** **
>
>  “The MUST is that all other requirements MUST be met, and the SHOULD****
>
> is that the solution SHOULD be those in general transport networks, ****
>
> which is actually is not a ring specific statement. Indeed by ****
>
> reusing the mesh approach (RFC6378) we comply with that requirement ****
>
> since the mesh solution are by definition "identical to those in ****
>
> general transport networks"”  ****
>
> ** **
>
> indeed I do not believe that we comply with the requirements “MUST”
> refers to.****
>
> ** **
>
> More specifically, as an example, ****
>
> RFC 5654, Req. 106B:  “MPLS-TP recovery mechanisms in a ring SHOULD
> protect against multiple failures”****
>
> Do we comply with that requirement?  What is the solution (and relevant
> operation/configuration cost) in the proposed draft when two adjacent nodes
> fail? Did we investigate further approaches before considering current
> draft as the protection solution for ring topologies?
>
yw>> Yes, we comply based on the recommendation that is provided in Section
2.4 of the document that states that Steering is the preferred method of
protection.  This would also address the problems of multiple failures,
even adjacent ones.  In answer to the final question in this series, yes we
investigated different approaches that were proposed to the group in other
drafts and found that they are based on constructs that are not supported
by MPLS and therefore would take time to acheive apporval.  The proposal in
this draft is merely an applicability statement and does not preclude
defining a separate mechanism.

> ****
>
> ** **
>
> Another example:****
>
> RFC 5654, Req. 105:  “It MUST be possible to lockout (disable) protection
> mechanisms on selected links (spans) in a ring”****
>
> Do we comply with that requirement?  What is the proposed solution (and
> relevant operation/configuration cost) to satisfy the requirement?
>
yw>> Yes, just as linear protection supports a Lockout of Protection
operator command, this proposal would support the same operator command.
 Could you elaborate some more your understanding of this requirement?

> ****
>
> ** **
>
> ** **
>
> If we look into the draft-ietf-mpls-tp-ring-protection, e.g. for the
> wrapping solution, we find the following:****
>
> ** **
>
> Section 1.  Introduction****
>
> “We show that this mechanism provides the ability to    protect all of
> the basic conditions within a reasonable time frame    and does optimize
> the criteria set out in [TPReqs] as summarized    above.”****
>
> Does the proposed solution optimize the criteria as specified in  [TPReqs]?
> I rose the point in a previous email on October 2nd to Stewart Bryant. ***
> *
>
> Was the proposed solution compared with other approaches to better
> understand pro and cons (e.g. respect to the criteria above mentioned and
> respect to the overall behavior and complexity)?
>
yw>> RFC5654 mentions the requirement to optimize relative to protecting
each LSP that traverses the "ring" and relative to that measurement the
proposal does optimize the criteria.  It would be very hard to optimize
against all theoretical mechanisms until they all are standardized and
prove that they are based on standard MPLS constructs, or if they require
new constructs (as was the case with one proposed solution) - that these
new constructs be defined and verified to comply with IETF standards for
MPLS.

> ****
>
> ** **
>
> Section 1.1.  Problem statement****
>
> “In either of these two situations, there is a need to address the   following
> different cases  -****
>
> 3.  An operator command is issued to a specific ring node.  A  descriptionof the different operator commands is found in Section 4.12 of [RFC4427].
> Examples of these commands include  Manual Switch, Forced Switch, or
> Clear operations.”****
>
> I did not find the Freeze command as specified in section 4.13 of RFC 4427
> in the proposed solution. What are the commands that draft-ietf-mpls-tp-ring-protection
> support?
>
yw>> Being an applicability statement this draft supports all operator
commands supported by RFC6378.  If there is a need to support additional
commands then these should be proposed as extensions to RFC6378 following
the regular IETF process for proposing extensions (While not relevant to
the current discussion, I might point out that RFC6378 does provide for
extensions of its protocol based on IANA  allocation)

****
> Obs:  reference should be to section 4.13 of RFC4427 and not to section
yw>> Thank you - Corrected.

> ****
>
> ** **
>
> Section 2.1.  Wrapping****
>
> “Configuration of the protection being performed (i.e.   link protection
> or node protection) needs to be performed    a-priori, since the
> configuration of the proper protection path is   dependent upon this
> decision.”****
>
> I believe this is a consequence of the proposed solution and not the
> general behavior that operator should expect for ring based protection.
> That clearly  shows  draft-ietf-mpls-tp-ring-protection limitations in
> terms of optimization for ring based  topology it is intended for
>
yw>> I assume that there is supposed to be a continuation to this sentence,
but based on my understanding of the start of the statement, I will agree
that the Wrapping solution does display certain limitations, some of these
limitationsare intrinsic to Wrapping and some are based on the limitations
added by use of standard MPLS constructs (for example, the use of LSPs that
have a defined starting point and that cannot be used in the same manner as
Ethernet or SDH paths that start at arbitrary points in the network).  For
this reason, the document strongly recommends that Steering be the
mechanism of choice when applying linear protection to ring topoplogies.

> ****
>
> ** **
>
> ** **
>
> Section 2.3.4.  Wrapping for link and node protection****
>
>   “ In addition, the neighboring LSR, that detects the fault,    cannot
> readily differentiate between a link failure or a node    failure.****
>
>    It would be possible to configure extra SPME to protect both for link
> and node failures, arriving at a configuration of the ring that is    shown
> in Figure 5.  Choosing the SPME to use for the wrapping would,  however,
> then involve considerable effort and could result in the    protected
> traffic not sharing the same protection path in both    directions.”****
>
> Self-explaining… anyway I believe this is a consequence of the proposed
> solution and not the general behavior that operator should expect for ring
> based protection. That clearly shows  draft-ietf-mpls-tp-ring-protection
> limitations in terms of optimization for ring topology it is intended for
>
yw>> See previous comment.

> ****
>
> ** **
>
> ** **
>
> So, there are two main points I rose:****
>
> **1.       **Compliance to requirements
>
yw>> I believe that I addressed these concerns

> ****
>
> **2.       **Limitations and complexity that are clearly stated in the
> document itself
>
yw>> I would like to say that if the limitations are "clearly stated" then
this should not be a limitation of approval of the document as long as the
user is aware of the limitations, especially considering that this is
intended to be an Informative Applicability Document.

> ****
>
> ** **
>
> Those points bring me to consider the draft not still mature.****
>
> ** **
>
> Best regards,****
>
> Alessandro****
>
> *Telecom Italia
> *Alessandro Gerardo D'Alessandro
> Transport Innovation
> Via Reiss Romoli, 274 - 10148 Torino*
> *phone:  +39 011 228 5887
> mobile: +39 335 766 9607
> fax: +39 06 418 639 07****
>
> ** **
>

-- 
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Mon, 29 Oct 2012 11:03:27 +0200

Rui, hi

Thank you for your comments to this WGLC, I will try to answer some of your
comments that deal directly with my aspect of the draft in question and
leave your other comments for those that are more qualified.  See inline
below.

Hope this helps,
yaacov weingarten

On Wed, Oct 3, 2012 at 6:09 PM, Rui Costa <[email-masked]> wrote:

> Hello,
>
> 1. RFC1958 states "If a previous design, in the Internet context or
> elsewhere, has successfully solved the same problem [...]".
>
yw>>  Not sure what you are driving at – the question whether protection
schemes that were designed for the physical layer, where rings are
prevalent, is applicable to the logical layer of MPLS may need to be
examined further.  However, this document merely states that it is possible
to address the protection by applying an existing design to the domain.

>
> 2. This draft looks quite different from G.841's sections about rings (or
> G.8132.1 draft), IMHO. If there's a problem with the liaison accessibility,
> perhaps the expired comparison
> http://tools.ietf.org/html/draft-yang-mpls-tp-ring-protection-analysishelps.
>
yw>>  This is very true and it was not a goal of the authors to adhere to
either G.841 nor G.8132.1 (except in the description of the Wrapping and
Steering mechanisms).  I find the comparison presented in the referenced
draft as very helpful and I notice that there are several instances in
which this comparison has come to different conclusions from those listed
in the LS from ITU-T SG15 (in particular in the categories of Simplicity,
Resource use, and Configuration), but I am not sure why this is relevant to
the draft in question.

>
> 3. Could the authors explain, remembering the RFC1958 quote above
> ("Internet context or ELSEWHERE"), what's the benefit of this draft versus
> existing G.841 (Jul/1995)/G.8132.1
> draft/draft-helvoort-mpls-tp-ring-protection-switching?
>
yw>>  As mentioned above, this is merely an applicability statement that
says that many of the issues in ring protection can be addressed by use of
the existing Linear Protection mechanism.  In addition, it is very unclear
how the two mechanisms that you mention (one is a physical layer mechanism,
the other is a draft that was discussed [under a different name and author]
in WG) really can be applied to MPLS without introducing new constructs to
MPLS whose definition and technology would need to precede the work on
these mechanisms.  In particular (just one example that needs to be
examined more closely), there is a claim that running OAM on a segment LSP
can notify all other LSPs that traverse a particular LSR  that they must
reroute their traffic without a real MPLS description of how this is done.
 While this is very understandable in an Ethernet environment that works at
the  MAC address level, it is unclear how this is applied to MPLS label,
without causing layer violations.

>
> 4. What is the benefit of RFC6378 (Feb2012) versus existing
> G.841(Jul/1995)/G.8131.1 draft (again, remembering RFC1958...)? What new
> brings PSC versus APS?
>
yw>> I believe that this was a WGLC on a different document

>
> 5. Why did we approve RFC6670, essentially saying "1 standard's better
> than 2", but create 2 completely new protection standards, alternate to
> options architecturally similar to those we have in the field for almost
> 20years?
>
yw>> Again I believe that this was a WGLC on a different document.  But it
is interesting that you have a mechanism in the field for almost 20 years
for a technology that is only 13 years old!!  I do believe that new
technologies call for a reexamination of tools that we have in the field
rather than the other way around.

> 6. Why isn't the intersection of the authors of this draft, RFCs 6378 and
yw>> Again this was a WGLC on a different document.

yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Mon, 29 Oct 2012 12:14:37 +0200

Yoshinori, hello

Thank you for your very helpful comments on the draft.  In preparing the
new version of the draft I will take these comments into account, as
described in my comments inline below.

Thank you and BR,
yaacov weingarten

On Wed, Oct 3, 2012 at 11:59 PM, Yoshinori Koike <
[email-masked]> wrote:

> requirements of ring protection in RFC5654. This document doesn’t seem to
> specify a ring protection.
>
yw>> Not sure that I fully understand what you mean by "doesn't seem to
specify a ring protection" - the document explains how it is possible to
protect traffic that is traversing a ring, for most common scenarios, based
on MPLS constructs and the extensions defined for MPLS-TP.  Keep in mind
that providing protection at the physical layer (where the ring exists) is
really not MPLS, and may be based on constructs that are not well-defined
in MPLS.

2)It seems that this document intends to address only parts of requirements
> for protection of ring topologies; therefore I would suggest that the term
> “ring protection” (total 12 in this document) should be modified to an
> appropriate expression such as “a protection for a ring topology”. Title
> and the first sentence in abstract seem to be appropriate.
>
yw>> I double-checked the twelve instances in which "ring protection" is
mentioned in the document and noticed that they all are part of the
description of the general mechanisms, i.e. Steering and Wrapping, and do
not refer to the proposals that are described in the document.  Therefore,
unless you do not consider Wrapping and Steering to be "ring protection", I
do not see a need to change the text.

> intentionally changed, it seems necessary to clearly explain them and the
> reason. Otherwise, they are confusing. The followings are differences.
> a.“minimize” is missing
> b.“minimize” is missing
> c.“minimize” is missing
>
yw>> The sentence before the bullets (and that applies to all of the
bullets) mentions the requirement to "optimize" all of the criteria.  Will
change this word to "minimize" if that will help.

> d.“recovery operation” is used instead of “maintenance operation”
yw>> OK will change

> e.“during protection” is missing,
yw>> OK, will change.

> caution in terms of operation? Could you be more specific on the draft,
yw>> The intent of the statement was to make a comparison that would be
familiar to people that are more familiar with existing MPLS mechanisms
rather than ITU mechanisms.  There is no reason for a “caution” since FRR
is very successful.

> unidirectional fault condition.” Could you be more specific on this point,
> please?
>
yw>> The sentence is stating that if there is a need to maintain the
traffic as co-routed bidirectional at all times, both on the working path
and whenever protection is activated, then there will be a need for
coordination between the two local LSRs for cases of a unidirectional fault
in order to verify that both endpoints realize that they need to switchover
to the protection path.  If there is no need to maintain the co-routed
nature, then there is no need for coordination since one direction may
continue to transmit on the working path, while the second direction
transmits on the protection path, just notification is needed!
Regarding the use of the plural “cases” that is part of the English
language usage for generalization!

> problematic. If it is correct, it seems better to clearly describe that
yw>> It is problematic since there are a large number of parallel SPMEs
that are being defined and if we allocate the full resources to all of the
SPMEs there will be major over-subscription of the resources available.
 Therefore, it is advised to only reserve the resources and not allocate!
Will try to clarify by adding text.

> referred. However, external commands are defined in section 4.13, correctly.
yw>> OK Corrected

> -In the example 2 on page 5, a description of index “1” is missing in the
> explanation of [PB1(G)|LE].
>
yw>> The one is referring to the fact that it is the label related to
SPME-1 (which is mentioned in the explanation)

> -In the first paragraph of section 2.1, in the third line from the bottom,
> “arounf” should be “around”.
>
yw>> OK Corrected

> -In figure 1, wrapped data path”@@@” is not described between LSR E & LSR
yw>> OK Corrected

> aligning with the example shown in 3.2.2.
yw>> These branches are the egress points of the protection path SPME,
however, due to the limitations of ASCII art it was difficult to draw them
properly, I have slightly changed them and labelled them in the figure.

> -In the first sentence of section 5, “prevelant” should be “prevalent”.
yw>> OK Corrected

>> draft-ietf-mpls-tp-ring-**protection-02-txt.
>>
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>

-- 
Thanx and BR,
yaacov