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

From: cheng weiqiang <[email-masked]>
Date: Tue, 2 Oct 2012 21:01:41 +0800

Do not support.

In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be
optimized for simplification of the ring operation and the resources
consumption around the ring. This draft cannot meet the requirement.

Best Regards,

Cheng Weiqiang
Research Institute of China Mobile
Department of Network Technology

---

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

Forwarded...

-----Original Message-----
From: cheng weiqiang [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2012 9:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. This draft cannot meet the requirement.

Best Regards,

Cheng Weiqiang

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Oct 2012 15:09:36 +0100

Hi, 

Let me pitch in here as an individual contributor who sourced a lot of the text
in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised from the
ITU-T.

I have read and reread that section trying to find the text that is claimed
below. It does not exist.

Could you please point to the specific requirement you believe is not met? Or
maybe you are confused by the preamble text in the section that describes the
circumstances under which an optimized protection mechanism (rather than one
built from the mechanisms that operate outside a ring) might be developed.

Maybe, also, you could explain in what way you consider the current proposal
does not make good use of the resources on the ring (i.e. what features don't
work) so that the authors can look at improving their solution.

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> cheng weiqiang
> Sent: 02 October 2012 14:02
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

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

Forwarded...

Please do not include the E-Mail address "[email-masked]" as an addressee in 
your mail...

--
Eric

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2012 10:10 AM
To: 'cheng weiqiang'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi, 

Let me pitch in here as an individual contributor who sourced a lot of the text in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised from the ITU-T.

I have read and reread that section trying to find the text that is claimed below. It does not exist.

Could you please point to the specific requirement you believe is not met? Or maybe you are confused by the preamble text in the section that describes the circumstances under which an optimized protection mechanism (rather than one built from the mechanisms that operate outside a ring) might be developed.

Maybe, also, you could explain in what way you consider the current proposal does not make good use of the resources on the ring (i.e. what features don't
work) so that the authors can look at improving their solution.

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of cheng weiqiang
> Cc: [email-masked]; [email-masked]; 
> draft-ietf-mpls-tp-ring- [email-masked]

---

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

Dear Ceng Weiquiang,
In order to be able to refer to your comment, can you please indicate
which specific requirements in section 2.5.6.1. of RFC 5654 cannot be
met and (technically) why do you think so...
Best regards,
Nurit

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

Forwarded...

-----Original Message-----
From: cheng weiqiang [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2012 9:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] Working group last call on
draft-ietf-mpls-tp-ring-protection

Do not support.

Best Regards,

Cheng Weiqiang

---

From: cheng weiqiang <[email-masked]>
Date: Wed, 3 Oct 2012 17:40:12 +0800

Dear adrian,

Here I would like to try to describe some issues on the ring
protection solution from my point view.

1. The Wrapping solution doesn’t work when Multi-links faults happen

For each link in the ring, current wrapping solution defines two SPME
- the first is a SPME between the two LSRs that are connected by the
link,and the second SPME

between these same two LSRs but traversing the entire ring (except the
link that connects the LSRs).

                                    ___              ___     x       ___
                    ======>/LSR\********/LSR\********/LSR\
                                   \_B_/            \_A_/           \_F_/
                                      *                                       *
                                      *                                       *
                                      *                                       *x
                                    _*                 ___                *_

/LSR\********/LSR\********/LSR\======>
        \_C_/            \_D_/            \_E_/

            ===> connected LSP    *** physical link
                 x   link fault

Above figure shows that One LSP enter the ring from LSR B and Exit
from LSR E. And at the same time the link A-F and link F-E are both
broken.According to current

solution, both the protection SPME for A-F and the protection SPME for
Link F-E should be activated synchronously. Obviously, it does not
work.

At the same situation, the ring protection for SDH, G.8132(T-MPLS) and
the MSRP solution (C-2098 “MPLS-TP Shared-Ring protection (MSRP)
mechanism for ring topology",

ITU-T SG15 meeting, Sep. 2012) can work well.

2.Steering function is totally the same with 1:1 linear protection

As the draft mentioned "we use 1:1 linear protection [SurvivFwk]
[LinProtect] to perform protection switching and coordination when a
signal fault is detected." It is

the basic 1:1 linear protection(we can see it as a SNC protection,in
another words 1:1 linear protection is using in sub-network).

It does not provide any more simplicity and optimism than 1:1 linear
protection. That is why we say this draft cannot meet R100 of RFC5654
the requirement.

So I don't think we need defined it in the ring draft redundantly again.

Best Regards,

Cheng Weiqiang
Research Institute of China Mobile
e-mail:[email-masked]
mobile: +86 138 1001 9089

---

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

Cheng, hi

Thank you for your comments regarding the ring protection applicability
statement.

I find your scenarios as being very interesting and understand the concenr
in certain networks for the prevelance of such scenarios.  While I agree
with your analysis that the Wrapping solution that is proposed in the draft
would have difficulty in addressing the scenarios of multiple failures in
adjacent nodes or links, I think that this just strenghthens the
recommnedation of Section 2.4 that it is better to apply Steering as a
preferred methoid of protection.  In addition to the considerations
mentioned in Section 2.4, Steering would easily overcome the scenarios that
you mention and is an easy application of LP to the ring scenarios.

Regarding your second point, I would like to clarify that, in my
understanding, the optimization criteria mentioned in RFC5654 are
optimizations compared to using linear protection to protect each
individual LSP, which this draft certainly optimizes by protecting the SPME
that tunnels numerous LSPs and therefore provides the desired optimization.
 The optimization certainly was never intended to be relative to a
theoretical protection scheme that extends MPLS beyond its present
definition by using constructs that are not supported in MPLS.

Hope this helps,
yaacov weingarten

*Still looking for new opportunity.*

On Wed, Oct 3, 2012 at 11:40 AM, cheng weiqiang <[email-masked]> wrote:

>                                       *
>     *
>                                       *
>     *
>                                       *
>     *x
>                                     _*                 ___
>  *_

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*