Re: [mpls] MPLS ring protection reconsidered ??

["Dongjie (Jimmy)" <[e-mail]>]

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

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Wednesday, March 18, 2015 9:14 AM
> To: Shahram Davari
> Cc: [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [mpls] MPLS ring protection reconsidered ??
> 
> Shahram,
> 
> 
> On Mar 17, 2015, at 01:14 , Shahram Davari <[e-mail]> wrote:
> 
> > Hi Loa
> >
> > 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.
> 
> > Regards,
> > Shahram
> >
> >
> >> On Mar 16, 2015, at 10:23 PM, Loa Andersson <[e-mail]> wrote:
> >>
> >>
> >> 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 Protection
> in 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: [e-mail]
> >> Senior MPLS Expert                          [e-mail]
> >> Huawei Technologies (consultant)     phone: [phone]
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls