Subject: [mpls-tp] Why do we need both wrapping and steering for ring protection?

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 04:06:20 +0200

Hi all,
The subject of this message says it all...

Regards,
     Sasha

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Nov 2009 02:09:43 -0000

It is a question of trade-offs. Since the techniques clearly have different 
performance characteristics.

It is not clear (IMHO) that both are needed. I think we need to quantify the 
characteristics to understand whether the different optimisations that each 
scheme provides are sufficiently significant to make a difference.

Hoping that the authors of the many ring protection I-Ds can work on this in 
a relatively honest and non-partisan way.

Adrian
----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 11, 2009 2:06 AM
Subject: [mpls-tp] Why do we need both wrapping and steering for 
ringprotection?

Hi all,

Regards,
     Sasha

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

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 04:13:24 +0200

Adrian,
>From your email:
<quote>
	It is not clear (IMHO) that both are needed. 
<end quote>
Glad to hear that I am not the only one to whom it is not clear...

My 2c,
     Sasha
> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, November 11, 2009 4:10 AM
> To: Alexander Vainshtein; [email-masked]
> Subject: Re: [mpls-tp] Why do we need both wrapping and 
> steering for ringprotection?
>

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 11 Nov 2009 03:15:14 +0100

Sasha, hi

I certainly support Adrian's hope for the unification "in a relatively
honest and non-partisan way".

We do not think that we need both wrapping and steering.  We think that
steering is the more appropriate method for packet-switched networks,
however there may be special cases where wrapping may be better for a
particular application.

BR,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Adrian Farrel
Sent: Wednesday, November 11, 2009 04:10
To: Alexander Vainshtein; [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering
forringprotection?

It is a question of trade-offs. Since the techniques clearly have
different 
performance characteristics.

It is not clear (IMHO) that both are needed. I think we need to quantify
the 
characteristics to understand whether the different optimisations that
each 
scheme provides are sufficiently significant to make a difference.

Hoping that the authors of the many ring protection I-Ds can work on
this in 
a relatively honest and non-partisan way.

Adrian
----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 11, 2009 2:06 AM
Subject: [mpls-tp] Why do we need both wrapping and steering for 
ringprotection?

Hi all,

Regards,
     Sasha

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 04:19:39 +0200

Yaacov,
Lots of thanks for a prompt and informative response.
I tend to think that steering is one that should go away (based on wide acceptance of FRR-Facility
which is what wrapping seems to be about).

I would be happy to hear what other people on the list think about it.

Regards,
     Sasha

> From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: Wednesday, November 11, 2009 4:15 AM
> To: Adrian Farrel; Alexander Vainshtein; [email-masked]
> Subject: RE: [mpls-tp] Why do we need both wrapping and 
> steering forringprotection?
> 
> Sasha, hi
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 11 Nov 2009 03:20:55 +0100

Hi,

   I agree with Adrian so I also think we should agree on the parameters the have to trade off and try to evaluate the different solution among these parameters.

IMHO as parameters, we have:

*         Recovery time

*         Implementation Effort

*         Scalability

*         Bandwidth usage.

Of course carriers to not care about point 2 but care about the other points e.g. it is worth to have bandwidth waste for some 10s of millisecond in improved recovery performance?

The point that i'm missing here is what are the applications we are trying to address i mean applications that are neither present in mpls nor in mesh network with mpls-tp.

BR

Diego

 

 line

DIEGO CAVIGLIA 

Strategic Product Manager 

Ericsson Italy

Product Line PAIB

Via A. Negrone 1/A

Genoa, Italy

Phone +390106003736

Mobile +393357181762

[email-masked]

www.ericsson.com 

 Ericsson

 

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: mercoledì 11 novembre 2009 3.10
To: Alexander Vainshtein; [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Adrian

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

To: <[email-masked]>

ringprotection?

Hi all,

Regards,

     Sasha

 

mpls-tp mailing list

[email-masked]

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 11 Nov 2009 03:25:23 +0100

Sasha
     As far as i've understood the steering is about 1:1 that is also accepted as mpls(-tp) recovery.

BR

D

 line

DIEGO CAVIGLIA 

Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762

 Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: mercoledì 11 novembre 2009 3.20
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Yaacov,

Regards,
     Sasha

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Tue, 10 Nov 2009 22:02:32 -0600

Actually, my understanding of wrapping as proposed in draft-umansky-mpls-tp-ring-protection-switching says something different:
- It looks like wrapping doesn't do a label push, requiring the same number of protection LSPs to exist for the working LSPs.  I assume was done to allow non-protected LSPs to fail when the link failure occurs, as well as to allow differing QoS to be provided on the protection LSP..
- It also looks like wrapping requires the merge point to be at the exact other side of the link being protected.

FRR-Facility does a label push so that only one Bypass LSP is required and the merge point is only required to "intersect the working LSP" somewhere downstream.  So while wrapping seems similar, it is really different.

Looking further at the steering - it seems to be the same as FRR's one-to-one backup method.

I can see wrapping providing some simplicity because the protection LSP path is easy to identify. However, CAC will still need to be done for that LSP...

At the same time, steering in a topology that is richer than a ring would allow for diverse path computation to be used to identify its path.

My question: why was wrapping not specified to do a label push?

Thanks,

Jonathan Sadler

Jonathan Sadler

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Alexander Vainshtein [[email-masked]]
Sent: Tuesday, November 10, 2009 8:19 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Yaacov,

Regards,
     Sasha

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Nov 2009 04:21:31 -0000

I think this was the question at the mic on one of the drafts and implicitly 
applying to all the protection drafts (I certainly heard at least one author 
of another I-D say he registered the point)...

We do need to describe the precise data plane behavior for all of these 
proposals so that we can fairly evaluate them. This is obviously a job for 
the authors of the different drafts.

A
----- Original Message ----- 
From: "Sadler, Jonathan B." <[email-masked]>
To: "Alexander Vainshtein" <[email-masked]>; 
"Weingarten,Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 11, 2009 4:02 AM
Subject: Re: [mpls-tp] Why do we need both wrapping and steering 
forringprotection?

> Actually, my understanding of wrapping as proposed in 
> draft-umansky-mpls-tp-ring-protection-switching says something different:
> - It looks like wrapping doesn't do a label push, requiring the same 
> number of protection LSPs to exist for the working LSPs.  I assume was 
> done to allow non-protected LSPs to fail when the link failure occurs, as 
> well as to allow differing QoS to be provided on the protection LSP..
> FRR-Facility does a label push so that only one Bypass LSP is required and 
> the merge point is only required to "intersect the working LSP" somewhere 
> downstream.  So while wrapping seems similar, it is really different.
>
> I can see wrapping providing some simplicity because the protection LSP 
> path is easy to identify. However, CAC will still need to be done for that 
> LSP...
>
> At the same time, steering in a topology that is richer than a ring would 
> allow for diverse path computation to be used to identify its path.
>
> From: [email-masked] [[email-masked]] On Behalf Of 
> Alexander Vainshtein [[email-masked]]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 11 Nov 2009 05:36:30 +0100

Hi Jonathan,

1.    The protection LSP in the wrapping mode in draft-umansky forms a
closed loop. We do not have such a construct in MPLS. This actually
creates a MP2MP LSP with much ingress and egress points. 

2.    Also, it is not clear from draft-umansky, how they protect against
a node failure in the wrapping mode. 

3.    It is not clear how it behave in case of specific multiple
failures over the ring in case of wrapping. Also it is not clear what
happens with the APS message is coin case of node failure. In which mode
they work one-phase or two-phase mode of coordination. 

4.    A challengeable issue with wrapping is really the BW allocation
per LSP. 

Best regards,

Nurit 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Sadler, Jonathan B.
Sent: Wednesday, November 11, 2009 6:03 AM
To: Alexander Vainshtein; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering
forringprotection?

Actually, my understanding of wrapping as proposed in
draft-umansky-mpls-tp-ring-protection-switching says something
different:

- It looks like wrapping doesn't do a label push, requiring the same
number of protection LSPs to exist for the working LSPs.  I assume was
done to allow non-protected LSPs to fail when the link failure occurs,
as well as to allow differing QoS to be provided on the protection LSP..

- It also looks like wrapping requires the merge point to be at the
exact other side of the link being protected.

FRR-Facility does a label push so that only one Bypass LSP is required
and the merge point is only required to "intersect the working LSP"
somewhere downstream.  So while wrapping seems similar, it is really
different.

Looking further at the steering - it seems to be the same as FRR's
one-to-one backup method.

I can see wrapping providing some simplicity because the protection LSP
path is easy to identify. However, CAC will still need to be done for
that LSP...

At the same time, steering in a topology that is richer than a ring
would allow for diverse path computation to be used to identify its
path.

Thanks,

Jonathan Sadler

Jonathan Sadler

Cc: [email-masked]

Yaacov,

I tend to think that steering is one that should go away (based on wide
acceptance of FRR-Facility

Regards,

     Sasha

> We do not think that we need both wrapping and steering.  We

> think that

> It is not clear (IMHO) that both are needed. I think we need

> to quantify

> --------------------------------------------------------------

> ----------

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 11 Nov 2009 05:41:29 +0100

Ciao Diego,

You wrote:

> Sasha
>      As far as i've understood the steering is about 1:1
 > that is also accepted as mpls(-tp) recovery.

Note that in ring protection wrapping is also 1:1, because the
protection bandwidth is shared.

Steering was introduced in co-cs when SPRing is used on
trans-oceanic connetions because it reduces the latency
when protection is activated.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 06:46:38 +0200

Nurit and all,
Per-LSP BW allocation (for FRR 1:1 backup mode) vs. improved scalability (for FRR facility mode) is a well-known trade-off point
in MPLS. My impression has been that the industry has, so far, made its choice for scalability. But I admit that MPLS-TP
users may see things differently.

I wonder if

 1.  My interpretation of steering vs. wrapping as the ITU-T equivalents of FRR 1:1 vs Facility modes is correct
 2.  (assuming a positive answer to the previous question) this is recorded in the Rosetta stone draft.

My 2c,
     Sasha

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Sent: Wednesday, November 11, 2009 6:37 AM
To: ext Sadler, Jonathan B.; Alexander Vainshtein; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Hi Jonathan,

1.    The protection LSP in the wrapping mode in draft-umansky forms a closed loop. We do not have such a construct in MPLS. This actually creates a MP2MP LSP with much ingress and egress points.

2.    Also, it is not clear from draft-umansky, how they protect against a node failure in the wrapping mode.

3.    It is not clear how it behave in case of specific multiple failures over the ring in case of wrapping. Also it is not clear what happens with the APS message is coin case of node failure. In which mode they work one-phase or two-phase mode of coordination.

4.    A challengeable issue with wrapping is really the BW allocation per LSP.

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sadler, Jonathan B.
Sent: Wednesday, November 11, 2009 6:03 AM
To: Alexander Vainshtein; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Thanks,

Jonathan Sadler

Jonathan Sadler

Cc: [email-masked]

Yaacov,

Regards,

     Sasha

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 06:49:07 +0200

Huub,
Lots of thanks for the clarification.
if the only application of steering is for trans-oceanic connections, this provides the future MPLS-TP operators
with a clear guideline when (not) to use it...

Regards,
     Sasha

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Wednesday, November 11, 2009 6:41 AM
> To: [email-masked]
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> > I tend to think that steering is one that should go away 
> (based on wide acceptance of FRR-Facility

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Tue, 10 Nov 2009 22:56:31 -0600

Hi Nurit,

I appreciate your comments on the differences, however, I don't see an answer to the label-push question I asked or reasons why I'm incorrect in my impression that wrapping and FRR-Facility are really different.  I look forward to someone dealing with these...

Your comment jars loose a couple of other thoughts though:
 - I also am concerned about the closed loop -- especially after the fault clears.  What keeps traffic from being "captured" in the protection path leading to cycling in the loop until TTL expiry?
 - Also, given the comments made in the MPLS session today, the authors may have been thinking that node failure would be handled the same way it is done in MS-SPRing -- specifically that the nodes that see a link failure would perform wrapping.  If an additional node called node G were added between Nodes C and D in Figure 1 of the draft, a failure of node C would initiate wraping at node B and at node G (since both see server layer failure indications).  The resulting LSP would be A-B-A-F-E-D-G-D. (where B-A-F-E-D-G were provided by the protection LSP.  Multiple link failures would be handled under these behaviors (as they are in MS-SPRing).
 - The draft's use of distinct protection LSPs for each working LSP would belp with the BW allocation issue.

Anyone else have thoughts?

Jonathan Sadler

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Tuesday, November 10, 2009 10:36 PM
To: Sadler, Jonathan B.; Alexander Vainshtein; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Hi Jonathan,

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sadler, Jonathan B.
Sent: Wednesday, November 11, 2009 6:03 AM
To: Alexander Vainshtein; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Thanks,

Jonathan Sadler

Jonathan Sadler

Cc: [email-masked]

Yaacov,

Regards,

     Sasha

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 11 Nov 2009 06:12:08 +0100

Nurit,

> creates a MP2MP LSP with much ingress and egress points.

We (the editors) realised this after uploading the draft.
It is not necessary to close the loop (i.e. connecting
the spans in each ring node) in the ring when there is
no protection switch active.
Connecting the spans will occur only during a protection
switch based on the APS information received.

> a node failure in the wrapping mode.

This is the same case as two spans failing at both sides of a
single ring node. The protection mechanism is capable of
handling and recovering multiple (span) faults on the ring.

> failures over the ring in case of wrapping.

This should indeed be described better, but in case of multiple
span faults, wrapping will take place as in single fault case.
Note that wrapping only will be effective on the working LSPs
not on the protection LSPs.

> Also it is not clear what 
> happens with the APS message is coin case of node failure.

I don't understand what is a coin case.

> In which mode 

On slide 9 of the presentation last bullet: 1-phase.

> 4.    A challengeable issue with wrapping is really the BW allocation 

The BW required for the protection around the whole ring
is less than the sum of the BW required for each protected LSP.

Regards, Huub.

> would allow for diverse path computation to be used to identify its path.
> 
>  
>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 11 Nov 2009 06:25:13 +0100

Hi Sasha.

> Lots of thanks for the clarification.

You're welcome.

> if the only application of steering is for trans-oceanic
 > connections, this provides the future MPLS-TP operators

What I tried to convey is that steering should be used
when latency is an issue. In packet transport latency
can be an issue for some services een when no ocean
has o be crossed.

The reason latency did become an issue in TDM was when
protection was required accross oceans, hence the steering
solution for trans-oceanic application..

Best regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 11 Nov 2009 06:49:01 +0100

Hi Jonathan,

You are right. I did not try to answer this question but just to refer
to some of your statements. 

FRR as well as segment protection may be solutions for wrapping mode of
protection.....

Draft- Umansky does not refer to node protection in the wrapping mode
and I am not sure what assumptions they have and how it really works. In
bypass tunnels we will need two bypass tunnels, one to overcome a link
failure and one to overcome a node failure and we will need to correctly
distinguish between the two. 

Still we need to see how multiple failures along the ring can be
addresses or does not create a loop on the ring......

Please see more inline.

Best regards,

Nurit

From: ext Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Wednesday, November 11, 2009 6:57 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein;
Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] Why do we need both wrapping and steering
forringprotection?

Hi Nurit,

I appreciate your comments on the differences, however, I don't see an
answer to the label-push question I asked or reasons why I'm incorrect
in my impression that wrapping and FRR-Facility are really different.  I
look forward to someone dealing with these...

-          I also am concerned about the closed loop -- especially after
the fault clears.  What keeps traffic from being "captured" in the
protection path leading to cycling in the loop until TTL expiry?

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] right

-          Also, given the comments made in the MPLS session today, the
authors may have been thinking that node failure would be handled the
same way it is done in MS-SPRing -- specifically that the nodes that see
a link failure would perform wrapping. 

[Sprecher, Nurit (NSN - IL/Hod HaSharon)]  Before sending APS? Before
getting an ack? One or two phases? See more below regarding the APS
message?

-         If an additional node called node G were added between Nodes C
and D in Figure 1 of the draft, a failure of node C would initiate
wraping at node B and at node G (since both see server layer failure
indications).  The resulting LSP would be A-B-A-F-E-D-G-D. (where
B-A-F-E-D-G were provided by the protection LSP.  Multiple link failures
would be handled under these behaviors (as they are in MS-SPRing).

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] to whom the APS is sent to? To
the peer node (other edge of the link) or to the previous node before
the edge of the link?

-          The draft's use of distinct protection LSPs for each working
LSP would belp with the BW allocation issue.

-         [Sprecher, Nurit (NSN - IL/Hod HaSharon)]  since the failure
can happen at any point, I believe the BW allocation is still a
challenge. 

Jonathan Sadler

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Tuesday, November 10, 2009 10:36 PM
To: Sadler, Jonathan B.; Alexander Vainshtein; Weingarten, Yaacov (NSN -
IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] Why do we need both wrapping and steering
forringprotection?

Hi Jonathan,

Best regards,

Nurit 

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

Thanks,

Jonathan Sadler

Jonathan Sadler

Cc: [email-masked]

Yaacov,

Regards,

     Sasha

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 11 Nov 2009 07:01:00 +0100

Huub,

Good answers.

I would like just to complement your reply to question 4.

In draft-umansky (like in SONET/SDH SPRing), BW allocation is very
trivial.

Only 50% of the link bw is allocated to working traffic (and no BW is
allocated to the protection traffic). The protection bw sharing property
of this scheme, together with the knowledge that a ring is a ring,
ensures that in whichever protection switching scenario, there is enough
bw for carrying the protection traffic on every span.

Italo

> Sent: Wednesday, November 11, 2009 2:12 PM
> To: [email-masked]
> Subject: Re: [mpls-tp] Why do we need both wrapping 
> andsteering forringprotection?
> 
> Nurit,
> 
> You replied:
> 
> > Hi Jonathan,
> > 
> [mailto:[email-masked]] On
> >

---

From: Jiang Yuanlong <[email-masked]>
Date: Wed, 11 Nov 2009 16:18:17 +0900

Another advantage of steering is the efficiency of bandwidth.
When traffics is switched on the protection path, double bandwidth 
will be consumed in some segments for wrapping in comparison with steering.

Best regards
Yuanlong

----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 11, 2009 1:41 PM
Subject: Re: [mpls-tp] Why do we need both wrapping and steeringforringprotection?

Ciao Diego,

Regards, Huub.

---

From: Jia HE <[email-masked]>
Date: Wed, 11 Nov 2009 16:02:39 +0800

Hi All,

I agree with the application motivation for different ring protection schemes.

IMHO wrapping is more popular in ring protection because it's simple and fast with only the node adjacent to the failure does switching  

Steering provides optimized path and bandwidth usage when delay and bandwidth efficiency is highly considered.

B.R.
Jia

  ----- Original Message ----- 
  From: Diego Caviglia 
  To: Adrian Farrel ; Alexander Vainshtein ; [email-masked] 
  Sent: Wednesday, November 11, 2009 10:20 AM
  Subject: Re: [mpls-tp] Why do we need both wrapping and steeringforringprotection?

  Hi,

  ·         Recovery time

  ·         Implementation Effort

  ·         Scalability

  ·         Bandwidth usage.

  BR

  Diego

   

   line

  DIEGO CAVIGLIA 

   

  Ericsson Italy

  Product Line PAIB

  Via A. Negrone 1/A

  Genoa, Italy

  Phone +390106003736

  Mobile +393357181762

  www.ericsson.com 

   Ericsson

   

   

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
  Sent: mercoledì 11 novembre 2009 3.10
  To: Alexander Vainshtein; [email-masked]
  Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

  Adrian

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

  To: <[email-masked]>

  ringprotection?

  Hi all,

  Regards,

       Sasha

   

  mpls-tp mailing list

  [email-masked]

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

---

From: "Cheng, Weiying" <[email-masked]>
Date: Wed, 11 Nov 2009 02:09:24 -0600

RPR （IEEE 802.17) also defines both wrap protection scheme and steer protection scheme. Due to simplicity of wrap, it is easier to meet 50 mSec switching requirements, but it does results in traffic pass extra hops. 

-- W. 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jia HE [[email-masked]]
Sent: Wednesday, November 11, 2009 2:02 AM
To: Diego Caviglia; Adrian Farrel; Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steeringforringprotection?

Hi All,

B.R.
Jia

----- Original Message -----
From: Diego Caviglia<mailto:[email-masked]>
To: Adrian Farrel<mailto:[email-masked]> ; Alexander Vainshtein<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Wednesday, November 11, 2009 10:20 AM
Subject: Re: [mpls-tp] Why do we need both wrapping and steeringforringprotection?

Hi,

・         Recovery time

・         Implementation Effort

・         Scalability

・         Bandwidth usage.

The point that i’m missing here is what are the applications we are trying to address i mean applications that are neither present in mpls nor in mesh network with mpls-tp.

BR

Diego

 line

DIEGO CAVIGLIA

Ericsson Italy

Product Line PAIB

Via A. Negrone 1/A

Genoa, Italy

Phone +390106003736

Mobile +393357181762

www.ericsson.com

 Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: mercoledì 11 novembre 2009 3.10
To: Alexander Vainshtein; [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering forringprotection?

Adrian

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

To: <[email-masked]>

ringprotection?

Hi all,

Regards,

     Sasha

mpls-tp mailing list

[email-masked]

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 11 Nov 2009 10:06:29 +0100

> My question: why was wrapping not specified to do a label push?

In order to support multiple failure scenarios (including node
protection) in a very simple/efficient manner, when you wrap from
working to protection, you make a swap operation to the same label value
independently on where the wrap from protection to working is taking
place. The label value you swap to is the one assigned by the next hop
on the protection path.

If you do a label push, you need to swap the incoming label to a value
assigned by the node where the pushed label is popped (i.e. the node
where the wrapping from protection to working will take place). As a
consequence this label value cannot be the same independently from the
node where the wrapping from protection to working takes place.

Italo

> [mailto:[email-masked]] On Behalf Of Sadler, Jonathan B.
> Sent: Wednesday, November 11, 2009 1:03 PM
> To: Alexander Vainshtein; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
> Cc: [email-masked]
> - It looks like wrapping doesn't do a label push, requiring 
> the same number of protection LSPs to exist for the working 
> LSPs.  I assume was done to allow non-protected LSPs to fail 
> when the link failure occurs, as well as to allow differing 
> QoS to be provided on the protection LSP..
> - It also looks like wrapping requires the merge point to be 
> at the exact other side of the link being protected.
> 
> FRR-Facility does a label push so that only one Bypass LSP is 
> required and the merge point is only required to "intersect 
> the working LSP" somewhere downstream.  So while wrapping 
> seems similar, it is really different.
> 
> I can see wrapping providing some simplicity because the 
> protection LSP path is easy to identify. However, CAC will 
> still need to be done for that LSP...
> 
> At the same time, steering in a topology that is richer than 
> a ring would allow for diverse path computation to be used to 
> identify its path.
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Alexander Vainshtein [[email-masked]]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Nov 2009 09:28:50 +0000

Huub van Helvoort wrote:
> Nurit,
>
> You replied:
>
>> Hi Jonathan,
>>
>> 1.    The protection LSP in the wrapping mode in draft-umansky forms 
>> a closed loop. We do not have such a construct in MPLS. This actually 
>> 2.    Also, it is not clear from draft-umansky, how they protect 
>> against a node failure in the wrapping mode.
>
So I think that you are saying that for every LSP that passes through 
the ring you create a second LSP that goes right round the ring (which 
may or may not be closed) and you merge traffic into that LSP one hop 
away one hope away from the failure, and pull it out one hop away from 
the failure on the far side of the failure and merge it back into it's 
proper LSP on the far side of the failure. Is that correct?

I think that you said that the merge was a one phase process. What 
happens when you get a one way failure?

>> Also it is not clear what happens with the APS message is coin case 
>> of node failure.
>
I think that the question was what happen to the APS message in the case 
of a node failure.

Specifically how do you deliver the APS message to the node adjacent to 
the failure - which may be the original neighbor of the node detecting 
the failure (link failure) or neighbor of that neighbor (node failure).

>> In which mode they work one-phase or two-phase mode of coordination.
>
I hope it says that in the draft.

-Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Nov 2009 09:36:02 +0000

Adrian Farrel wrote:
> I think this was the question at the mic on one of the drafts and 
> implicitly applying to all the protection drafts (I certainly heard at 
> least one author of another I-D say he registered the point)...
>
> We do need to describe the precise data plane behavior for all of 
> these proposals so that we can fairly evaluate them. This is obviously 
> a job for the authors of the different drafts.
Absolutely, for every message at every hop we need to specify what label 
stack it came in on, what label stack it went out on, and how any labels 
that were pushed or swapped were learned.

Where ever a packet is received at a node we need to know why.

We also need to explore what happens when an unexpected failure, partial 
failure, flap or repair takes place to make sure the protocol is clean, 
efficient and non-disruptive.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 16:13:45 +0200

Huub,
I am not sure that wrapping in MPLS (or MPLS-TP) is affected by latency issues in the same way as
wrapping in MS-SPRing.

In the case of the latter, the two nodes adjacent to the failure must agree between themselves on the type of failure (link or node) they deal with, and hence use signaling to achieve that. Hence signaling latency adds to the overall services' downtime.

In the case of the former (using the FRR - Facility backup schemes) such a coordination is not required IMO. In the link-and-node FRR protection mode each node that has detected a failure can take recovery actions individually.

This is because in MS-SPRing "locally wrapped" traffic does not carry with it any identification of the "remote wrapping node": we are dealing with the CO-CS network. In MPLS (and MPLS-TP) this information can be provided by the (pre-signaled or pre-configured) labels at the top of the label stack of each wrapped packet. The "remote wrapping node" is simply the tail end node of the appropriate bypass LSP.

I cannot say if these considerations completely eliminate the need for steering, but it is worth looking into it IMHO.
Every protection scheme that we can safely skip in MPLS-TP adds value.

My 2c,
     Sasha

> Sent: Wednesday, November 11, 2009 7:25 AM
> To: [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 16:18:23 +0200

Italo,
You've said:
<quote>
<end quote>

IMHO and FWIW this NOT how FRR-Facility protection in link-and-node protection mode works today in MPLS.
And I do not see why the same scheme is not applicable to MPLS-TP. The only difference is the source of information
about existence of the Next Next Hop and the label it expects to receive (CP or MP).

To the best of my understanding, this scheme is deployed today.

Did I miss something important?

Regards,
     Sasha

> From: BUSI ITALO [mailto:[email-masked]] 
> Sent: Wednesday, November 11, 2009 11:06 AM
> To: Sadler, Jonathan B.; Alexander Vainshtein; 
> Weingarten,Yaacov (NSN - IL/Hod HaSharon)
> Cc: [email-masked]

---

From: Phil Bedard <[email-masked]>
Date: Wed, 11 Nov 2009 13:50:02 -0500

I would say in MPLS networks today we rely on both wrapping and  
steering.  Wrapping via FRR one-to-one or facility and the steering  
function is done through a re-computation of the primary path or a  
secondary path which is pre-signaled.   I think one of the main  
reasons people use FRR/wrapping is because fault-detection and  
notification isn't good enough to ensure 50ms protection in all  
network scenarios.  Wrapping/local protection works across any  
topology of any distance as long as your topology is rich enough to  
support paths for the bypass tunnels.

Steering becomes more interesting on a ring because we can put  
constraints on ring size and node counts, and can make assumptions  
about the time it will take a failed node to notify other nodes of a  
failure.   On small diameter (low latency) rings I've seen restoration  
happen very quickly when a pre-signaled secondary path exists on the  
node, via a PathErr message.  So to me the choice depends if the  
notification+restoration using steering can happen in a timeframe  
carriers are comfortable with.

Phil

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 12 Nov 2009 02:53:56 +0100

Hi Sasha,

You replied:

> I am not sure that wrapping in MPLS (or MPLS-TP) is affected by
> latency issues in the same way as wrapping in MS-SPRing.

The issue of the latency is the additional propagation delay
(i.e two ocean crossings) for the transported client signals.

The APS signalling is not affected at all (because only the
client data is wrapped).

> In the case of the latter, the two nodes adjacent to the failure must
> agree between themselves on the type of failure (link or node) they
> deal with, and hence use signaling to achieve that. Hence signaling
> latency adds to the overall services' downtime.

No, as explained before the 1-phase APS is used, this requires
no negotiation, neither in case of link nor in node failure.

> In the case of the former (using the FRR - Facility backup schemes)
> such a coordination is not required IMO. In the link-and-node FRR
> protection mode each node that has detected a failure can take
> recovery actions individually.

So does 1-phase APS.

> This is because in MS-SPRing "locally wrapped" traffic does not carry
> with it any identification of the "remote wrapping node":

Each ring node has a ring map so at each ring node the ring
topology is known and local actions can be taken based on
the information in the ring map and received APS signals.

> we are dealing with the CO-CS network. In MPLS (and MPLS-TP) this
> information can be provided by the (pre-signaled or pre-configured)
> labels at the top of the label stack of each wrapped packet.

The same information can (if necessary) be transferred by the APS
messages in MPLS-TP in a TLV. Here we do not have the limited size
of the APS bytes in SDH/SONET.

> The "remote wrapping node" is simply the tail end node of the
 > appropriate bypass LSP.

The remote wrapping node can be determined by examining the
ring map together with received APS data.

> I cannot say if these considerations completely eliminate the need
> for steering, but it is worth looking into it IMHO. Every protection
> scheme that we can safely skip in MPLS-TP adds value.

The latency issue, as explained above, is related to client
signals that are sensitive to it.

My 2 (euro)c, Huub.

>> -----Original Message----- From: [email-masked] 
>> Sent: Wednesday, November 11, 2009 7:25 AM To: [email-masked] 
>>> connections, this provides the future MPLS-TP operators with a
>>> clear guideline when (not) to use it...
>> What I tried to convey is that steering should be used when latency
>> is an issue. In packet transport latency can be an issue for some
>> services een when no ocean has o be crossed.
>> 
>> The reason latency did become an issue in TDM was when protection
>> was required accross oceans, hence the steering solution for
>> trans-oceanic application..
>> 
>> Best regards, Huub.
>> 
>> 
>>>> -----Original Message----- From: [email-masked] 
>>>> [mailto:[email-masked]] On Behalf Of Huub van
>>>> Helvoort Sent: Wednesday, November 11, 2009 6:41 AM To:
>>>> [email-masked] Subject: Re: [mpls-tp] Why do we need both
>>>> wrapping and steering forringprotection?
>>>> 
>>>> Ciao Diego,
>>>> 
>>>> You wrote:
>>>> 
>>>>> Sasha As far as i've understood the steering is about 1:1 
>>>> trans-oceanic connetions because it reduces the latency when
>>>> protection is activated.
>>>> 
>>>> Regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Nov 2009 04:25:31 +0200

Huub,

If added client signals latency is an issue, then I fully agree with you: 
wrapping implies that the "long path" latency is added to the original one, 
and steering is better in this regard.  

So maybe there is a place for both - with the appropriate applicability statements.

Regards,
     Sasha

> Sent: Thursday, November 12, 2009 3:54 AM
> To: [email-masked]
> steering for ring protection?
> 
> Hi Sasha,
> 
> You replied:
>

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 12 Nov 2009 03:33:20 +0100

Stewart,

You wrote:

> may or may not be closed)

No, that is not what I think I wrote.
For determining the number of required protection LSPs, the
number of working LPSs in each span is considered. The number
of protection LSPs == max number of working LPSs in any single span.
(this is because the protecting LPSs are shared).

> and you merge traffic into that LSP one hop 
> away one hope away from the failure,

They are switched to, not merged into.

> and pull it out one hop away from 
> proper LSP on the far side of the failure.

They are switched to the originals, not merged into.

 > Is that correct?

See the above comments.

> happens when you get a one way failure?

The protection switch is one phase, i.e. immediate switch action
and acknowledge from far end.

SPRing is bi-directional, so both directions switch even in
case of one-way failure.
The reason is to keep the propagation delay in both directions
the same.

> the failure (link failure) or neighbor of that neighbor (node failure).

As is written in the draft and shown in figures 3 and 4
the APS messages are transmitted in both direction
(clockwise *AND* counter clockwise) on the ring.
One of these will always arrive at the node at the far end of
the failure.

> I hope it says that in the draft.

If you did read the 00 version you would have noticed that
this is not mentioned explicitly, it will be mentioned
explicitly in the next version.

Regards, Huub.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Nov 2009 15:29:34 +0000

> The APS signalling is not affected at all (because only the
Does APS need to co-ordinate the two ends of the failure? If so surely 
it needs to take the long path round the ring which is one ring 
circumference per signalling phase.

> no negotiation, neither in case of link nor in node failure.
I did not see an answer to my earlier mail on operation under conditions 
of node failure, and partial ring failure, and would like to understand 
how the proposal works in detail under these conditions.
> the information in the ring map and received APS signals.
What information is contained in the ring map?

> ring map together with received APS data.
Ah, so you do need to wait for the APS pkt to get all the way round the 
ring.  It's interesting that Malcolm said that he did not like 
triggering repair action on a link fail notification, and yet this 
approach seems to rely on an APS message which has similar properties.

Stewart

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 12 Nov 2009 22:07:54 +0100

Hi Huub,

Thanks for your clarifications.

Please see in-line.

Note well to the comments in red. 

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Huub van Helvoort
Sent: Thursday, November 12, 2009 4:33 AM
To: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrappingand steering
forringprotection?

Stewart,

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] you say "protecting LSPs are
shared", Do you mean protecting LSPs of the same single working LSP?

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] If you can enter an LSP from
different points by definition it is merge...and it is hard to follow
where it has been wrapped (there is no indication in the traffic)....

Also how do you handle multiple failures? 

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I believe in steering we can
handle more cases of multiple failures across the ring.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] You need to explain it
better... when you have two different labels swapped to the same label
on the same interface, it is a merge.......

See the above comments.

case of one-way failure.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] In the requirements we need to
handle p2mp as well which is unidirectional..

the same.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] can it cause a case where at a
certain point of time we can have traffic both on the protection path
and the working path and these are merged into the working path?

the failure.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] As far as I understand, the
APS message is used to co-ordinate the states of the protection between
the two edges of a link. Why do we need a new mechanism for this? Why
cannot we have linear protection (Segment protection) to achieve the
same thing? Why do we need two different messages, two different
solutions?

For example, we could define a protection PST to protect all traffic
going over a link in case of a fault condition. The protection PST is
set up between the two edges of the link (going all the way around the
ring to the peer edge of the link). Then we can use the PSC protocol
which is defined in the linear protection draft to coordinate the
protection state. Why do we need additional mechanism (which is based on
an unknown construct and a new protocol message if we can use something
which is already defined (in the linear protection draft) and can
provide the same functionality? Also in such a case we do not have
protection path for each LSP but for all LSPs traversing a link that
need to be protected. 

Regards, Huub.

-- 

mpls-tp mailing list

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 12 Nov 2009 22:07:56 +0100

Hi,
I agree Sasha that it is a good idea to come with some applicability
statements.
Note however that both steering and wrapping can be achieved efficiently
using existing constructs (and I include linear protection as an
existing construct). I would like to refer you to
draft-weingarten-mpls-tp-ring-protection to see more details. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Alexander Vainshtein
Sent: Thursday, November 12, 2009 4:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Why do we need both wrapping and steering for
ring protection?

Huub,

If added client signals latency is an issue, then I fully agree with
you: 
wrapping implies that the "long path" latency is added to the original
one, 
and steering is better in this regard.  

So maybe there is a place for both - with the appropriate applicability
statements.

Regards,
     Sasha

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Nov 2009 21:48:10 +0000

Huub

To illustrate how this all works, perhaps you could provide an example 
of what happens in the dataplane.

Perhaps we can start by looking at a variant of Figure 1 of you draft, 
can we assume that for  LSP 1 and LSP 2 is clockwise, and consider the 
following two failure cases: failure of BC and failure of node C.

What is the label stack on these two LSPs on the working and on the 
protect path for each of these cases.

- Stewart

Huub van Helvoort wrote:
>> the ring you create a second LSP that goes right round the ring 
>> (which may or may not be closed)
>
>> and you merge traffic into that LSP one hop away one hope away from 
>> the failure,
>
>> and pull it out one hop away from the failure on the far side of the 
>> failure and merge it back into it's proper LSP on the far side of the 
>> failure.
>
>> I think that the question was what happen to the APS message in the 
>> case of a node failure.
>>
>> Specifically how do you deliver the APS message to the node adjacent 
>> to the failure - which may be the original neighbor of the node 
>> detecting the failure (link failure) or neighbor of that neighbor 
>> (node failure).
>