Subject: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 3 Sep 2008 10:39:29 +0200

Ben,
Hi Ben
      AFAIK the most interesting use case for this is multicast (video) distribution on metro/regional ring topology.

Typically there is a regional high capacity ring with several metro ring attached to it.  Both the metro and regional ring nodes can be connected to DSLAM that actually distribute the multicast (video) to end user.

So the situation in the ring is exactly the one depicted by John/Italo, that is, p2p LSP between adjacent nodes on the ring.

Now, even if I'm not a carrier, I think that the requirement is to protect (50ms?) the multicast traffic using less recovery bandwidth as possible.

Of course given that we are in mpls-tp environment that should be done without control plane and I suppose with the minimum complexity possible, I think that this can be read that the complexity should be moved at provisioning/planning stage and not during the life of the network.

Just my two cents

BR

Diego
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Niven-jenkins,B,Ben,DMF R
> Sent: martedì 2 settembre 2008 21.52
> To: Loa Andersson; Italo Busi
> Cc: [email-masked]
> Subject: Re: [mpls] [mpls-tp] RES: R: discussion on ring protection
> inMPLS-TP
> 
> let's take a step back.
> 
> Requirements exist based on a use/deployment case. What is the use case
> for rings - can someone articulate it clearly (if it has been presented
> elsewhere great we can reuse that).
> 
> From the use case we can distil the true requirements
> 
> From the requirements we can evaluate solutions.
> 
> It may be that the use/deployment case for mpls-tp may differ from sdh and
> so the requirements may be subtlely different. It may be that the nature
> of a packet based technology means that the requirements can be satisfied
> in an alternative way to in a circuit switched technology.
> 
> In any case let's start with a clearly define use/deployment case and work
> from there.
> 
> Ben
> 
> 
> -----Original Message-----
> From: "Loa Andersson" <[email-masked]>
> To: "Italo Busi" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: 02/09/2008 16:18
> Subject: Re: [mpls] [mpls-tp] RES: R: discussion on ring protection
> inMPLS-TP
> 
> Italo,
> 
> inline
> 
> Italo Busi wrote:
> > Salvio,
> >
> > "I think we need to start from the requirements ..."
> 
> that far I agree!
> 
> but I think what needs to be said in the second part of the
> sentence is
> 
> "... and not from the solutions ring protoection or FRR."
> 
> Also, since we are seeking MPLS compatibility, once we have the
> requirments we need to evaluate/analyze the existing mpls
> solutions to seee if they meet the requirements, and sedond
> build something new.
> 
> 
> /Loa
> >
> > Italo
> >
> >
> >   _____
> >
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Salvio Straube Stecz
> > Sent: Friday, August 29, 2008 4:29 PM
> > To: [email-masked]
> > Subject: [mpls-tp] RES: R: discussion on ring protection in MPLS-TP
> >
> >
> >
> > Hi all,
> >
> >         I think that for the MPLS-TP, the better protection scheme to be
> used is
> > fast-reroute - FRR. Comparing to SDH-like ring protection it can works
> like
> > MS-SPring, where is possible to achieve less than 50ms switching time,
> and the
> > use of the protection side of the ring to carry extra-traffic. There are
> already
> > equipment in the market that works with this idea.
> >
> >
> >
> >
> > rgds,
> > ------------------------------------------------
> >     Sálvio Straube Stecz
> >   GVT - Global Village Telecom
> >  Planning - Transport Networks
> >      +55 41 3022 - 9451
> >      +55 41 8848 - 3428
> >         [email-masked]
> > -----------------------------------------------
> >
> >
> >
> >
> >
> >
> > -----Mensagem original-----
> > De: [email-masked] [mailto:[email-masked]]Em nome de
> > Diego Caviglia
> > Enviada em: sexta-feira, 29 de agosto de 2008 10:38
> > Para: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Assunto: [mpls-tp] R: discussion on ring protection in MPLS-TP
> >
> >
> > Ciao Alessandro,
> >                            I think you made a good point.
> >
> > If, as stated in sveral documents, mpls-tp is going to replace sdh we
> > have to consider that most of the metro and metro core topology are ring
> > based.
> >
> > Br
> >
> > Diego
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> --
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                            [email-masked]
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 03 Sep 2008 10:57:37 +0100

So the requirement is then (stealing some text from a previous mail from
Adrian)

MPLS-TP XXX provide a protection mechanism that minimises the amount of
recovery bandwidth required when MPLS-TP nodes are arranged in a topology
that is ring shaped.

Where a ring shaped topology is defined as a set of MPLS-TP routers with
line-side order of two (and presumably the ability to add and drop data!)
arranged in a ring.

Where XXX is one of MUST, SHOULD, MAY (to be debated).

Ben

On 03/09/2008 09:39, "Diego Caviglia" <[email-masked]> wrote:

> Ben,
> Hi Ben
>       AFAIK the most interesting use case for this is multicast (video)
> distribution on metro/regional ring topology.
> 
> Typically there is a regional high capacity ring with several metro ring
> attached to it.  Both the metro and regional ring nodes can be connected to
> DSLAM that actually distribute the multicast (video) to end user.
> 
> So the situation in the ring is exactly the one depicted by John/Italo, that
> is, p2p LSP between adjacent nodes on the ring.
> 
> Now, even if I'm not a carrier, I think that the requirement is to protect
> (50ms?) the multicast traffic using less recovery bandwidth as possible.
> 
> Of course given that we are in mpls-tp environment that should be done without
> control plane and I suppose with the minimum complexity possible, I think that
> this can be read that the complexity should be moved at provisioning/planning
> stage and not during the life of the network.
> 
> Just my two cents
> 
> BR
> 
> Diego

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Sep 2008 06:22:56 -0700

Ben,

There is however a tradeoff between minimizing bandwidth and minimizing recovery time.  With facilities based FRR, you would minimize recovery time at the expense of wrapping the traffic back over the links between the failed link/node and the ring entry node.  With linear protection, the recovery time could be longer, but the recovery LSP would be directly between ring entry node and the ring exit node.

Thanks,

John   

>From: Ben Niven-Jenkins [mailto:[email-masked]] 
>Sent: Wednesday, September 03, 2008 2:58 AM
>To: Diego Caviglia; [email-masked]
>Subject: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP
>
>MPLS-TP XXX provide a protection mechanism that minimises the 
>amount of recovery bandwidth required when MPLS-TP nodes are 
>arranged in a topology that is ring shaped.
>
>Where a ring shaped topology is defined as a set of MPLS-TP 
>routers with line-side order of two (and presumably the 
>ability to add and drop data!) arranged in a ring.
>
>>       AFAIK the most interesting use case for this is multicast 
>> (video) distribution on metro/regional ring topology.
>> 
>> Typically there is a regional high capacity ring with several metro 
>> ring attached to it.  Both the metro and regional ring nodes can be 
>> connected to DSLAM that actually distribute the multicast 
>(video) to end user.
>> 
>> So the situation in the ring is exactly the one depicted by 
>> John/Italo, that is, p2p LSP between adjacent nodes on the ring.
>> 
>> Of course given that we are in mpls-tp environment that 
>should be done 
>> without control plane and I suppose with the minimum complexity 
>> possible, I think that this can be read that the complexity 
>should be 
>> moved at provisioning/planning stage and not during the life 
>of the network.
>> 
>> Just my two cents
>> 
>> BR
>> 
>> Diego
>>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>> Of Niven-jenkins,B,Ben,DMF R
>>> Requirements exist based on a use/deployment case. What is the use 
>>> case for rings - can someone articulate it clearly (if it has been 
>>> presented elsewhere great we can reuse that).
>>> 
>>> It may be that the use/deployment case for mpls-tp may differ from 
>>> sdh and so the requirements may be subtlely different. It 
>may be that 
>>> the nature of a packet based technology means that the requirements 
>>> can be satisfied in an alternative way to in a circuit 
>switched technology.
>>> 
>>> In any case let's start with a clearly define 
>use/deployment case and 
>>> work from there.
>>> 
>>> Ben
>>> 
>>> 
>sentence 
>>> is
>>> requirments we need to evaluate/analyze the existing mpls solutions 
>>> to seee if they meet the requirements, and sedond build something 
>>> new.
>>> 
>>> 
>>> /Loa
>>>> 
>>>> Italo
>>>> 
>>>> 
>>>>   _____
>>>> 
>>>> use of the protection side of the ring to carry 
>extra-traffic. There 
>>>> are
>>> already
>>>> De: [email-masked] [mailto:[email-masked]]Em 
>>>> nome de Diego Caviglia Enviada em: sexta-feira, 29 de 
>agosto de 2008 
>>>> 10:38
>>>> If, as stated in sveral documents, mpls-tp is going to replace sdh 
>>>> we have to consider that most of the metro and metro core topology 
>>>> are ring based.
>>>> 
>>>> Br
>>>> 
>>>> Diego

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Sep 2008 15:05:56 +0100

> There is however a tradeoff between minimizing bandwidth and minimizing recovery time.  With facilities based FRR, you would minimize recovery time at the expense of wrapping the traffic back over…
I think the optimised entry to exit case is the same as optimised ring 
protection (which I think is FFS), and I cannot see why there would be 
any difference in the recovery time.

In both cases you need to signal the entry points of the location of the 
failure, in both cases you have to modify exactly the same subset of 
entry LSPs.

So I would expect optimised  RP and LP to have exactly the same recovery 
performance, and that this would be significantly slower than 50ms.

Stewart

---

From: "D'Alessandro Alessandro" <[email-masked]>
Date: Wed, 3 Sep 2008 16:08:45 +0200

Hi Diego, hi all,
Multicast video distribution inside a metro area is one of the most interesting scenario to be studied about provisioning/resilience mechanisms because MPLS-TP can potentially offer interesting advantages respect to traditional CO-CS technologies (e.g. SDH).

Provisioning and resilience solutions that are efficient in terms of OAM&P from technical (simplicity) and economical (bandwidth minimization) point of view are of interest for every carriers.
In that sense p2p LSP between adjacent nodes on the ring could not be the best/only way to proceed taking into account that metro area architecture are often quite simple networks: INTERCONNECTED rings (metro core ring and many interconnected metro access rings).

I think there is still space for a discussion about requirements for OPTIMIZED resilience mechanisms at MPLS-TP level for
1. point to multipoint traffic (e.g. video distribution)
2. interconnected rings architecture

New solutions optimized for unicast traffic on interconnected rings architecture could not be so easy to identify but again it may be useful to be further investigated.

About control plane use for resilience purposes, I think it could be premature to exclude it at all. Anyway, you are right when you say that data plane based mechanisms to manage resilience is desirable.

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Diego Caviglia
Sent: mercoledì 3 settembre 2008 10.39
To: [email-masked]
Subject: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP

Ben,
Hi Ben

Just my two cents

BR

Diego
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Sep 2008 07:28:33 -0700

Stewart,

In the case of ring wrap, after detecting failure the upstream node can
place the traffic in the bypass LSP without notifying the ring entry
node.

In the case of linear protection, the upstream node either has to notify
the ring entry node node, or the ring entry node has to detect, e.g.,
using a BFD session between it and the ring exit node, a failure along
the path of the primary LSP, before it can place the traffic in the
protecting LSP.  Either of these will probably take longer than it would
take the upstream node to detect the failure.

(If the protecting LSP is instantiated as a secondary LSP, the ring
entry node will also have to signal to change its status to a primary
LSP before it can place traffic in it.)

Thanks,

John

P.S.  I should probably be using 'ingress/egress' rather than
'entry/exit'.

P.P.S.  It occurs to me that what I am describing is the uni-directional
LSP case.  For the bi-directional case, the upstream node also needs to
notify the node at the other end of the bypass or protecting LSP to
place traffic in that LSP.  Presumably, we would run APS in the control
channel?
  
>From: Stewart Bryant [mailto:[email-masked]] 
>Sent: Wednesday, September 03, 2008 7:06 AM
>To: Drake, John E
>Cc: Ben Niven-Jenkins; Diego Caviglia; [email-masked]
>> There is however a tradeoff between minimizing bandwidth and 
>minimizing recovery time.  With facilities based FRR, you 
>would minimize recovery time at the expense of wrapping the 
>traffic back over the links between the failed link/node and 
>the ring entry node.  With linear protection, the recovery 
>time could be longer, but the recovery LSP would be directly 
>between ring entry node and the ring exit node.
>>
>>   
>I think the optimised entry to exit case is the same as 
>optimised ring protection (which I think is FFS), and I cannot 
>see why there would be any difference in the recovery time.
>
>In both cases you need to signal the entry points of the 
>location of the failure, in both cases you have to modify 
>exactly the same subset of entry LSPs.
>
>So I would expect optimised  RP and LP to have exactly the 
>same recovery performance, and that this would be 
>significantly slower than 50ms.
>
>Stewart
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Sep 2008 16:16:41 +0100

John wrote..

> place traffic in that LSP.  Presumably, we would run APS in the control

Not sure why we would run APS.

For now, while we sort out the requirements, can we stick to functional 
abstract messages (see the RFC 4426/7/8 series). When we are agreed on the 
requirements we can look at what protocols and protocol messages we really 
want to use.

A

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Sep 2008 08:19:39 -0700

Oopsie.  Yes, let's use the correct terminology.  

>From: Adrian Farrel [mailto:[email-masked]] 
>Sent: Wednesday, September 03, 2008 8:17 AM
>To: Drake, John E; [email-masked]
>Cc: [email-masked]
>Subject: "APS"
>
>John wrote..
>
>> P.P.S.  It occurs to me that what I am describing is the 
>> uni-directional LSP case.  For the bi-directional case, the upstream 
>> node also needs to notify the node at the other end of the bypass or 
>> protecting LSP to place traffic in that LSP.  Presumably, we 
>would run 
>> APS in the control channel?
>
>For now, while we sort out the requirements, can we stick to 
>functional abstract messages (see the RFC 4426/7/8 series). 
>When we are agreed on the requirements we can look at what 
>protocols and protocol messages we really want to use.
>
>A 
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 03 Sep 2008 21:49:00 +0100

At the risk of being strung up and burned at the stake can I make a
suggestion and that is, given:

- the level of demand for ring protection expressed by service providers so
far seems to be low, and
- the level of work & number of documents being concurrently developed
related to MPLS-TP is currently high

That we de-scope ring protection for the time being and concentrate our
efforts on the baseline MPLS-TP specifications including linear protection.
That's not to say we don't revisit ring protection in the future and specify
requirements (and possibly solutions if the existing ones are not adequate).

I think we are at risk of "boiling the ocean" and trying to solve everything
in one go.  I am simply suggesting we concentrate on getting the baseline
documents completed first, see how we get on with respect to meeting the
deadlines we have set ourselves and then look to expand the initial scope if
there is desire to do so.  Otherwise we are at risk of trying to do too much
and not delivering something useable by the deadline we have set ourselves.

As a general note (which I know Adrian has made before) MPLS-TP is not part
of my day job and I only have limited cycles to spend on it so from my point
of view the areas to focus on would be those where there is the most
expressed interest and ring protection would appear to me to be low on that
list relative to other topics, so let's finish those topics off first.

<flame proof suit donned>

Ben

On 03/09/2008 15:08, "D'Alessandro Alessandro"
<[email-masked]> wrote:

> Hi Diego, hi all,
> Multicast video distribution inside a metro area is one of the most
> interesting scenario to be studied about provisioning/resilience mechanisms
> because MPLS-TP can potentially offer interesting advantages respect to
> traditional CO-CS technologies (e.g. SDH).
> 
> Provisioning and resilience solutions that are efficient in terms of OAM&P
> from technical (simplicity) and economical (bandwidth minimization) point of
> view are of interest for every carriers.
> In that sense p2p LSP between adjacent nodes on the ring could not be the
> best/only way to proceed taking into account that metro area architecture are
> often quite simple networks: INTERCONNECTED rings (metro core ring and many
> interconnected metro access rings).
> 
> 
> I think there is still space for a discussion about requirements for OPTIMIZED
> resilience mechanisms at MPLS-TP level for
> New solutions optimized for unicast traffic on interconnected rings
> architecture could not be so easy to identify but again it may be useful to be
> further investigated.
> 
> About control plane use for resilience purposes, I think it could be premature
> to exclude it at all. Anyway, you are right when you say that data plane based
> mechanisms to manage resilience is desirable.
> 
> 
> Best regards,
> Alessandro
> 
> This message and its attachments are addressed solely to the persons above and
> may contain confidential information. If you have received the message in
> error, be informed that any use of the content hereof is prohibited. Please
> return it immediately to the sender and delete the message. Should you have
> any questions, please contact us by replying to [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 03 Sep 2008 16:51:10 -0400

I would second this proposal. The MPLS-TP work needs to stay focused and
stop trying to boil the ocean.

    --Tom

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Sep 2008 13:55:46 -0700

What a great idea 

>Sent: Wednesday, September 03, 2008 1:49 PM
>To: D'Alessandro Alessandro; [email-masked]
>At the risk of being strung up and burned at the stake can I 
>make a suggestion and that is, given:
>
>- the level of demand for ring protection expressed by service 
>providers so far seems to be low, and
>- the level of work & number of documents being concurrently 
>developed related to MPLS-TP is currently high
>
>That we de-scope ring protection for the time being and 
>concentrate our efforts on the baseline MPLS-TP specifications 
>including linear protection.
>That's not to say we don't revisit ring protection in the 
>future and specify requirements (and possibly solutions if the 
>existing ones are not adequate).
>
>I think we are at risk of "boiling the ocean" and trying to 
>solve everything in one go.  I am simply suggesting we 
>concentrate on getting the baseline documents completed first, 
>see how we get on with respect to meeting the deadlines we 
>have set ourselves and then look to expand the initial scope 
>if there is desire to do so.  Otherwise we are at risk of 
>trying to do too much and not delivering something useable by 
>the deadline we have set ourselves.
>
>As a general note (which I know Adrian has made before) 
>MPLS-TP is not part of my day job and I only have limited 
>cycles to spend on it so from my point of view the areas to 
>focus on would be those where there is the most expressed 
>interest and ring protection would appear to me to be low on 
>that list relative to other topics, so let's finish those 
>topics off first.
>
>> interesting scenario to be studied about provisioning/resilience 
>> mechanisms because MPLS-TP can potentially offer interesting 
>> advantages respect to traditional CO-CS technologies (e.g. SDH).
>> 
>> Provisioning and resilience solutions that are efficient in terms of 
>> OAM&P from technical (simplicity) and economical (bandwidth 
>> minimization) point of view are of interest for every carriers.
>> In that sense p2p LSP between adjacent nodes on the ring 
>could not be 
>> the best/only way to proceed taking into account that metro area 
>> architecture are often quite simple networks: INTERCONNECTED rings 
>> (metro core ring and many interconnected metro access rings).
>> 
>> 
>> I think there is still space for a discussion about requirements for 
>> OPTIMIZED resilience mechanisms at MPLS-TP level for 1. point to 
>> multipoint traffic (e.g. video distribution) 2. interconnected rings 
>> architecture
>> 
>> architecture could not be so easy to identify but again it may be 
>> useful to be further investigated.
>> 
>> About control plane use for resilience purposes, I think it could be 
>> premature to exclude it at all. Anyway, you are right when you say 
>> that data plane based mechanisms to manage resilience is desirable.
>> 
>> 
>> Best regards,
>> Alessandro
>> 
>> Behalf Of Diego Caviglia
>>>> ----
>> This message and its attachments are addressed solely to the persons 
>> above and may contain confidential information. If you have received 
>> the message in error, be informed that any use of the content hereof 
>> is prohibited. Please return it immediately to the sender and delete 
>> the message. Should you have any questions, please contact 
>us by replying to [email-masked].
>> 
>>         Thank you
>> 
>>                                         www.telecomitalia.it
>>

---

From: "Yuji KAMITE" <[email-masked]>
Date: Thu, 04 Sep 2008 12:23:37 +0900

Folks,

I agree with lowering priority of ring protection.

Because ring protection has relatively limited applicatbility in terms of topology types.
We cannot apply it directly to non-ring physical networks (mesh, ladder, star and so on),
whereas linear protection can support them all.

In fact in the legacy tranport system (ATM, SDH), we have lots of operational
experience of path design and fault management that accounts for linear protection.
Ring protection can be used in metro but usually does not span wide area in SP's network.

Furthermore if we consider various approaches at the same time, It might delay
finalizing standardization and our service release.  We should avoid that.

So we can leave it as optional scope in the future at this moment.

Regards,
Yuji

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Thursday, September 04, 2008 5:49 AM
> - the level of demand for ring protection expressed by 
> service providers so far seems to be low, and
> concentrate our efforts on the baseline MPLS-TP 
> specifications including linear protection.
> future and specify requirements (and possibly solutions if 
> the existing ones are not adequate).
> 
> concentrate on getting the baseline documents completed 
> first, see how we get on with respect to meeting the 
> deadlines we have set ourselves and then look to expand the 
> initial scope if there is desire to do so.  Otherwise we are 
> at risk of trying to do too much and not delivering something 
> useable by the deadline we have set ourselves.
> 
> > moved at provisioning/planning stage and not during the 
> life of the network.
> > 
> > Just my two cents
> > 
> > BR
> > 
> > Diego
> >> but I think what needs to be said in the second part of 
> the sentence 
> >> is
> >> 
> solutions 
> >>>         I think that for the MPLS-TP, the better 
> protection scheme 
> >>> to be
> >> used is

---

From: hejia <[email-masked]>
Date: Thu, 04 Sep 2008 16:15:12 +0800

Hi all
   When I checked the source of this discussion (see attached Loa's mail),
the purpose is to find out opinions (especially from service providers) on
ring protection requirement. Following the long discussion thread, we DID
see some service providers/vendors presented their interest in ring
protection. How to evaluate this? Thanks.

B.R.
Jia

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yuji KAMITE
> Sent: Thursday, September 04, 2008 11:24 AM
> To: 'Ben Niven-Jenkins'; 'D'Alessandro Alessandro'; [email-masked]
> We cannot apply it directly to non-ring physical networks (mesh, ladder,
star
> and so on),
> Ring protection can be used in metro but usually does not span wide area
in
> SP's network.
> > [mailto:[email-masked]] On
> > >> Behalf Of
> > >>> Salvio Straube Stecz

Subject: [mpls-tp] the discussion on ring protection in Dublin
From: Loa Andersson <[email-masked]>
To: [email-masked]
Date: Fri, 08 Aug 2008 20:44:55 +0800

All,

we had a meeting in Dublin that was attended by members and of the MEAD
team and service providers.

Nurit captured note from the meeting (see below).

The possibly most important discussion in that meeting was on
MPLS ring protection. We asked the service providers whether ring 
protection were needed in MPLS-TP or not. Of the service providers
present at the meeting there were no one that required that
ring protection is included in MPLS-TP.

We also agreed some time for those service providers that did not
attend the meeting to voice their opinions. This mail is to invite
such opinions.

The decision whether ring protection is in or out will be taken in
early September.

/Loa

-------------------  notes from the meeting  -------------------------
Hi,

My quick take off from the meeting:

1.    There is a requirement for bi-directional LSPs.

a.    It is required that they are co-routed (for simple operation).

b.    We should not preclude non co-routed LSPs (as unidirectional fault
in 1+1 unidirectional protection switching (in case of bi-directional
LSPs) will result in non co-routed LSPs.

2.    uni-directional LSPs should not be precluded (although it was
stated that in many cases bi-directional LSP is set even for real
uni-directional traffic).

3.    50ms is requested basically for the migration from legacy/SDH
networks. This is the value customers are used to and will request for
(pre-condition to move from SDH to packet based networks).

4.    It was indicated that in physical rings it is required to apply
linear protection.

a.    Still we need to re-visit it as I am unsure that we can provide
protection for P2MP LSPs in physical ring topologies using linear
protection.

b.    It was decided to send a 'head up' to the list that since there
was no requirement for a dedicated mechanism for ring protection we
consider to drop the requirement. Italo asked to wait with the decision
until September and it was agreed to wait.

5.    It was indicated that revertive is required and that it serves
better than re-optimization.

I would like to thank the SPs for participating in the meeting.

It is extremely important to have a close dialogue. We need to
understand better the requirements in order to provide the best
solution.

Best regards,

Nurit

-- 
Loa Andersson

---

From: Lei Wang <[email-masked]>
Date: Thu, 4 Sep 2008 18:16:59 +0800

Dear all,
 
In my opinion, the main requirement of ring protection is come from the shared protection ring, such like the MS-SPRing in SDH, to increase the transmission resource utilization in the balanced traffic pattern.
Further, from a higher point of view, the final requirement is to protect and not how to protect. The ring protection is only one used in ring topology.

WANG Lei, Ph.D.--------------------------------Division of Network Technologies,Research Institute, China MobileEmail:[email-masked]: Thu, 4 Sep 2008 16:15:12 +0800From: [email-masked]: [email-masked]: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TPHi all   When I checked the source of this discussion (see attached Loa's mail),the purpose is to find out opinions (especially from service providers) onring protection requirement. Following the long discussion thread, we DIDsee some service providers/vendors presented their interest in ringprotection. How to evaluate this? Thanks. B.R.Jia > -----Original Message-----> From: [email-masked] [mailto:[email-masked]] On Behalf> Of Yuji KAMITE> Sent: Thursday, September 04, 2008 11:24 AM> To: 'Ben Niven-Jenkins'; 'D'Alessandro Alessandro'; [email-masked]> Subject: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP> > Folks,> > I agree with lowering priority of 
 ring protection.> > Because ring protection has relatively limited applicatbility in terms of> topology types.> We cannot apply it directly to non-ring physical networks (mesh, ladder,star> and so on),> whereas linear protection can support them all.> > In fact in the legacy tranport system (ATM, SDH), we have lots ofoperational> experience of path design and fault management that accounts for linear> protection.> Ring protection can be used in metro but usually does not span wide areain> SP's network.> > Furthermore if we consider various approaches at the same time, It mightdelay> finalizing standardization and our service release.  We should avoid that.> > So we can leave it as optional scope in the future at this moment.> > Regards,> Yuji> > > > -----Original Message-----> > From: [email-masked]> > [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins> > Sent: Thursday, September 04, 2008 5:49 AM> > To: D'Alessandro Alessandro; [email-masked]> > Su
 bject: Re: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP> >> > At the risk of being strung up and burned at the stake can I> > make a suggestion and that is, given:> >> > - the level of demand for ring protection expressed by> > service providers so far seems to be low, and> > - the level of work & number of documents being concurrently> > developed related to MPLS-TP is currently high> >> > That we de-scope ring protection for the time being and> > concentrate our efforts on the baseline MPLS-TP> > specifications including linear protection.> > That's not to say we don't revisit ring protection in the> > future and specify requirements (and possibly solutions if> > the existing ones are not adequate).> >> > I think we are at risk of "boiling the ocean" and trying to> > solve everything in one go.  I am simply suggesting we> > concentrate on getting the baseline documents completed> > first, see how we get on with respect to meeting the> > deadlines we have set o
 urselves and then look to expand the> > initial scope if there is desire to do so.  Otherwise we are> > at risk of trying to do too much and not delivering something> > useable by the deadline we have set ourselves.> >> > As a general note (which I know Adrian has made before)> > MPLS-TP is not part of my day job and I only have limited> > cycles to spend on it so from my point of view the areas to> > focus on would be those where there is the most expressed> > interest and ring protection would appear to me to be low on> > that list relative to other topics, so let's finish those> > topics off first.> >> > <flame proof suit donned>> >> > Ben> >> > On 03/09/2008 15:08, "D'Alessandro Alessandro"> > <[email-masked]> wrote:> >> > > Hi Diego, hi all,> > > Multicast video distribution inside a metro area is one of the most> > > interesting scenario to be studied about provisioning/resilience> > > mechanisms because MPLS-TP can potentially offer interestin
 g> > > advantages respect to traditional CO-CS technologies (e.g. SDH).> > >> > > Provisioning and resilience solutions that are efficient in> > terms of> > > OAM&P from technical (simplicity) and economical (bandwidth> > > minimization) point of view are of interest for every carriers.> > > In that sense p2p LSP between adjacent nodes on the ring> > could not be> > > the best/only way to proceed taking into account that metro area> > > architecture are often quite simple networks: INTERCONNECTED rings> > > (metro core ring and many interconnected metro access rings).> > >> > >> > > I think there is still space for a discussion about> > requirements for> > > OPTIMIZED resilience mechanisms at MPLS-TP level for 1. point to> > > multipoint traffic (e.g. video distribution) 2.> > interconnected rings> > > architecture> > >> > > New solutions optimized for unicast traffic on interconnected rings> > > architecture could not be so easy to identify but again it may be> > > useful t
 o be further investigated.> > >> > > About control plane use for resilience purposes, I think it> > could be> > > premature to exclude it at all. Anyway, you are right when you say> > > that data plane based mechanisms to manage resilience is desirable.> > >> > >> > > Best regards,> > > Alessandro> > >> > > -----Original Message-----> > > From: [email-masked] [mailto:[email-masked]] On> > > Behalf Of Diego Caviglia> > > Sent: mercoledì 3 settembre 2008 10.39> > > To: [email-masked]> > > Subject: Re: [mpls-tp] RES: R: discussion on ring> > protection inMPLS-TP> > >> > > Ben,> > > Hi Ben> > >       AFAIK the most interesting use case for this is multicast> > > (video) distribution on metro/regional ring topology.> > >> > > Typically there is a regional high capacity ring with several metro> > > ring attached to it.  Both the metro and regional ring nodes can be> > > connected to DSLAM that actually distribute the multicast> > (video) to end user.> > >> >
  > So the situation in the ring is exactly the one depicted by> > > John/Italo, that is, p2p LSP between adjacent nodes on the ring.> > >> > > Now, even if I'm not a carrier, I think that the requirement is to> > > protect> > > (50ms?) the multicast traffic using less recovery bandwidth> > as possible.> > >> > > Of course given that we are in mpls-tp environment that> > should be done> > > without control plane and I suppose with the minimum complexity> > > possible, I think that this can be read that the complexity> > should be> > > moved at provisioning/planning stage and not during the> > life of the network.> > >> > > Just my two cents> > >> > > BR> > >> > > Diego> > >> -----Original Message-----> > >> From: [email-masked] [mailto:[email-masked]]> > On Behalf> > >> Of Niven-jenkins,B,Ben,DMF R> > >> Sent: martedì 2 settembre 2008 21.52> > >> To: Loa Andersson; Italo Busi> > >> Cc: [email-masked]> > >> Subject: Re: [mpls] [mpls-tp] RES: R: discussion on ring
 > > protection> > >> inMPLS-TP> > >>> > >> let's take a step back.> > >>> > >> Requirements exist based on a use/deployment case. What is the use> > >> case for rings - can someone articulate it clearly (if it has been> > >> presented elsewhere great we can reuse that).> > >>> > >> From the use case we can distil the true requirements> > >>> > >> From the requirements we can evaluate solutions.> > >>> > >> It may be that the use/deployment case for mpls-tp may differ from> > >> sdh and so the requirements may be subtlely different. It> > may be that> > >> the nature of a packet based technology means that the> > requirements> > >> can be satisfied in an alternative way to in a circuit> > switched technology.> > >>> > >> In any case let's start with a clearly define> > use/deployment case and> > >> work from there.> > >>> > >> Ben> > >>> > >>> > >> -----Original Message-----> > >> From: "Loa Andersson" <[email-masked]>> > >> To: "Italo Busi" <[email-masked]>> > >> Cc
 : "[email-masked]" <[email-masked]>> > >> Sent: 02/09/2008 16:18> > >> Subject: Re: [mpls] [mpls-tp] RES: R: discussion on ring> > protection> > >> inMPLS-TP> > >>> > >> Italo,> > >>> > >> inline> > >>> > >> Italo Busi wrote:> > >>> Salvio,> > >>>> > >>> "I think we need to start from the requirements ..."> > >>> > >> that far I agree!> > >>> > >> but I think what needs to be said in the second part of> > the sentence> > >> is> > >>> > >> "... and not from the solutions ring protoection or FRR."> > >>> > >> Also, since we are seeking MPLS compatibility, once we have the> > >> requirments we need to evaluate/analyze the existing mpls> > solutions> > >> to seee if they meet the requirements, and sedond build something> > >> new.> > >>> > >>> > >> /Loa> > >>>> > >>> Italo> > >>>> > >>>> > >>>   _____> > >>>> > >>> From: [email-masked]> > [mailto:[email-masked]] On> > >> Behalf Of> > >>> Salvio Straube Stecz> > >>> Sent: Friday, August 29, 2008 4:29 PM> > >>> T
 o: [email-masked]> > >>> Subject: [mpls-tp] RES: R: discussion on ring protection> > in MPLS-TP> > >>>> > >>>> > >>>> > >>> Hi all,> > >>>> > >>>         I think that for the MPLS-TP, the better> > protection scheme> > >>> to be> > >> used is> > >>> fast-reroute - FRR. Comparing to SDH-like ring protection it can> > >>> works> > >> like> > >>> MS-SPring, where is possible to achieve less than 50ms switching> > >>> time,> > >> and the> > >>> use of the protection side of the ring to carry> > extra-traffic. There> > >>> are> > >> already> > >>> equipment in the market that works with this idea.> > >>>> > >>>> > >>>> > >>>> > >>> rgds,> > >>> ------------------------------------------------> > >>>     Sálvio Straube Stecz> > >>>   GVT - Global Village Telecom> > >>>  Planning - Transport Networks> > >>>      +55 41 3022 - 9451> > >>>      +55 41 8848 - 3428> > >>>         [email-masked]> > >>> -----------------------------------------------> > >>>> > >>>> > >>>> > >
 >>> > >>>> > >>>> > >>> -----Mensagem original-----> > >>> De: [email-masked] [mailto:[email-masked]]Em> > >>> nome de Diego Caviglia Enviada em: sexta-feira, 29 de> > agosto de 2008> > >>> 10:38> > >>> Para: [email-masked]> > >>> Cc: [email-masked]; [email-masked]> > >>> Assunto: [mpls-tp] R: discussion on ring protection in MPLS-TP> > >>>> > >>>> > >>> Ciao Alessandro,> > >>>                            I think you made a good point.> > >>>> > >>> If, as stated in sveral documents, mpls-tp is going to> > replace sdh> > >>> we have to consider that most of the metro and metro core> > topology> > >>> are ring based.> > >>>> > >>> Br> > >>>> > >>> Diego> > >>> _______________________________________________> > >>> mpls-tp mailing list> > >>> [email-masked]> > >>> https://www.ietf.org/mailman/listinfo/mpls-tp> > >>>> > >>>> > >>>> > >>>> > >>>> > --------------------------------------------------------------------> > >>> ----
 > > >>>> > >>> _______________________________________________> > >>> mpls-tp mailing list> > >>> [email-masked]> > >>> https://www.ietf.org/mailman/listinfo/mpls-tp> > >>> > >>> > >> --> > >> Loa Andersson> > >>> > >> Principal Networking Architect> > >> Acreo AB                           phone:  +46 8 632 77 14> > >> Isafjordsgatan 22                  mobile: +46 739 81 21 64> > >> Kista, Sweden                      email:  [email-masked]> > >>                                            [email-masked]> > >> _______________________________________________> > >> mpls mailing list> > >> [email-masked]> > >> https://www.ietf.org/mailman/listinfo/mpls> > >> _______________________________________________> > >> mpls mailing list> > >> [email-masked]> > >> https://www.ietf.org/mailman/listinfo/mpls> > > _______________________________________________> > > mpls-tp mailing list> > > [email-masked]> > > https://www.ietf.org/mailman/listinfo/mpls-tp> > > ------------------------
 --------------------------------------------> > >> > > CONFIDENTIALITY NOTICE> > >> > > This message and its attachments are addressed solely to> > the persons> > > above and may contain confidential information. If you have> > received> > > the message in error, be informed that any use of the> > content hereof> > > is prohibited. Please return it immediately to the sender> > and delete> > > the message. Should you have any questions, please contact> > us by replying to [email-masked].> > >> > >         Thank you> > >> > >                                         www.telecomitalia.it> > >> > > --------------------------------------------------------------------> > >> > > _______________________________________________> > > mpls-tp mailing list> > > [email-masked]> > > https://www.ietf.org/mailman/listinfo/mpls-tp> >> > _______________________________________________> > mpls-tp mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/mpls-tp> > 
 _______________________________________________> mpls-tp mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/mpls-tp--Forwarded Message Attachment--Date: Fri, 8 Aug 2008 20:44:55 +0800From: [email-masked]: [mpls-tp] the discussion on ring protection in DublinTo: [email-masked]

All,
we had a meeting in Dublin that was attended by members and of the MEADteam and service providers.
Nurit captured note from the meeting (see below).
The possibly most important discussion in that meeting was onMPLS ring protection. We asked the service providers whether ring protection were needed in MPLS-TP or not. Of the service providerspresent at the meeting there were no one that required thatring protection is included in MPLS-TP.
We also agreed some time for those service providers that did notattend the meeting to voice their opinions. This mail is to invitesuch opinions.
The decision whether ring protection is in or out will be taken inearly September.
/Loa
-------------------  notes from the meeting  -------------------------Hi,
My quick take off from the meeting:
1.    There is a requirement for bi-directional LSPs.
a.    It is required that they are co-routed (for simple operation).
b.    We should not preclude non co-routed LSPs (as unidirectional faultin 1+1 unidirectional protection switching (in case of bi-directionalLSPs) will result in non co-routed LSPs.
2.    uni-directional LSPs should not be precluded (although it wasstated that in many cases bi-directional LSP is set even for realuni-directional traffic).
3.    50ms is requested basically for the migration from legacy/SDHnetworks. This is the value customers are used to and will request for(pre-condition to move from SDH to packet based networks).
4.    It was indicated that in physical rings it is required to applylinear protection.
a.    Still we need to re-visit it as I am unsure that we can provideprotection for P2MP LSPs in physical ring topologies using linearprotection.
b.    It was decided to send a 'head up' to the list that since therewas no requirement for a dedicated mechanism for ring protection weconsider to drop the requirement. Italo asked to wait with the decisionuntil September and it was agreed to wait.
5.    It was indicated that revertive is required and that it servesbetter than re-optimization.
I would like to thank the SPs for participating in the meeting.
It is extremely important to have a close dialogue. We need tounderstand better the requirements in order to provide the bestsolution.
Best regards,
Nurit
-- Loa Andersson
Principal Networking ArchitectAcreo AB                           phone:  +46 8 632 77 14Isafjordsgatan 22                  mobile: +46 739 81 21 64Kista, Sweden                      email:  [email-masked]                                            [email-masked] mailing [email-masked]://www.ietf.org/mailman/listinfo/mpls-tp
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

---

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 4 Sep 2008 13:06:36 +0200

Hi all,
       I agree that developing standards similar to the SDH MS-SPRing is not a high priority task for mpls-tp group, nevertheless I think Alessandro's requirements are valid and we should consider it.

Here is the point from the Alessandro e-mail I was referring to.
> multipoint traffic (e.g. video distribution) 2. interconnected rings 

So my proposal is to address the ring protection (intended as mpls-tp version of the MS-SPRing) at a later date but take into consideration Alessandro's requirements now.

BR

Diego
> Sent: giovedì 4 settembre 2008 5.24
> star and so on),
> in SP's network.

---

From: hejia <[email-masked]>
Date: Thu, 04 Sep 2008 20:42:05 +0800

Agree. Let the requirements go first and we can compare the different
solutions and finally select one or more at a later stage.

B.R.
Jia

> Of Diego Caviglia
> Sent: Thursday, September 04, 2008 7:07 PM
> To: Yuji KAMITE; Ben Niven-Jenkins; D'Alessandro Alessandro;
[email-masked]
>        I agree that developing standards similar to the SDH MS-SPRing is
not
> a high priority task for mpls-tp group, nevertheless I think Alessandro's
> requirements are valid and we should consider it.
> 
> So my proposal is to address the ring protection (intended as mpls-tp
version
> of the MS-SPRing) at a later date but take into consideration Alessandro's
> requirements now.
> 
> BR
> 
> Diego
Behalf
> > Because ring protection has relatively limited applicatbility in terms
of
> > topology types.

---

From: "Yuji KAMITE" <[email-masked]>
Date: Thu, 04 Sep 2008 22:07:02 +0900

Hi,

> So my proposal is to address the ring protection (intended as 
> mpls-tp version of the MS-SPRing) at a later date but take 
> into consideration Alessandro's requirements now.
> 

Which requirement are you mentioning? 
To me the 1 and 2 look different requirements.

1 is about logical path of the traffic (p2mp-tree), but 2 is about
resiliance on a particular physical topology.  
Realizing resiliance in p2mp traffic does not always assume 
ring architecure.

Regards,
Yuji

> From: Diego Caviglia [mailto:[email-masked]] 
> Sent: Thursday, September 04, 2008 8:07 PM
> Subject: RE: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP
> 
> Hi all,
>        I agree that developing standards similar to the SDH 
> MS-SPRing is not a high priority task for mpls-tp group, 
> nevertheless I think Alessandro's requirements are valid and 
> we should consider it.
> 
> So my proposal is to address the ring protection (intended as 
> mpls-tp version of the MS-SPRing) at a later date but take 
> into consideration Alessandro's requirements now.
> 
> BR
> 
> Diego
> > Behalf Of Yuji KAMITE
> > of topology types.
> > We cannot apply it directly to non-ring physical networks (mesh, 
> > ladder, star and so on), whereas linear protection can support them 
> > all.
> > 
> > In fact in the legacy tranport system (ATM, SDH), we have lots of 
> > operational experience of path design and fault management that 
> > accounts for linear protection.
> > Furthermore if we consider various approaches at the same time, It 
> > might delay finalizing standardization and our service release.  We 
> > should avoid that.
> > 
> concentrate 
> > > our efforts on the baseline MPLS-TP specifications 
> including linear 
> > > protection.
> future and 
> > > specify requirements (and possibly solutions if the existing ones 
> > > are not adequate).
> > >
> > > I think we are at risk of "boiling the ocean" and trying to solve 
> > > everything in one go.  I am simply suggesting we concentrate on 
> > > getting the baseline documents completed first, see how we get on 
> > > with respect to meeting the deadlines we have set 
> ourselves and then 
> > > look to expand the initial scope if there is desire to do so.  
> > > Otherwise we are at risk of trying to do too much and not 
> delivering 
> > > something useable by the deadline we have set ourselves.
> > >
> MPLS-TP is 
> > > not part of my day job and I only have limited cycles to 
> spend on it 
> > > so from my point of view the areas to focus on would be 
> those where 
> > > there is the most expressed interest and ring protection would 
> > > appear to me to be low on that list relative to other topics, so 
> > > let's finish those topics off first.
> > >
> > > > Multicast video distribution inside a metro area is one of the 
> > > > most interesting scenario to be studied about 
> > > > provisioning/resilience mechanisms because MPLS-TP can 
> potentially 
> > > > offer interesting advantages respect to traditional 
> CO-CS technologies (e.g. SDH).
> > > >
> > > > New solutions optimized for unicast traffic on interconnected 
> > > > rings architecture could not be so easy to identify but 
> again it 
> > > > may be useful to be further investigated.
> > > >
> [mailto:[email-masked]] 
> > > > On Behalf Of Diego Caviglia
> > > > Typically there is a regional high capacity ring with several 
> > > > metro ring attached to it.  Both the metro and regional 
> ring nodes 
> > > > can be connected to DSLAM that actually distribute the multicast
> > > (video) to end user.
> > > >
> > > > Now, even if I'm not a carrier, I think that the 
> requirement is to 
> > > > protect
> > > >> Requirements exist based on a use/deployment case. What is the 
> > > >> use case for rings - can someone articulate it clearly 
> (if it has 
> > > >> been presented elsewhere great we can reuse that).
> > > >>
> > > >> It may be that the use/deployment case for mpls-tp may differ 
> > > >> from sdh and so the requirements may be subtlely different. It
> > > may be that
> > > >>> fast-reroute - FRR. Comparing to SDH-like ring 
> protection it can 
> > > >>> works
> > > >> like
> > > >>> MS-SPring, where is possible to achieve less than 
> 50ms switching 
> > > >>> time,
> > > >> and the

---

From: David Sinicrope <[email-masked]>
Date: Thu, 4 Sep 2008 06:38:35 -0700

I agree. Let's follow Ben's suggestion and table ring protection for now ensuring that we consider Alessandro's requirements when we pick it up again.
-Dave

On 9/4/08 7:06 AM, "Diego Caviglia" <[email-masked]> wrote:

Hi all,

BR

Diego
> operational

---

From: "D'Alessandro Alessandro" <[email-masked]>
Date: Fri, 5 Sep 2008 18:14:44 +0200

Actually I just tried to draw your attention on a specific service scenario carriers are facing with. You can easily get requirements from that, e.g. at least:

1. MPLS-TP resilience mechanisms for point to multipoint traffic (e.g. video distribution) must be specified
2. MPLS-TP resilience mechanisms for point to multipoint traffic must recover as quick as possible (next step will be to set how fast)

Taking into account that
1. first deployments of MPLS-TP might occur inside metro areas
2. such areas are shaped as interconnected rings
... then it could be easier to find a way to get a solution that can match above requirements than satisfy the same requirements for a generic network (e.g. meshed) where deployment could not be in the near future.

best regards,
Alessandro

-----Original Message-----

From: Yuji KAMITE [mailto:[email-masked]]
Sent: giovedì 4 settembre 2008 15.07
To: 'Diego Caviglia'; 'Ben Niven-Jenkins'; D'Alessandro Alessandro; [email-masked]
Subject: RE: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP

Hi,

Regards,
Yuji

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: <[email-masked]>
Date: Fri, 5 Sep 2008 18:39:02 +0200

Ciao Alessandro.

I agree with your requirements but I must disagree with your last point. The fact that metro areas may be currently shaped as rings does not mean that they will be when moving to another technology. One can modify the topology by using the underlying optical layer while keeping the same fibers, thus allowing to tailor new topologies to actual traffic distribution... which is far from being only P2MP.

As a result, for the time being, I would prefer to focus effort on generic recovery schemes rather than ring-specific.

Regards and good week-end,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro

Taking into account that

best regards,
Alessandro

-----Original Message-----

Hi,

Regards,
Yuji

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 8 Sep 2008 09:31:48 +0200

Hi Julien, hi Alessandro,
                         Hi think that both of are right.

It is true that some of the existing ring topologies could be upgraded to mesh either using optical layer or delivering new fiber nevertheless is also true that some of that ring topology won't change.  There are some hundred of thousand of SONET/SDH ring out of there so is not so unlikely that ring topology will play some role, may be not the most important role, in NGN.

It seems to me that no one here is proposing to slow down the definition of linear protection to address the Alessandro requirements (let me call it for sake of simplicity) but if a bunch of vendors and carriers want to study a little bit more this problem I think is a good thing for the community.

So IMHO we can stop here the discussion on the list and go on off-line with this study.

May be at next IETF we'll have some ID explaining a little bit better the problem and the foreseen problems, if any, with the proposed solutions.

BR

Diego

> From: [email-masked] [mailto:julien.meuric@orange-
> ftgroup.com]
> Sent: venerdì 5 settembre 2008 18.39
> To: [email-masked]; [email-masked]; Diego
> Caviglia; [email-masked]; [email-masked]
> I agree with your requirements but I must disagree with your last point.
> The fact that metro areas may be currently shaped as rings does not mean
> that they will be when moving to another technology. One can modify the
> topology by using the underlying optical layer while keeping the same
> fibers, thus allowing to tailor new topologies to actual traffic
> distribution... which is far from being only P2MP.
> 
> As a result, for the time being, I would prefer to focus effort on generic
> recovery schemes rather than ring-specific.
> 
> Of D'Alessandro Alessandro
> 
> Actually I just tried to draw your attention on a specific service
> scenario carriers are facing with. You can easily get requirements from
> that, e.g. at least:
> 
> 2. MPLS-TP resilience mechanisms for point to multipoint traffic must
> recover as quick as possible (next step will be to set how fast)
> 
> Taking into account that
> ... then it could be easier to find a way to get a solution that can match
> above requirements than satisfy the same requirements for a generic
> network (e.g. meshed) where deployment could not be in the near future.
> 
> best regards,
> Alessandro
> 
> This message and its attachments are addressed solely to the persons above
> and may contain confidential information. If you have received the message
> in error, be informed that any use of the content hereof is prohibited.
> Please return it immediately to the sender and delete the message. Should
> you have any questions, please contact us by replying to
> [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 08 Sep 2008 13:12:37 +0200

Ciao Diego,

> May be at next IETF we'll have some ID explaining a little bit better the problem and the foreseen problems, if any, with the proposed solutions.

It may be worth while to look at draft-caviglia-GMPLS-MSSPRing-Req
for an explanation of the operation of shared protectiong in a ring.

Kind regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 8 Sep 2008 08:17:39 -0400

I also agree here.

Cheers,
Andy

On 9/4/08, David Sinicrope <[email-masked]> wrote:
>
>  I agree. Let's follow Ben's suggestion and table ring protection for now
> ensuring that we consider Alessandro's requirements when we pick it up
> again.
>  -Dave
>
>
>
> not a high priority task for mpls-tp group, nevertheless I think
> Alessandro's requirements are valid and we should consider it.
>
> version of the MS-SPRing) at a later date but take into consideration
> Alessandro's requirements now.
>
>  BR
>
>  Diego
> [mailto:[email-masked]] On Behalf
>  > Of Yuji KAMITE

---

From: "D'Alessandro Alessandro" <[email-masked]>
Date: Mon, 8 Sep 2008 17:18:42 +0200

Dear Julien,

Probably my sentence was not so clear.
I'm not asking to focus our effort on a specific topology.

As the discussion is about to drop or not to drop studies about ring topology based resilience schemes (at least at a first stage) my sentence wanted to highlight that such kind of topology could be one of the most exploited by packet transport in the near future and therefore it is of worth to spend some time to specify requirements and evaluate possible solutions.

About the possibility to change metro area architecture (e.g. making use of an underlying optical layer as you say) it is possible but you always have to take into account relationships between logical and physical topologies especially when you want to manage resilience in an effective way.

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: venerdì 5 settembre 2008 18.39
To: D'Alessandro Alessandro; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RES: R: discussion on ring protection inMPLS-TP

Ciao Alessandro.

Julien

-----Original Message-----

Taking into account that

best regards,
Alessandro

-----Original Message-----

Hi,

Regards,
Yuji

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Loa Andersson <[email-masked]>
Date: Mon, 08 Sep 2008 18:44:13 +0200

Alessandro et.al,

I tried to correct a very small misunderstanding below with my
working group chair hat on.

D'Alessandro Alessandro wrote:
> As the discussion is about to drop or not to drop studies 
> about ring topology based resilience schemes (at least at
> a first stage) my sentence wanted to highlight that such
> kind of topology could be one of the most exploited by packet
> transport in the near future and therefore it is of worth to
> spend some time to specify requirements and evaluate possible
> solutions.

I could agree with you "studies" of are interesting, and we are
in no way dis-encouraging such studies. And we done such studies
in the past.

However, we work against a very tough dead-line; RFCs  ready Oct 2009.

Therefore it is important that we, i.e. the IETF MPLS-TP effort as
driven by the MEAD team and specified by in the decision by the JWT
focus on what is absolutely necessary.

Now, ring protection was included in the JWT decision, but when we
started to evaluate those requirements we couldn't find any service
provider that has said that MPLS-TP is a requirement in the Oct 2009
time frame.

We therefore have suggested that the MEAD team don't (as part of its
effort) progress the Ring protection frame.

Any individual study on ring protection requirements is perfectly within
scope, but it won't get the same preferential treatment as the documents
that the MEAD team is working on.

I also hold that I think it would be better if the resources we have
concentrated on delivering the documents that we agreed on.

>From my point of view it is a decision that the MEAD team will drop the
ring protection framedwork, but I've also asked Malcolm to confirm it on
the ITU-T lists.

Hopefully the discussion on a ring protection document in the Oct 2009
ends here and a focused work on the other documents are reflected on
this list.

/Loa

-- 
Loa Andersson