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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2012 14:28:55 +0100

Hi,
 
Thanks for taking the time to set out your concerns.
 
I hope this now gives the WG something to work with.
 
With regard the first point, I hope to hear from the authors whether you have
identified a scenario where linear protection will not work (in which case they
should probably flag this short-coming in the I-D) or if they can see how linear
protection can handle the double failure case you have illustrated.
 
Obviously, we don't have access to C-2098 and can't take it as input to the IETF
discussions, so if its authors (was that you?) want to take that material as
contribution to the MPLS WG's work, you need to submit it either as an
Internet-Draft or as email.
 
The second of your discussion points is related to Section 2.5.6.1 of RFC 5654,
and specifically R100. I reproduce it here for our readers:
 
   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.
 
I think the authors need to address this point, but my understanding is that the
whole section is intended to describe the requirements that have to be satisfied
by topology-specific solutions. Thus, if we were inventing a new protection
solution applicable in rings then we would need to address these requirements
directly. However, I believe that the I-D that is in last call is called
"Applicability of MPLS-TP Linear Protection for Ring Topologies". That is, it
does not define a new mechanism, but specifically shows how the general
mechanism can be applied. 
 
Obviously, I can't speak for the WG, but it would seem to me that nothing in
this I-D precludes the development of a topology-specific solution for rings
that meets the optimization criteria in Section 2.5.6.1 of RFC 5654 and also
addresses the specific requirements in that section. It also seems to me that
the I-D in question is not a protocol specification at all (note that it is an
Informational draft) and actually does not even describe anything other than how
linear protection might apply in a ring topology.
 
So I am not quite sure why you believe that the failure of the generic solution
to address a requirement intended to describe optimizations is a reason to not
publish this document. Rather, in your shoes, I would see it as an encouragement
to do topology-specific work to follow on from this current I-D.
 
Cheers,
Adrian
 
> -----Original Message-----
> From: cheng weiqiang [mailto:[email-masked]]
> Sent: 03 October 2012 10:40
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-tp-ring-
> [email-masked]; [email-masked]
> Subject: Re: [mpls] Working group last call on
draft-ietf-mpls-tp-ring-protection
> 
> 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
> >

---

From: cheng weiqiang <[email-masked]>
Date: Wed, 3 Oct 2012 22:52:58 +0800

Adrian,

Thank you very much for your prompt and detailed reply. I need more
time to digest it. However, the current draft is really not mature to
get WG consensus. Do you agree?

B.R.
Cheng Weiqiang

2012/10/3 Adrian Farrel <[email-masked]>:
> With regard the first point, I hope to hear from the authors whether you
> have identified a scenario where linear protection will not work (in which
> case they should probably flag this short-coming in the I-D) or if they can
> see how linear protection can handle the double failure case you have
> illustrated.
>
>
>
> Obviously, we don't have access to C-2098 and can't take it as input to the
> IETF discussions, so if its authors (was that you?) want to take that
> material as contribution to the MPLS WG's work, you need to submit it either
> as an Internet-Draft or as email.
>
>
>
> The second of your discussion points is related to Section 2.5.6.1 of RFC
> 5654, and specifically R100. I reproduce it here for our readers:
>
>
>
> I think the authors need to address this point, but my understanding is that
> the whole section is intended to describe the requirements that have to be
> satisfied by topology-specific solutions. Thus, if we were inventing a new
> protection solution applicable in rings then we would need to address these
> requirements directly. However, I believe that the I-D that is in last call
> is called "Applicability of MPLS-TP Linear Protection for Ring Topologies".
> That is, it does not define a new mechanism, but specifically shows how the
> general mechanism can be applied.
>
>
>
> addresses the specific requirements in that section. It also seems to me
> that the I-D in question is not a protocol specification at all (note that
> it is an Informational draft) and actually does not even describe anything
> other than how linear protection might apply in a ring topology.
>
>
>
> So I am not quite sure why you believe that the failure of the generic
> solution to address a requirement intended to describe optimizations is a
> reason to not publish this document. Rather, in your shoes, I would see it
> as an encouragement to do topology-specific work to follow on from this
> current I-D.
>
>
>
> Cheers,
>
> Adrian
>
>
>
>> 1. The Wrapping solution doesn’t work when Multi-links faults happen
>
>>
>
>> the MSRP solution (C-2098 “MPLS-TP Shared-Ring protection (MSRP)
>
>> > 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.
>
>> >
>
>> > 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
>

---

From: cheng weiqiang <[email-masked]>
Date: Wed, 3 Oct 2012 23:23:29 +0800

Support.

And additional question to authors:

R27 of RFC 5654 requires " B.  It MUST be possible to deploy MPLS-TP
in arbitrarily interconnected rings with one or two points of
interconnection. "

Arccording the draft solution, It seems very hard to implement it.
Could you give more information on "How the solution in draft to
implement it" ?

Best Regards,

Cheng Weiqiang

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2012 16:28:24 +0100

I'm not going to make any comment about consensus on the document - That is the
job of the WG chairs and I am on the appeals path for any such assessment.

It seems to me that there are certainly some questions to be answered (that
might result in explanations, or might result in caveats being added to the
document). It also seems to me that this document is not trying to say "here is
the only solution that can ever work in MPLS-TP rings" but is actually saying
that here is how you might get protection on a ring using linear protection
techniques without the need for specification of new constructs or protocols. as
such, I don't believe that corner cases (and frankly, second order failures on a
ring should not be regarded as primary design features, should they?) prevent
publication, but should be highlighted as potential draw-backs.

Thanks,
Adrian

> Sent: 03 October 2012 15:53
> To: [email-masked]
> Cc: [email-masked]
> >> link, and the second SPME

---

From: cheng weiqiang <[email-masked]>
Date: Thu, 4 Oct 2012 19:02:17 +0800

Hi,

R106 of RFC 5654 mentioned "SHOULD protect against multiple failures".
And well known, the multi-failures recovery is a basic function for
ring protection. And the double failures scenario I mentioned is the
most basic multiple failures condition.

By the way, the wrapping solution of the draft cannot handle the
adjacent nodes failures also.

I don't think they are corner cases. I give you some examples for your
reference.

For the Micro-wave system, the adjacent hops often are impacted by
whether or other facts at the same time.

For the adjacent nodes, they often share the same power supply system.
When issues happen on power system, they may shut down simultaneous.

So for the carrier grade system, the multi-failures scenarios I
mentioned should be the basic functionality.

B.R.

Cheng Weiqiang

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 4 Oct 2012 12:46:07 -0400

Dear Cheng, et al.,
I would note that "multiple failure" scenario, illustrated in Annex 1  of liaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-networks, is, in my understanding, series of single failures in interconnected rings. I believe that protection architectures described in the document under discussion (wrapping, steering without and wit SPME) can be easily applied to interconnected ring topology as presented in the Annex 1. I've noticed that, referring to the Annex 1, that scenarios with dual failure on the same ring are not considered, i.e. failure at point 1 and 2 or 3 and 4. Should it be interpreted as "multiple failure" scenario implies failures in multiple interconnected rings over which a protected path spans but with only single failure in any given ring of the chain?

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of cheng weiqiang
Sent: Thursday, October 04, 2012 4:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi,

R106 of RFC 5654 mentioned "SHOULD protect against multiple failures".
And well known, the multi-failures recovery is a basic function for ring protection. And the double failures scenario I mentioned is the most basic multiple failures condition.

By the way, the wrapping solution of the draft cannot handle the adjacent nodes failures also.

I don't think they are corner cases. I give you some examples for your reference.

For the Micro-wave system, the adjacent hops often are impacted by whether or other facts at the same time.

So for the carrier grade system, the multi-failures scenarios I mentioned should be the basic functionality.

B.R.

Cheng Weiqiang

On Oct 3, 2012 11:28 PM, "Adrian Farrel" <[email-masked]> wrote:
>
> I'm not going to make any comment about consensus on the document -
> That is the job of the WG chairs and I am on the appeals path for any such assessment.
>
> It seems to me that there are certainly some questions to be answered
> (that might result in explanations, or might result in caveats being
> added to the document). It also seems to me that this document is not
> trying to say "here is the only solution that can ever work in MPLS-TP
> rings" but is actually saying that here is how you might get
> protection on a ring using linear protection techniques without the
> need for specification of new constructs or protocols. as such, I
> don't believe that corner cases (and frankly, second order failures on
> a ring should not be regarded as primary design features, should they?) prevent publication, but should be highlighted as potential draw-backs.
>
> Thanks,
> Adrian
>
> > time to digest it. However, the current draft is really not mature
> > to get WG consensus. Do you agree?
> >
> > B.R.
> > Cheng Weiqiang
> >
> >
> > > With regard the first point, I hope to hear from the authors
> > > whether you have identified a scenario where linear protection
> > > will not work (in which case they should probably flag this
> > > short-coming in the I-D) or if they can see how linear protection
> > > can handle the double failure case you have illustrated.
> > >
> > > Obviously, we don't have access to C-2098 and can't take it as
> > > input to the IETF discussions, so if its authors (was that you?)
> > > want to take that material as contribution to the MPLS WG's work,
> > > you need to submit it either as an Internet-Draft or as email.
> > >
> > > The second of your discussion points is related to Section 2.5.6.1
> > > of RFC 5654, and specifically R100. I reproduce it here for our readers:
> > >
> > > I think the authors need to address this point, but my
> > > understanding is that the whole section is intended to describe
> > > the requirements that have to be satisfied by topology-specific
> > > solutions. Thus, if we were inventing a new protection solution
> > > applicable in rings then we would need to address these
> > > requirements directly. However, I believe that the I-D that is in last call is called "Applicability of MPLS-TP Linear Protection for Ring Topologies".
> > > That is, it does not define a new mechanism, but specifically
> > > shows how the general mechanism can be applied.
> > >
> > > Obviously, I can't speak for the WG, but it would seem to me that
> > > nothing in this I-D precludes the development of a
> > > topology-specific solution for rings that meets the optimization
> > > criteria in Section 2.5.6.1 of RFC 5654 and also addresses the
> > > specific requirements in that section. It also seems to me that
> > > the I-D in question is not a protocol specification at all (note
> > > that it is an Informational draft) and actually does not even describe anything other than how linear protection might apply in a ring topology.
> > >
> > > So I am not quite sure why you believe that the failure of the
> > > generic solution to address a requirement intended to describe
> > > optimizations is a reason to not publish this document. Rather, in
> > > your shoes, I would see it as an encouragement to do
> > > topology-specific work to follow on from this current I-D.
> > >
> > > Cheers,
> > >
> > > Adrian
> > >
> > >> Cc: [email-masked]; [email-masked];
> > >> draft-ietf-mpls-tp-ring- [email-masked];
> > >> [email-masked]
> > >> - 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     ___
> > >> 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.
> > >>
> > >> [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.
> > >>

---

From: "Rogers, Josh" <[email-masked]>
Date: Thu, 4 Oct 2012 13:13:21 -0400

Greg, when I read ITU document, I suspected the concern about 'multiple failures' was surrounding situations where a single event (fiber cut for instance) may impact multiple rings (imagine two rings entering a facility at the same entry, possibly same sheath).  The diagram showing failure points 1, 2, 3, and 4 seemed to me to be relatively close, where a single event could cause multiple impacts (break more than one ring).

Of course, I'm guessing because it didn't appear all that clear that was the intent.

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 4, 2012 11:46 AM
To: cheng weiqiang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Dear Cheng, et al.,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of cheng weiqiang
Sent: Thursday, October 04, 2012 4:02 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi,

B.R.

Cheng Weiqiang

On Oct 3, 2012 11:28 PM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > 2012/10/3 Adrian Farrel <[email-masked]<mailto:[email-masked]>>:
> > > Hi,
> > >
> > >> To: [email-masked]<mailto:[email-masked]>
> > >> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > >> draft-ietf-mpls-tp-ring- [email-masked]<mailto:[email-masked]>;
> > >> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 5 Oct 2012 09:20:02 +0000

Hi Josh,

in addition to what already said by Greg, the protection of interconnected rings is not in the scope of the ring protection applicability draft but in the scope of this one:
http://tools.ietf.org/id/draft-liu-mpls-tp-interconnected-ring-protection-02.txt

BR
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogers, Josh
Sent: giovedì 4 ottobre 2012 19.13
To: Gregory Mirsky; cheng weiqiang; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Dear Cheng, et al.,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of cheng weiqiang
Sent: Thursday, October 04, 2012 4:02 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Hi,

B.R.

Cheng Weiqiang

---

From: cheng weiqiang <[email-masked]>
Date: Fri, 5 Oct 2012 19:44:07 +0800

Dear Greg, et al.,
I would like to clarify the meaning of the 'multiple failures'. The
Annex 1 of liaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-networks
is from the “T09-SG15-C-2097 PTN requirements on Ring protection”, and
I am the author of the contribution and the figure was drawn by me.
In that context, I intend to illustrate the ring protection have more
capability on ‘multiple failures’. By default, the ‘multiple failures’
include the adjacent links or nodes failure in single ring. Because
both linear protections and all previous ring protection solutions can
provide it already, I did not describe it at that time.
As well known, the meaning of multiple failures is “a single event may
impact multiple failures including scenarios of both “in single ring”
and “in multiple rings”. Multiple failures in one ring should be the
basic function.
--“fiber shared by multiple rings cut” in the ITU-T contribution gives
the example of multiple failures in multiple rings
-- "Micro-wave system impacted by whether and the nodes shared same
power supply system " in the mail I wrote to Adrian as following link
http://www.ietf.org/mail-archive/web/mpls/current/msg08804.html give
the good examples of multiple failures in single ring.

In one words, it is really essential function for MPLS-TP ring
protection to support the multiple failures in single ring.

B.R.
Cheng Weiqiang

2012/10/5 Daniele Ceccarelli <[email-masked]>:
> Hi Josh,
>
> in addition to what already said by Greg, the protection of interconnected
> rings is not in the scope of the ring protection applicability draft but in
> the scope of this one:
> Rogers, Josh
> Greg, when I read ITU document, I suspected the concern about 'multiple
> failures' was surrounding situations where a single event (fiber cut for
> instance) may impact multiple rings (imagine two rings entering a facility
> at the same entry, possibly same sheath).  The diagram showing failure
> points 1, 2, 3, and 4 seemed to me to be relatively close, where a single
> event could cause multiple impacts (break more than one ring).
>
> From: Gregory Mirsky <[email-masked]>
> To: cheng weiqiang <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> I would note that "multiple failure" scenario, illustrated in Annex 1  of
> liaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-networks,
> is, in my understanding, series of single failures in interconnected rings.
> I believe that protection architectures described in the document under
> discussion (wrapping, steering without and wit SPME) can be easily applied
> to interconnected ring topology as presented in the Annex 1. I've noticed
> that, referring to the Annex 1, that scenarios with dual failure on the same
> ring are not considered, i.e. failure at point 1 and 2 or 3 and 4. Should it
> be interpreted as "multiple failure" scenario implies failures in multiple
> interconnected rings over which a protected path spans but with only single
> failure in any given ring of the chain?
>
>         Regards,
>                 Greg
>
> And well known, the multi-failures recovery is a basic function for ring
> protection. And the double failures scenario I mentioned is the most basic
> multiple failures condition.
>

---

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

Cheng, hi

Thank you for you additional comment on the draft.

I would like to point out that there is a statement at the end of the
Introduction section that states that the considerations of interconnected
rings include very many scenarios and is for further study and should be
addressed in a separate document.

Hope this helps,
yaacov weingarten

*Still looking for new opportunity.*

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*