Subject: [mpls] Is m:n protection a critical requirement?

From: Pablo Frank <[email-masked]>
Date: Wed, 27 Jul 2011 09:36:24 -0400

There was a question raised in monday's WG meeting as to whether there was a
strong use-case for m:n protection.  A related question was whether m:n has
been standardized in the OTN / SONET world.  After we consulted our OTN
experts back at the ranch, the general consensus is that while 1+1 and 1:n
are well standardized by the ITU-T, m:n is typically left for further study.
 There are proprietary solutions, including our own, but they don't seem to
be widely deployed.  I didn't get a specific m:n use-case.  I suspect that
any m:n use-case is probably better handled with shared-mesh protection
anyway.

It seems that m:n shows up in all the standards, mainly for theoretical
completeness, but never ends up being specified.

Based on this, I don't think we should slow-down the current 1:n
standardization effort by requiring the authors to embark on an m:n science
project.

Pablo Frank
Ciena

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 27 Jul 2011 20:01:35 +0300

Hi Pablo,

When you write "...m:n use-case is probably better handled with
shared-mesh protection...", are you talking about a particular m:n
mechanism/standard? Can you pls specify?

DC

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pablo Frank
Sent: Wednesday, July 27, 2011 9:36 AM
To: [email-masked]
Subject: [mpls] Is m:n protection a critical requirement?

There was a question raised in monday's WG meeting as to whether there
was a strong use-case for m:n protection.  A related question was
whether m:n has been standardized in the OTN / SONET world.  After we
consulted our OTN experts back at the ranch, the general consensus is
that while 1+1 and 1:n are well standardized by the ITU-T, m:n is
typically left for further study.  There are proprietary solutions,
including our own, but they don't seem to be widely deployed.  I didn't
get a specific m:n use-case.  I suspect that any m:n use-case is
probably better handled with shared-mesh protection anyway.

Based on this, I don't think we should slow-down the current 1:n
standardization effort by requiring the authors to embark on an m:n
science project.

Pablo Frank

Ciena

---

From: Pablo Frank <[email-masked]>
Date: Wed, 27 Jul 2011 15:31:19 -0400

Hi Daniel,

Sorry, I wasn't particularly clear.  I was just inserting some of my own
intuition (i.e. I can't imagine any realistic use-case for m:n).  There's no
standard mechanism for m:n so really nothing that we can evaluate against.
 When I asked our experts if we've ever encountered m:n use-cases in our OTN
or sonet deployments, the response was that we always just solved the
problem using shared mesh protection (of which we've deployed tonnes).

cheers,
Pablo

On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn <[email-masked]> wrote:

> Hi Pablo,****
>
> ** **
>
> When you write “…m:n use-case is probably better handled with shared-mesh
> protection…”, are you talking about a particular m:n mechanism/standard? Can
> you pls specify?****
>
> ** **
>
> DC****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Pablo Frank
> *Sent:* Wednesday, July 27, 2011 9:36 AM
> *To:* [email-masked]
> *Subject:* [mpls] Is m:n protection a critical requirement?****
>
> ** **
>
> There was a question raised in monday's WG meeting as to whether there was
> a strong use-case for m:n protection.  A related question was whether m:n
> has been standardized in the OTN / SONET world.  After we consulted our OTN
> anyway.****
> ** **
> completeness, but never ends up being specified.****
>
> ** **
>
> project.****
> ** **
> Pablo Frank****
> Ciena  ****
> ** **

---

From: [email-masked]
Date: Thu, 28 Jul 2011 06:34:10 +0800

Hi Pablo

I am not sure I catch  the discussion....

The requirements of MPLS-TP do not include m;n [RFC5654], and it is clealy 
stated in the section 4.3.2 of the document [tp-survive-fwk] as blow:

"Note that there is no requirement for m:n recovery in the list of MPLS-TP 
requirements documented in [RFC5654]".

As to the shared mesh protection, G.smp is developing now in ITU-T, 
inlcuding packet and circuit solutions, and there are several individual 
documents now in MPLS WG.

Best regards

Fei

Pablo Frank <[email-masked]> 
发件人:  [email-masked]
2011-07-28 03:31

收件人
Daniel Cohn <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls] Is m:n protection a critical requirement?

Hi Daniel,

Sorry, I wasn't particularly clear.  I was just inserting some of my own 
intuition (i.e. I can't imagine any realistic use-case for m:n).  There's 
no standard mechanism for m:n so really nothing that we can evaluate 
against.  When I asked our experts if we've ever encountered m:n use-cases 
in our OTN or sonet deployments, the response was that we always just 
solved the problem using shared mesh protection (of which we've deployed 
tonnes).

cheers,
Pablo

When you write “…m:n use-case is probably better handled with 
shared-mesh protection…”, are you talking about a particular m:n 
mechanism/standard? Can you pls specify?
 
DC

There was a question raised in monday's WG meeting as to whether there was 
a strong use-case for m:n protection.  A related question was whether m:n 
has been standardized in the OTN / SONET world.  After we consulted our 
OTN experts back at the ranch, the general consensus is that while 1+1 and 
1:n are well standardized by the ITU-T, m:n is typically left for further 
study.  There are proprietary solutions, including our own, but they don't 
seem to be widely deployed.  I didn't get a specific m:n use-case.  I 
suspect that any m:n use-case is probably better handled with shared-mesh 
protection anyway.

 
Pablo Frank
Ciena  
 
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Pablo Frank <[email-masked]>
Date: Thu, 28 Jul 2011 10:18:49 -0400

Well, I think that pretty much settles it then.  There had been a suggestion
made in the wg meeting that m:n should be addressed by the 1:n protection
draft, under the assumption that m:n was a requirement for MPLS-TP and that,
intuitively, m:n was a more general case of 1:n.  However, as you've now
correctly pointed out, m:n was never a requirement of MPLS-TP.  From a
practical implementation perspective, there is a significant jump in
complexity between 1:n and m:n so it seems unreasonable to me to expect the
1-to-n draft to address this solution (especially given that it is not a
requirement).  I think there is greater potential in bringing the 1:n
proposal closer to the original 1:1 linear protection, rather than the other
way.

regards,
Pablo

2011/7/27 <[email-masked]>

> requirements documented in [*RFC5654* <http://tools.ietf.org/html/rfc5654>
> ]".
>
>  *Pablo Frank <[email-masked]>*
> On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn <[email-masked]*<[email-masked]>>
> wrote:
> Hi Pablo,
>
>
>
> you pls specify?
> *From:* [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] *On Behalf Of *Pablo Frank
> *
> Sent:* Wednesday, July 27, 2011 9:36 AM*
> To:* [email-masked]* <[email-masked]>*
> Subject:* [mpls] Is m:n protection a critical requirement?
>
>
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 28 Jul 2011 09:24:25 -0500

I agree that there's no requirement to provide an m:n solution, and as
such I'm inclined to stay away from providing it, at least until we're
well and truly done with 1:1, 1:n and shared mesh.

eric

> -----Original Message-----
> Sent: Wednesday, July 27, 2011 3:31 PM
> To: Daniel Cohn
> Cc: [email-masked]
> Subject: Re: [mpls] Is m:n protection a critical requirement?
> 
> Hi Daniel,
> 
> 	From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Pablo Frank
> 	There was a question raised in monday's WG meeting as to whether
> there was a strong use-case for m:n protection.  A related question
was
> consulted our OTN experts back at the ranch, the general consensus is
that
> while 1+1 and 1:n are well standardized by the ITU-T, m:n is typically
> left for further study.  There are proprietary solutions, including
our
> own, but they don't seem to be widely deployed.  I didn't get a
specific
> m:n use-case.  I suspect that any m:n use-case is probably better
handled
> with shared-mesh protection anyway.
> 
> 
> 
> 	It seems that m:n shows up in all the standards, mainly for
> theoretical completeness, but never ends up being specified.
> 
> 
>

---

From: [email-masked]
Date: Thu, 28 Jul 2011 22:30:55 +0800

Hi Pablo

Yeah, surely. 1:n proposal will be closeer to the 1:1 linear protection

Thanks

Fei

2011-07-28 22:18

收件人
[email-masked]
抄送
Daniel Cohn <[email-masked]>, [email-masked], [email-masked]
主题
Re: [mpls] Is m:n protection a critical requirement?

Well, I think that pretty much settles it then.  There had been a 
suggestion made in the wg meeting that m:n should be addressed by the 1:n 
protection draft, under the assumption that m:n was a requirement for 
MPLS-TP and that, intuitively, m:n was a more general case of 1:n. 
However, as you've now correctly pointed out, m:n was never a requirement 
of MPLS-TP.  From a practical implementation perspective, there is a 
significant jump in complexity between 1:n and m:n so it seems 
unreasonable to me to expect the 1-to-n draft to address this solution 
(especially given that it is not a requirement).  I think there is greater 
potential in bringing the 1:n proposal closer to the original 1:1 linear 
protection, rather than the other way.

regards,
Pablo

Hi Pablo 

Best regards 

Fei 

收件人

Hi Daniel, 

cheers, 
Pablo

  
DC 

 

Pablo Frank 
Ciena