Subject: [mpls] Mail regarding draft-cheng-mpls-tp-shared-ring-protection

From: 曾峻波 <[email-masked]>
Date: Wed, 4 Mar 2015 16:25:24 +0800

Hi authors，
       
We are developing the solution in our system. 

One question about the ring tunnel. For one destination node, the solution
needs setup 4 different ring tunnels, 2 for working and 2 for protection. My
suggestion is two tunnels are enough, one for clockwise working and protection,
and the other for anti-clockwise working and protection?

Best Regards!
Bobo

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 04 Mar 2015 10:26:22 +0100

Hello Bobo, 曾峻波 您好,

> We are developing the solution in our system.

Good to know that.

> One question about the ring tunnel. For one destination node, the
> solution needs setup 4 different ring tunnels, 2 for working and 2 for
> protection. My suggestion is two tunnels are enough, one for clockwise
> working and protection, and the other for anti-clockwise working and
> protection?

Did you take into account that the tunnels have to be bi-directional?

Did you also take into account that for a clockwise working tunnel
you have set up a anti-clockwise protection tunnel, and for an
anti-clockwise working tunnel, a clockwise protection tunnel?

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 05 Mar 2015 17:42:52 +0100

Hello Bobo,

You replied:

> Thank you very much for your quick response.

You're welcome.

> I know the 4 tunnels' benefit. and I got you the suggestion.

Great!.

> But I also read the draft draft-kompella-mpls-rmr-00, which was post by
> Kompella in last meeting. The very interesting thing is that
> draft-kompella-mpls-rmr-00 have similar concept with this draft, but it
> seems can use only two ring tunnel support both working and protection.

We studied that draft, and think it is complementary with our draft.
The Kompella draft describes the provisioning of the forwarding,
the Cheng draft describes the protection protocol.

The Kompella draft also does not make a distinction between working
and protection, that is why it seems that only two tunnels are
provisioned.

Best regards, 海高明

>  > Date: Wed, 4 Mar 2015 10:26:22 +0100
>  > From: [email-masked]
>  > To: [email-masked]; [email-masked]
>  > CC: [email-masked]
>  > Subject: Re: [mpls] Mail regarding
> draft-cheng-mpls-tp-shared-ring-protection
>  >
>  > Hello Bobo, 曾峻波 您好,
>  >
>  > You wrote:
>  >

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 6 Mar 2015 00:29:31 +0000

Hi Huub,
perhaps Kireeti disagrees with me but I think that draft-kompella-mpls-rmr and draft-cheng-mpls-tp-shared-ring-protection offer alternative or perhaps even orthogonal solutions to ring protection, not complimentary. My understanding is that RMR addresses unidirectional IP/MPLS LSP protection while MPLS-TP bi-directional co-routed MPLS-TP LSP.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Thursday, March 05, 2015 8:43 AM
To: 曾峻波; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Mail regarding draft-cheng-mpls-tp-shared-ring-protection

Hello Bobo,

You're welcome.

Great!.

> But I also read the draft draft-kompella-mpls-rmr-00, which was post 
> by Kompella in last meeting. The very interesting thing is that
> draft-kompella-mpls-rmr-00 have similar concept with this draft, but 
> it seems can use only two ring tunnel support both working and protection.

We studied that draft, and think it is complementary with our draft.
The Kompella draft describes the provisioning of the forwarding, the Cheng draft describes the protection protocol.

The Kompella draft also does not make a distinction between working and protection, that is why it seems that only two tunnels are provisioned.

Best regards, 海高明

>  > Date: Wed, 4 Mar 2015 10:26:22 +0100  > From: [email-masked]  
> > To: [email-masked]; [email-masked]  > CC: 
> [email-masked]
> > > solution needs setup 4 different ring tunnels, 2 for working and 2 
> for  > > protection. My suggestion is two tunnels are enough, one for 
> clockwise  > > working and protection, and the other for 
> anti-clockwise working and  > > protection?
>  >
> > you have set up a anti-clockwise protection tunnel, and for an  > 

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 6 Mar 2015 07:48:52 +0000

Hi Greg,

I agree that the protection mechanism in draft-cheng addresses the protection switching for MPLS-TP scenarios, and draft-kompella is more targeted on the IP/MPLS cases. 

Besides the protection mechanisms, the concept and structure of ring LSPs are described in both two drafts, which may be harmonized to build an unified ring LSP architecture for both TP and non-TP scenarios. For example: in both drafts, each ring LSP/tunnel is anchored by the exit node, for each exit node there are clockwise and anti-clockwise ring LSPs/tunnels, and all the traffic/services which leave the ring from a specific node would share the same ring LSP/tunnel. While there are also some differences, such as 2 tunnel vs. 4 tunnels as discussed in this thread.

Best regards,
Jie

> From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> Sent: Friday, March 06, 2015 8:30 AM
> To: [email-masked]; 曾峻波; [email-masked]
> perhaps Kireeti disagrees with me but I think that draft-kompella-mpls-rmr and
> draft-cheng-mpls-tp-shared-ring-protection offer alternative or perhaps even
> orthogonal solutions to ring protection, not complimentary. My understanding
> is that RMR addresses unidirectional IP/MPLS LSP protection while MPLS-TP
> bi-directional co-routed MPLS-TP LSP.
> 
> 	Regards,
> 		Greg
> 
> The Kompella draft also does not make a distinction between working and
> protection, that is why it seems that only two tunnels are provisioned.
> 
> Best regards, 海高明
> 
>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 Mar 2015 11:22:09 +0100

Hello Greg,

You replied:

 > perhaps Kireeti disagrees with me but I think that
 > draft-kompella-mpls-rmr and draft-cheng-mpls-tp-shared-ring-protection
 > offer alternative or perhaps even orthogonal solutions
 > to ring protection, not complimentary.

Ok, let's wait for his response.

 > My understanding is that RMR addresses unidirectional
 > IP/MPLS LSP protection while MPLS-TP bi-directional
 > co-routed MPLS-TP LSP.

When I read draft-kompella for the first time I thought
it was similar to SONET UPSR (while draft-cheng is more
like SONET BLSR). But the description of the switching
mechanism looked more like BLSR.

Regards, Huub.

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 9 Mar 2015 23:09:28 -0700

Hi Huub, Greg:

> > to ring protection, not complimentary.

Greg, I would agree with you (mostly) — I believe my draft is orthogonal: it’s focused on IP/MPLS.

> > IP/MPLS LSP protection while MPLS-TP bi-directional

Actually, RMR is bidirectional.  So, R1 can send (working) traffic to R3 CW and send (working) traffic to R7 anti clockwise (AC); i.e., use both directions for working traffic.  If there is a failure in the link between R3 and R4, traffic to nodes R4-Rn will be AC; traffic to nodes R2 and R3 will be CW.  In other words, the CW Working is the AC Protect, and vice versa.  This of course means that bandwidth management must take into account both working and protect traffic.

> mechanism looked more like BLSR.

Agreed; the intent (spelled out in the draft) is to mimic BLSR.

One other difference between draft-cheng and RMR is that draft-cheng has LSPs on rings, while RMR actually has ring LSPs — i.e., LSPs that start and end at the same node.  I note that cheng-03 has LSPs from C->D working and E->D protect.  In -04, the working goes from E->D, but the protect now goes D->D.  I expect in -05 that both will go D->D, and then there will be an overlap with RMR :)

There are three justifications for ring LSPs being full rings.  One is aesthetic (many won’t care; this may be in the eye of the beholder).  The second is it is easier for signaling to pair up the CW and AC LSPs.  The third is for OAM (as briefly outlined in rmr-01): the ingress can send OAM messages over its LSP, and check that they arrived fine back at the same node.

BTW, there is an update on RMR.  The update focuses on simplifying configuration and on auto-discovery, with a bunch of other smaller tweaks.  And a new author!

Cheers,
Kireeti.