Subject: [mpls] MPLS ring protection reconsidered ??

From: Loa Andersson <[email-masked]>
Date: Mon, 16 Mar 2015 15:23:27 +0100

Folks,

(taking my chair hat off for a while, i.e. this should not be
read as a chair directive, just a bit of mumbling that comes out
thinking about how to progress documents.)

As far back s the 73rd IETF in Minneapolis John and Adrian made
a report on "Requirements for Ring Protectionin MPLS-TP". The
conclusions were that we could do topology specific protection
solutions if the benefits are big enough.

Such solutions need to meet the same requirements as linear
protection and it has to be show that it can't be done by linear
protection only.

At that time we did not see that there were things that would not
be as readily done by the linear protection being specified at that
time.

Today we have to drafts that address ring topologies, one 
draft-kompella-mpls-rmr addresses Resilient MPLS Rings in an MPLS-TE
environment. The other draft-cheng-mpls-tp-shared-ring-protection
addresses protection in an MPLS-TP environment.

Both recognizes that ring topologies are very common and that very
efficient mechanism for keeping traffic flowing in case of failures
are possible to design. Sometime far better than what is the case if
the actual ring topologies are view as a linear topology,

The first document (draft-kompella- ) looks primarily on the operations
within a single ring and how fast and simple mechanisms for protection
can be deployed. A ring topology is a very common deployment scenario.
While, the draft-kompella from a solutions point is somewhat orthogonal
to draft-cheng, it does also discuss the dynamic control plane for mpls
ring, including auto-discovery and signaling. It seems that there are
opportunities for co-operation between the two drafts in this area.

The other (draft-cheng- ) looks at what is called MPLS shared ring, i.e.
a rather high number can shared the same path around the ring, and all
traffic can be protected by a single operation.
Another aspect of the shared tunnel is that if part of the ring
(typically 2 nodes and one link) are part of more than one ring. It
becomes possible to protect against more than one failure.

Maybe it is time to revisit the question and see if we want to adopt
working group documents for the two scenarios outlined above.

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Andrey Slastenov <[email-masked]>
Date: Mon, 16 Mar 2015 18:13:13 +0100

Hi Loa

Thank you for your presentation today :)

Отправлено с iPhone

> 16 марта 2015 г., в 15:23, Loa Andersson <[email-masked]> написал(а):
> 
> 
> Folks,
> 
> Today we have to drafts that address ring topologies, one draft-kompella-mpls-rmr addresses Resilient MPLS Rings in an MPLS-TE
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 16 Mar 2015 19:32:35 +0100

Hello Loa,

Thank you for your analysis.

The key source of information required for protection switching
in a ring topology are the "ring-maps" present in each node in
the ring.
A "ring-map" contains the identity and location of each "ring-node"
in the ring. It also contains information of the "ring-LSPs".

draft-kompella-mpls-rmr describes how to fill the "ring-maps"
and can be extended to multiple rings sharing a link.
draft-cheng-mpls-tp-shared-ring-protection describes the messaging
mechanism to provide the protection switch in single and multiple
rings.

I support your proposal below.

Regards, Huub.
=============

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

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Mar 2015 00:14:39 +0000

Hi Loa

I support merging these two drafts as I mentioned it on the Mic during last IETF. 

Regards,
Shahram

> On Mar 16, 2015, at 10:23 PM, Loa Andersson <[email-masked]> wrote:
> 
> 
> Folks,
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 18 Mar 2015 02:02:54 +0100

Hi Loa,

Thanks for your mail!

I’m all for revisiting the question.  I was going to ask for WG adoption of RMR.

If the draft-cheng authors ask the same, I have no objection.  However, I think there are quite a few differences between the two drafts, and don’t think that merging them is the technically best solution.

Kireeti.

> On Mar 16, 2015, at 15:23 , Loa Andersson <[email-masked]> wrote:
> 
> 
> Folks,
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 18 Mar 2015 02:13:52 +0100

Shahram,

> I support merging these two drafts as I mentioned it on the Mic during last IETF. 

I don’t.

Here’s why (in addition to points that others have mentioned):
1) The two drafts have different views of ring LSPs.  draft-cheng creates LSPs on rings; RMR creates ring LSPs (LSPs that start and end at the same node).
2) draft-cheng is focused on MPLS-TP; RMR is focused on IP/MPLS & MPLS-TE
3) RMR considers the issue of “bypass links”.
4) RMR, in addition to protection, also aims to significantly reduce the configuration of ring LSPs.

Kireeti.

---

From: weiqiang cheng <[email-masked]>
Date: Wed, 18 Mar 2015 10:50:31 +0800

Hi  Loa and Kireeti,

Thank you very much for your constructive discussion.

As thoroughly discussed in previous IETF meetings, we were also going to
ask for WG adoption of the draft-cheng.

I agree with you that the two drafts solve different issues. We also prefer
not to merge them.

We suggest that the WG may consider to adopt both drafts in Dallas

B.R.

Weiqiang Cheng
Research Institute of China Mobile
Department of Network Technology

2015-03-18 9:02 GMT+08:00 Kireeti Kompella <[email-masked]>:

> If the draft-cheng authors ask the same, I have no objection.  However, I
> think there are quite a few differences between the two drafts, and don’t
> think that merging them is the technically best solution.
>
> Kireeti.
>
> > a report on "Requirements for Ring Protection in MPLS-TP". The

---

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Mar 2015 02:58:18 +0000

Kireeti,

I understand there are differences. And I am OK to have two separate drafts. I was just hoping we could converge on one solution.

Thx
Shahram

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Wednesday, March 18, 2015 9:14 AM
To: Shahram Davari
Cc: Kireeti Kompella; Loa Andersson; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS ring protection reconsidered ??

Shahram,

I don’t.

Kireeti.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Mar 2015 10:08:55 +0000

Hi Kireeti, 

I'd appreciate the convergence on the understanding that it is a good idea to progress both drafts. 

With regard to "different views of ring LSPs", I'd like to share some of my views for discussion. draft-cheng mentions both ring tunnels and LSPs, the LSPs traversing the ring can have their ingress and egress nodes out of the ring, while the ring tunnels are provisioned based on the ring topology and for each exit node on the ring. Thus to some extent the ring tunnels in draft-cheng could be seen as the equivalents of ring LSPs in draft-kompella. Since draft-cheng does not specify the dynamic control plane which is optional for MPLS-TP, these ring tunnels are not created via signaling.

Best regards,
Jie

> From: mpls [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Cc: [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> 1) The two drafts have different views of ring LSPs.  draft-cheng creates LSPs
> on rings; RMR creates ring LSPs (LSPs that start and end at the same node).
> >> (taking my chair hat off for a while, i.e. this should not be read as
> >> a chair directive, just a bit of mumbling that comes out thinking
> >> about how to progress documents.)
> >>
> >> As far back s the 73rd IETF in Minneapolis John and Adrian made a
> >> report on "Requirements for Ring Protection
> in MPLS-TP". The
> >> At that time we did not see that there were things that would not be
> >> as readily done by the linear protection being specified at that
> >> time.
> >>
> >> The first document (draft-kompella- ) looks primarily on the
> >> operations within a single ring and how fast and simple mechanisms
> >> for protection can be deployed. A ring topology is a very common
> deployment scenario.
> >> While, the draft-kompella from a solutions point is somewhat
> >> orthogonal to draft-cheng, it does also discuss the dynamic control
> >> plane for mpls ring, including auto-discovery and signaling. It seems
> >> that there are opportunities for co-operation between the two drafts in this
> area.
> >>
> >> a rather high number can shared the same path around the ring, and
> >> all traffic can be protected by a single operation.