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

[Daniele Ceccarelli <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Rogers, Josh
Sent: giovedì 4 ottobre 2012 19.13
To: Gregory Mirsky; cheng weiqiang; [e-mail]
Cc: [e-mail]
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, October 4, 2012 11:46 AM
To: cheng weiqiang <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of cheng weiqiang
Sent: Thursday, October 04, 2012 4:02 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.

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





On Oct 3, 2012 11:28 PM, "Adrian Farrel" <[e-mail]<mailto:[e-mail]>> 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
>
> > -----Original Message-----
> > From: cheng weiqiang [mailto:[e-mail]]
> > Sent: 03 October 2012 15:53
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: Re: [mpls] Working group last call on
> draft-ietf-mpls-tp-ring-protection
> >
> > 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 <[e-mail]<mailto:[e-mail]>>:
> > > 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:[e-mail]]
> > >> Sent: 03 October 2012 10:40
> > >> To: [e-mail]<mailto:[e-mail]>
> > >> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> > >> draft-ietf-mpls-tp-ring- [e-mail]<mailto:[e-mail]>;
> > >> [e-mail]<mailto:[e-mail]>
> > >> 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
>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
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.