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

From: cheng weiqiang <[email-masked]>
Date: Fri, 9 Nov 2012 15:48:58 +0800

Hi Yaacov，

Thank you very much for your reply.

Comments on P2P wrapping solution:
We have a simple survey on wrapping solution that shows in SDH ring
network more than 90% of ring protection application scenarios are
using wrapping solution. That indicates wrapping solution is really
important. However as you said your wrapping solution is “difficulty
in addressing the scenarios of multiple failures in adjacent nodes or
links”, that means performance of your wrapping solution is even worse
than linear protection.

Comments on P2P Steering solution:
As described in draft, you need O(2N^2) SPME for steering solution.
Let’s consider a 16 nodes access ring, in the transport network,
according to our servey, the LSP number per node in average is less
than 5, that means usually there are only 16 x 5 x 2= 160 LSPs in one
access ring. However, based on your solution, 16 x 15 x2 =480 SPME
should be set up which introduces more OAM sessions, more recovery
elements, more Labels, and more management transactions. It is a
violation of chapter 2.5.6.1. RFC 5654.

So compared to Linear protection, wrapping solution has poorer
performance and steering solution is more complicated.

Could you give more clarification?

B.R.

Weiqiang Cheng

2012/10/28 Yaacov Weingarten <[email-masked]>:
> 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:
>>
>> 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
>>
>>
>>
>>
>> 2012/10/2 Adrian Farrel <[email-masked]>:
>> > 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
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> >> cheng weiqiang
>> >> Sent: 02 October 2012 14:02
>> >> To: [email-masked]
>> >> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-tp-ring-
>> >> [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
>> >> Research Institute of China Mobile
>> >> Department of Network Technology
>> >> _______________________________________________
>> >> mpls mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/mpls
>> >
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
> --
> Thanx and BR,
> yaacov
>
> Still looking for new opportunity
>

---

From: Yaacov Weingarten <[email-masked]>
Date: Fri, 9 Nov 2012 12:31:12 +0200

See inline below

BR,
yaacov
> links”, that means performance of your wrapping solution is even worse

yw>> I fully understand why 90% in SDH rings used wrapping - for SDH that
is a very low level protocol, i.e. very close to the HW, it was the
simplest and ITU's definition for Steering was difficult to implement.
However, MPLS is not SDH in very many aspects, one of these aspects is that
it uses logical connections rather than the physical layer that is used by
SDH or even Ethernet and when the operators switch over to a new technology
in which Steering (which has obvious advantages over Wrapping in BW use and
not overloading traffic by sending it around the ring more than once)
becomes simpler, I would expect that we should be recommending the better
solution rather than trying to emulate an older technology.
> violation of chapter 2.5.6.1. RFC 5654.

yw>> So what you are saying is that you foresee that even though the
operators are now adopting a newer technology that will scale better to
support thousands of connections and not be limited by the limitations that
are carried over from SDH, they will still limit themselves to this low
number of connections!
But even if this is true then certainly the implication is that there is no
real reason to consider creating an optimization for such a low number of
LSPs and it raises the question of whether there is a need for any "ring"
protection in MPLS (where rings do not really exist, since all connections
in MPLS are LSPs that are actually agnostic to the underlying physical
connections that may be rings or full mesh).
In any case, for this low number of LSPs it certainly makes more sense to
use simple Linear Protection, I agree.  But then again, this draft
addresses the possibility of optimizing over a theoretical network of
thousands of connections and reducing it to an order of hundreds by just
applying the use of SPME.
> >>                                     ___              ___     x
___
> >>                                    \_B_/            \_A_/
\_F_/

---

From: weiqiang cheng <[email-masked]>
Date: Sun, 11 Nov 2012 16:16:27 +0800

Hi Yaacov,
Many thanks for your clarification but it seems you did not answer my
questions still.

Let’s clarify my steering application scenarios in my last mail at
first. The survey I gave you is really on the MPLS-TP networks instead
of SDH. Please pay attention to that I was using "access ring". In the
MPLS-TP networks, I fully agree the total links number is much bigger
than SDH. But No matter the topology is rings or full mesh, for the
access layers network, the number of LSPs is really limited. If you
knows well of the architecture of the transport network, it is easy to
get that the conclusion that 5 LSPs number per access node in our
survey is really reasonable. I would like to give you another number:
the number of access nodes often takes more than 80% account of that
in whole MPLS-TP networks. If you agree that your draft is "optimizing
over a theoretical network of thousands of connections", does that
mean you will loss more than 80% application scenarios of the network?

Let's see wrapping again, as you said the wrapping is a simple
mechanism. That means that with the same hardware its switch-over time
can be as short as possible and it is easy to implement. That is
enough for its survival in MPLS-TP network. So I suggest it is more
constructive to improve the wrapping performance instead of to avoid
using it. Do you agree?

B.R.
Weiqiang Cheng

-----------------------------------------------------------------------------
See inline below
BR,
yaacov
On Nov 9, 2012 9:48 AM, "cheng weiqiang" <chengwq at gmail.com> wrote:
> Hi Yaacovï
> important. However as you said your wrapping solution is âdifficulty
> linksâ, that means performance of your wrapping solution is even worse
> than linear protection.
yw>> I fully understand why 90% in SDH rings used wrapping - for SDH
that is a very low level protocol, i.e. very close to the HW, it was
the simplest and ITU's definition for Steering was difficult to
implement.Â However, MPLS is not SDH in very many aspects, one of
these aspects is that it uses logical connections rather than the
physical layer that is used by SDH or even Ethernet and when the
operators switch over to a new technology in which Steering (which has
obvious advantages over Wrapping in BW use and not overloading traffic
by sending it around the ring more than once)Â becomes simpler, I
would expect that we should be recommending the better solution rather
than trying to emulate an older technology.
> Letâs consider a 16 nodes access ring, in the transport network,
yw>> So what you are saying is that you foresee that even though the
operators are now adopting a newer technology that will scale better
to support thousands of connections and not be limited by the
limitations that are carried over from SDH, they will still limit
themselves to this low number of connections!
But even if this is true then certainly the implication is that there
is no real reason to consider creating an optimization for such a low
number of LSPs and it raises the question of whether there is a need
for any "ring" protection in MPLS (where rings do not really exist,
since all connections in MPLS are LSPs that are actually agnostic to
the underlying physical connections that may be rings or full mesh).
In any case, for this low number of LSPs it certainly makes more sense
to use simple Linear Protection, I agree.Â But then again, this draft
addresses the possibility of optimizing over a theoretical network of
thousands of connections and reducing it to an order of hundreds by
just applying the use of SPME.