Subject: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt

From: Kireeti Kompella <[email-masked]>
Date: Wed, 29 Oct 2014 10:40:42 -0700

Hi Folks,

This is a draft on making MPLS more efficient in ring networks.  I have
come around to understanding that:
a) rings are a special topology (there was a time that I didn't appreciate
that);
b) MPLS is pretty inefficient in rings (that is/was quite obvious).

This draft attempts to fix that, both by making protection much more
efficient, and by making configuration much easier.

Your comments are highly welcome!

Cheers,
Kireeti.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <[email-masked]>

A new version of I-D, draft-kompella-mpls-rmr-00.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:           draft-kompella-mpls-rmr
Revision:       00
Title:          Resilient MPLS Rings
Document date:  2014-10-26
Group:          Individual Submission
Pages:          7
URL:
http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/
Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-rmr-00

Abstract:
   This document describes the use of the MPLS control and data planes
   on ring topologies.  It describes the special nature of rings, and
   proceeds to show how MPLS can be effectively used in such topologies.
   It describes how MPLS rings are configured, auto-discovered and
   signaled, as well as how the data plane works.  Companion documents
   describe the details of discovery and signaling for specific
   protocols.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Kireeti

---

From: Shahram Davari <[email-masked]>
Date: Wed, 29 Oct 2014 17:59:23 +0000

Hi Kireeti,

It would be good if you can add a section to describe what is the difference between your draft and the following RFC/drafts, and why it is better.

https://tools.ietf.org/html/rfc6974

http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-ring-protection-03

Thanks
Shahram

From: mpls [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, October 29, 2014 10:41 AM
To: [email-masked]
Subject: [mpls] Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Folks,

This is a draft on making MPLS more efficient in ring networks.  I have come around to understanding that:
a) rings are a special topology (there was a time that I didn't appreciate that);
b) MPLS is pretty inefficient in rings (that is/was quite obvious).

This draft attempts to fix that, both by making protection much more efficient, and by making configuration much easier.

Cheers,
Kireeti.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>

URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

--
Kireeti

---

From: Mark Tinka <[email-masked]>
Date: Thu, 30 Oct 2014 12:48:21 +0200

On Wednesday, October 29, 2014 07:59:23 PM Shahram Davari 
wrote:

> It would be good if you can add a section to describe
> what is the difference between your draft and the
> following RFC/drafts, and why it is better.
> 

I'd also like to understand, better, from Kireeti, why he 
think the current IP/MPLS implementations are not suitable 
for ring architectures.

That said, I'm keen on getting a better handle on this 
draft, if it has the ability to make MPLS cheaper enough to 
roll out on far less expensive devices that can be deployed 
en masse in rings, in a way specific to ring architectures 
and their cost structures.

Mark.

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 30 Oct 2014 12:14:15 +0000

I've only just skimmed Kireeti's draft, but the differences are obvious to me.  The two docs you cite are TP-specific.  rfc6974 tries to show how one can use standard linear protection whilst simultaneously going in a circle (thus, Applicability) and the draft claims you need special non-protocol protocols to do the same thing.  Kireeti's doc says "Both RSVP-TE and LDP, with appropriate extensions, can be used to  signal ring LSPs"; although this is the extent of the meat of the document, it's obviously different from the other two you cite.

eric

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Shahram Davari
> Sent: Wednesday, October 29, 2014 1:59 PM
> To: Kireeti Kompella; [email-masked]
> Subject: Re: [mpls] Fwd: New Version Notification for draft-kompella-mpls-
> rmr-00.txt
> 
> Hi Kireeti,
> 
> 
> 
> It would be good if you can add a section to describe what is the difference
> between your draft and the following RFC/drafts, and why it is better.
> 
> 
> 
> From: <[email-masked] <mailto:[email-masked]> >
> To: Kireeti Kompella <[email-masked]
> <mailto:[email-masked]> >
> 
> 
> 
> A new version of I-D, draft-kompella-mpls-rmr-00.txt has been successfully
> submitted by Kireeti Kompella and posted to the IETF repository.
> 
> URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-
> 00.txt <http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-
> 00.txt>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org> .
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> 
> 
> --
> Kireeti

---

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 30 Oct 2014 16:17:20 +0200

Hi,

I tend to support Shahram's request regarding the issues of protection -
not sure what Kireeti is proposing in this draft that is different from the
proposals in the RFC or in the extreme case the shared ring protection
draft. I think that there may be some justification in extending this new
draft to cover the questions of configuring the ring LSP, as this is a
topic that is not covered by either of the two documents that Shahram
cites, and was assumed to pre-exist by both of those documents.

Eric - there is one comment that you made that I cannot agree with - that
the RFC is TP-specific! I am of the belief that there is nothing
intrinsically TP specific in either the Linear Protection or the Ring
Protection RFCs except for the use of the Generic Associated Channel -
which to the best of my understanding is Generic to any MPLS application.

BR,
yaacov

On Thu, Oct 30, 2014 at 2:14 PM, Osborne, Eric <[email-masked]>
wrote:

> I've only just skimmed Kireeti's draft, but the differences are obvious to
> me.  The two docs you cite are TP-specific.  rfc6974 tries to show how one
> can use standard linear protection whilst simultaneously going in a circle
> (thus, Applicability) and the draft claims you need special non-protocol
> protocols to do the same thing.  Kireeti's doc says "Both RSVP-TE and LDP,
> with appropriate extensions, can be used to  signal ring LSPs"; although
> this is the extent of the meat of the document, it's obviously different
> from the other two you cite.
>
>
>
>
>
> eric
>
>
> > Subject: [mpls] Fwd: New Version Notification for
> draft-kompella-mpls-rmr-
> > 00.txt
> >
> >
> >
> > Hi Folks,
> >
> >
> >
> http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-
> > Status:
> https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 30 Oct 2014 23:21:18 +0000

Hi Kireeti,
I think that proposed in this document protection method creates some unpleasant scenario if failure is of a node, not a link. If I use the scenario presented in Section 3.6 but assume that the failure is not of the link between R_j and R_j+1 but of the node Rj+1. Thus, as R_j switches to US direction, the R_j+2 will switch to DS. And until notifications from R_j and R_j+2 reach R_j+2 and R_j respectively we have routing loop on RL_j+1 LSP. If my assumptions are correct, then notification mechanism MUST be reliable or be backed up by IGP signaling. In any case, the loop may persist for quite a while and affect all services.

Comments, questions are always welcome and greatly appreciated.

                Regards,
                                Greg

Hi Folks,

Cheers,
Kireeti.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

--
Kireeti

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 31 Oct 2014 18:36:34 -0700

Hi Greg,

On Oct 30, 2014, at 16:21 , Gregory Mirsky <[email-masked]> wrote:

> Hi Kireeti,
> I think that proposed in this document protection method creates some unpleasant scenario if failure is of a node, not a link. If I use the scenario presented in Section 3.6 but assume that the failure is not of the link between R_j and R_j+1 but of the node Rj+1. Thus, as R_j switches to US direction, the R_j+2 will switch to DS. And until notifications from R_j and R_j+2 reach R_j+2 and R_j respectively we have routing loop on RL_j+1 LSP.

I appreciate your careful reading!  Note of course that since there is a TTL, this is a finite loop (not saying it isn’t bad, but that this has the germ of the solution.)

I have three solutions for this problem. I didn’t put them in the first version of the draft; I may eventually document all (and others, as the WG chimes in), but meanwhile this discussion is perfect.

My preferred solution is to always insert packets on a ring LSP with TTL = 2N-1 if the ring has N nodes.  This is enough for the worst case — node R_j sends a packet on RL_j+1 the “long” way around, only to encounter a failure at node R_j+2, and come all the way back to R_j, then R_j+1.

Another solution is that an ingress node sets the TTL as usual, but a PLR sets the TTL to the smaller of the current TTL-1 and the minimum TTL required to reach the egress.    So, in the above example, R_j would set TTL as usual, but R_j+2, on detecting a failure, would set TTL = N-1 and send it the other way.  In this case, when the packet gets back to R_j, it should not in turn reset the TTL to N-1.  Of course, both of the above can be combined.

Finally, a PLR (R_j+2) can push a special purpose label to indicate that this is a failure path, then push the label to go the other way.  If the packet goes back to R_j, before R_j sends it the other way, it sees that the label below the top of stack is this failure label, and drops the packet rather than cycle it back around the ring.

> If my assumptions are correct, then notification mechanism MUST be reliable or be backed up by IGP signaling. In any case, the loop may persist for quite a while and affect all services.

Agreed, having a reliable notification mechanism is always a good thing.

> Comments, questions are always welcome and greatly appreciated.

Greg, since you worked out the problem, do you have any opinions on the solutions above, or any of your own?

Cheers,
Kireeti.

> From: <[email-masked] <mailto:[email-masked]>>
> To: Kireeti Kompella <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/ <https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/>
> Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-rmr-00 <http://tools.ietf.org/html/draft-kompella-mpls-rmr-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
>  
> -- 
> Kireeti

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 31 Oct 2014 18:46:39 -0700

Hi Mark,

> think the current IP/MPLS implementations are not suitable 

“Not suitable” may be over-stating it; inefficient may be better. RSVP-TE needs bypass LSPs, and the failure path is inefficient.  LDP LFA’s worst topology is a ring.

Also, provisioning N^2 LSPs for full connectivity on N nodes is a burden, especially since there are lots of rings out there.

Finally, it might be time for new approaches to bandwidth management :)

> and their cost structures.

Well, let me know what you think!  I hope that is indeed the case.

Cheers,
Kireeti