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

From: Huub van Helvoort <[email-masked]>
Date: Sat, 01 Nov 2014 17:01:25 +0100

Hello Kireeti,

I also did a careful reading of this draft.

I agree with Greg that the failure of a node is not covered.

I also notice that you did not cover that a second failure
(link/node) that splits the ring in two islands.
In this case the protection in effect in each of the islands
should be maintained. You may have the same issue as detected
by Greg for a single node failure.

I also notice that during the process of changing DS to US
at each node MPLS packets may get lost or get out of order.
Is my interpretation correct?

Cheers, Huub.

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

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 2 Nov 2014 03:39:52 +0000

Hi Kireeti,
thank you for your kind consideration, much appreciated.
Of course, TTL will break the loop and setting it to precise value may be one solution. But, as Huub pointed, if ring experienced double failure loop still exist though less severe. And since nodes may be added and removed from the ring dynamically every node must be aware of number of nodes in that ring.
Thus I personally prefer option #3, (Extended) Special Purpose Label (that we can name later). The possible drawback, as with any new (E)SPL cases, is that it becomes new capability that now must be advertised as such.
But I agree, let’s list all three options as these are sound technical solutions to the realistic scenario and any of TTL based may be used by itself or in combination with (E)SPL. (E)SPL may be used only if ring is homogeneous in regard to this capability.

                Regards,
                                Greg

From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, October 31, 2014 6:37 PM
To: Gregory Mirsky
Cc: Kireeti Kompella; [email-masked]
Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Greg,

On Oct 30, 2014, at 16:21 , Gregory Mirsky <[email-masked]<mailto:[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.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, October 29, 2014 10:41 AM
To: [email-masked]<mailto:[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.

Your comments are highly welcome!

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]>>

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<http://tools.ietf.org/>.

The IETF Secretariat

--
Kireeti

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 2 Nov 2014 07:02:18 +0000

​​Greg, Kireeti and all,

A couple of general comments if you do not mind.

  1.  Fast handling of node failures is usually much more complicated than fast handling link failures, probably because it is not trivial for the nodes adjacent to the failure to distinguish between the two.
  2.  Ring topologies are special not just because they are the simplest topologies providing some level of resilience, but also because distinguishing between link and node failures is relatively simple even if it involves signaling.  BLSR (or its ITU-T equivalent MSP-Ring) uses this ability, and it has been inherited by the MPLS-TP mechanisms for ring protection. To me this means that enhancing Kireeti's original proposal with some signaling that would effectively protect against node failure should not be complicated.
  3.  I am not sure we need a new extended reserved label for this signaling. Existing mechanisms for trapping the labeled packets (GAL, TTL expiration) should suffice IMO.
  4.  Protection against a double failure that results in a ring being partitioned in two disjoint islands is IMO of less interest, not in the least because some traffic would not be restored in any case.
  5.  Last but not least, I think that Greg has hit an important weak point of all ring topologies when he has mentioned that nodes can be inserted into/removed from the ring. Such an operation typically requires renumbering of the nodes forming a ring. In SONET/DH operations require intervention of the network management system, and I suspect that this is also true for MPLS-TP rings. Identifying a solution for node insertion/removal that does not depend on management intervention and does not create additional traffic hits (beyond one that has been caused by disconnection of fibers required for node insertion/removal) looks like an important and challenging problem to me. If it could be solved, IMO this would give a real advantage to Kireeti's proposal.

My 2c,

Sasha

________________________________

From: mpls <[email-masked]> on behalf of Gregory Mirsky <[email-masked]>
Sent: Sunday, November 2, 2014 5:39 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Kireeti,

                Regards,
                                Greg

Hi Greg,

Hi Kireeti,

Cheers,
Kireeti.

                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: Huub van Helvoort <[email-masked]>
Date: Sun, 02 Nov 2014 14:27:19 +0100

Hello Sasha,

> A couple of general comments if you do not mind.

Thank you for your valuable comments.

See in-line [HH] for some answers.

>  1. Fast handling of node failures is usually much more complicated than
>     fast handling link failures, probably because it is not trivial for
>     the nodes adjacent to the failure to distinguish between the two.

[HH] if a node fails I expect that the links to the adjacent nodes fail
      too. If this protocol can handle two link failures, there is no
      need to distinguish between link and node failure.

>  2. Ring topologies are special not just because they are the simplest
>     topologies providing some level of resilience, but also because
>     distinguishing between link and node failures is relatively simple
>     even if it involves signaling.  BLSR (or its ITU-T equivalent
>     MSP-Ring) uses this ability, and it has been inherited by the
>     MPLS-TP mechanisms for ring protection. To me this means that
>     enhancing Kireeti's original proposal with some signaling that would
>     effectively protect against node failure should not be complicated.

[HH] (the correct ITU-T term is MS-SPRing), see my comment regarding
      node failure above. MS-SPRing signals only link failures. The APS
      protocol covers the node failure.

>  3. I am not sure we need a new extended reserved label for this
>     signaling. Existing mechanisms for trapping the labeled packets
>     (GAL, TTL expiration) should suffice IMO.

[HH] a new extended label will also increase the size of every packet
      that is ring protected. Note that there will also be unprotected
      traffic on the ring.

>  4. Protection against a double failure that results in a ring being
>     partitioned in two disjoint islands is IMO of less interest, not in
>     the least because some traffic would not be restored in any case.

[HH] the island could be a single node, see my comment under 1.
      Traffic that was already switched due to the first failure should
      not be switched again due to the second failure, in the current
      draft I cannot find how that is addressed.

>  5. Last but not least, I think that Greg has hit an important weak
>     point of all ring topologies when he has mentioned that nodes can be
>     inserted into/removed from the ring. Such an operation typically
>     requires renumbering of the nodes forming a ring.

[HH] IMHO renumbering is not required, the ring maps in each node have
      to be updated with the new adjacency of the nodes.

>     In SONET/SDH operations require intervention of the network
>     management system, and I suspect that this is also true for
>     MPLS-TP rings. Identifying a solution for node insertion/removal
>     that does not depend on management intervention and does not create
>     additional traffic hits (beyond one that has been caused
>     by disconnection of fibers required for node insertion/removal)
>     looks like an important and challenging problem to me. If it could
>     be solved, IMO this would give a real advantage to Kireeti's proposal.

[HH] adding/deleting a node from a ring should be performed only when
      there are no faults on the ring, the management has to update the
      ring-maps in each ring node. MS-SPRing uses a forced switch to move
      the traffic away from the link that is opened to insert a new node
      or away from the node that is removed. After the ring-maps are
      updated, the forced switch is cleared. The activation and clearing
      of the forced switch will have minimal hits on the traffic.

Best regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 2 Nov 2014 13:51:42 +0000

Hi Huub,
Lots of thanks for a prompt response and interesting comments.

Please see some responses inline below (marked [[Sasha]]).

Regards,
       Sasha 
Email: [email-masked]
Mobile: 054-9266302

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Sunday, November 02, 2014 3:27 PM
> To: [email-masked]
[[Sasha]] It is two links only in the case of a ring. In a more general topology it would be multiple links.
But even in the case of just two links their failure becomes known to two different nodes that are adjacent to the failed one.
Hence local repair actions undertaken by these adjacent nodes becomes problematic.
> [HH] (the correct ITU-T term is MS-SPRing), 
>
[[Sasha]] Oops! Lots of thanks for catching the typo!
> see my comment regarding node failure above. MS-SPRing signals only link failures. The APS
[[Sasha]] Well, my terminology was inaccurate... I admit that I have not read G.841 for quite a few years...
>       that is ring protected. 
[[Sasha]] No. This label would only be used in the signaling packets IMO so that they could be identified and trapped to SW.
>Note that there will also be unprotected  traffic on the ring.
> 
[[Sasha]] I suspect that the draft does not consider that. Not sure if this is a serious issue (probably not).
>       draft I cannot find how that is addressed.
[[Sasha]] I do not argue with that. I just say that these scenarios are of less interest because in the general case some traffic would  be lost.
>       to be updated with the new adjacency of the nodes.
[[Sasha]] I think that a "ring map" in your terminology is a generalization of "ring numbering". There is no real difference IMO.
>       there are no faults on the ring, 
[[Sasha]] Yes of course - but this is not related
> the management has to update the   ring-maps in each ring node. 
[[Sasha]] I call this operation "renumbering", but we are effectively saying exactly the same thing.
[[Sasha]] The only difference - and an important one - is that you expect the management to do that, while I would prefer renumbering/change of the ring map to be done by a coordinated action of the nodes themselves.
> MS-SPRing uses a forced switch to move  the traffic away from the link that is opened to insert a new node
[[Sasha]] Again, the main question here is whether you use a management system that operates simultaneously on all the nodes, or the nodes achieve similar results due to a coordinated action.
[[Sasha]] A node insertion scheme that would only require assignment of the ring ID and node ID (not node number) to the new node and restores the traffic once the fibers have been connected is what I would look for.
[[Sasha]] Please note that in a general IP/MPLS network using, say, LDP LFA, this is exactly what would happen - of course, assuming that your original LDP LFA scheme provides full coverage for link and node 
[[Sasha]failures both before and after insertion.
[[Sasha]] As Kireeti has mentioned, ring topologies are highly problematic for LDP LFA (at least if you do not use remote LFA), but I would still expect (I can be over-optimistic) to achieve similar results with the RMR scheme.

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

---

From: Mark Tinka <[email-masked]>
Date: Sun, 2 Nov 2014 19:35:44 +0200

On Sunday, November 02, 2014 09:02:18 AM Alexander 
Vainshtein wrote:

> 5.  Last but not least, I
> think that Greg has hit an important weak point of all
> ring topologies when he has mentioned that nodes can be
> inserted into/removed from the ring. Such an operation
> typically requires renumbering of the nodes forming a
> ring. In SONET/DH operations require intervention of the
> network management system, and I suspect that this is
> also true for MPLS-TP rings. Identifying a solution for
> node insertion/removal that does not depend on
> management intervention and does not create additional
> traffic hits (beyond one that has been caused by
> disconnection of fibers required for node
> insertion/removal) looks like an important and
> challenging problem to me. If it could be solved, IMO
> this would give a real advantage to Kireeti's proposal.

I'm aware of active work in this regard taking place at one 
of the vendors.

I hope any success in this area will be open standard.

Mark.

---

From: Phil Bedard <[email-masked]>
Date: Sun, 02 Nov 2014 16:47:50 -0500

>I hope any success in this area will be open standard.

There is some difficulty because address assignment happens at a layer 
below protocols like LDP/RSVP.  One solution is to use unnumbered 
interfaces which has been used for some time in various protocols but it 
can add some operational difficulties, at least perceived.  Never caught 
on for various reasons.   The other is use a protocol below IP to 
negotiate IP addresses.  If we are thinking of the same vendor they use 
proprietary extensions to LLDP (802.3ab) to negotiate the owner of the 
link and the non-owner.  The non-owner is assigned an IP address one lower 
than the owner, which works for either a /30 or a /31.  

What I'd rather see is have all this working over IPv6 where you simply 
use link-local addresses which offer a dynamic mechanism for address 
assignment.   

As for the draft I do see some benefit in it as we deploy MPLS access 
rings.  They require a lot of state in the rings today which is completely 
unnecessary including link detours or FRR paths.  

Phil

---

From: Sriganesh Kini <[email-masked]>
Date: Sun, 2 Nov 2014 22:42:02 -0800

Hi all,

Would like to point to a proposal several years ago, that sent a
notification to the upstream nodes (to remove the wraparound traffic).
http://www.ietf.org/archive/id/draft-kini-mpls-ring-frr-facility-backup-02.txt

http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-02

In order to convey the notification rapidly, signaling protocols were not
used.
A combination of TTL expiry and the G-Ach was used (GAL TTL was used to
prevent looping of packets). It also used a BFD session to convey whether
the PLR has done the protection switch so that the upstream nodes can do
the switchover of the traffic and remove the wraparound. There may be
better alternatives than using BFD.

Sri

On Sun, Nov 2, 2014 at 12:02 AM, Alexander Vainshtein <
[email-masked]> wrote:

>    1. Fast handling of node failures is usually much more complicated
>    than fast handling link failures, probably because it is not trivial for
>    distinguishing between link and node failures is relatively simple even if
>    it involves signaling.  BLSR (or its ITU-T equivalent MSP-Ring) uses this
>    ability, and it has been inherited by the MPLS-TP mechanisms for ring
>    protection. To me this means that enhancing Kireeti's original proposal
>    with some signaling that would effectively protect against node failure
>    should not be complicated.
>    signaling. Existing mechanisms for trapping the labeled packets (GAL, TTL
>    expiration) should suffice IMO.
>    partitioned in two disjoint islands is IMO of less interest, not in the
>    least because some traffic would not be restored in any case.
>    inserted into/removed from the ring. Such an operation typically requires
>    renumbering of the nodes forming a ring. In SONET/DH operations
>    require intervention of the network management system, and I suspect that
>    this is also true for MPLS-TP rings. Identifying a solution for node
>    insertion/removal that does not depend on management intervention and does
>    not create additional traffic hits (beyond one that has been caused
>    by disconnection of fibers required for node insertion/removal) looks like
>    an important and challenging problem to me. If it could be solved, IMO this
>    would give a real advantage to Kireeti's proposal.
>
>
>  My 2c,
>
> Sasha
>  ------------------------------
>
>
>  *From:* mpls <[email-masked]> on behalf of Gregory Mirsky <
> [email-masked]>
> *Sent:* Sunday, November 2, 2014 5:39 AM
> *To:* Kireeti Kompella
> *Cc:* [email-masked]
>
> *Subject:* Re: [mpls] New Version Notification for
> draft-kompella-mpls-rmr-00.txt
>
>
> Hi Kireeti,
>
> Of course, TTL will break the loop and setting it to precise value may be
> one solution. But, as Huub pointed, if ring experienced double failure loop
> still exist though less severe. And since nodes may be added and removed
> from the ring dynamically every node must be aware of number of nodes in
> that ring.
>
> Thus I personally prefer option #3, (Extended) Special Purpose Label (that
> we can name later). The possible drawback, as with any new (E)SPL cases, is
> that it becomes new capability that now must be advertised as such.
>
> But I agree, let’s list all three options as these are sound technical
> solutions to the realistic scenario and any of TTL based may be used by
> itself or in combination with (E)SPL. (E)SPL may be used only if ring is
> homogeneous in regard to this capability.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Kireeti Kompella [mailto:[email-masked]]
> *Sent:* Friday, October 31, 2014 6:37 PM
> *To:* Gregory Mirsky
> *Cc:* Kireeti Kompella; [email-masked]
> *Subject:* Re: [mpls] New Version Notification for
> draft-kompella-mpls-rmr-00.txt
>
>
>
> 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.
>
>
>
> *From:* mpls [mailto:[email-masked] <[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 draft attempts to fix that, both by making protection much more
> efficient, and by making configuration much easier.
>
>
>
> From: <[email-masked]>
> To: Kireeti Kompella <[email-masked]>
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>
> --
> Kireeti
>
>
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Nov 2014 09:58:20 -1000

Hi Huub,

> On Nov 1, 2014, at 06:01 , Huub van Helvoort <[email-masked]> wrote:
> 
> Hello Kireeti,
> 

My aim is to treat link and node failures the same way.  I don’t see much difference in how one would respond, but I’m happy to listen to other opinions.

> by Greg for a single node failure.

Understood.

> Is my interpretation correct?

That is correct.  I think that is the case for all protection schemes; certainly for MPLS protection schemes.

Cheers,
KIreeti

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Nov 2014 10:06:20 -1000

Hi Greg,

> On Nov 1, 2014, at 17:39 , Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Kireeti,

Do you think it is important to deal with dynamic changes during protection?

> Thus I personally prefer option #3, (Extended) Special Purpose Label (that we can name later). The possible drawback, as with any new (E)SPL cases, is that it becomes new capability that now must b…

I suggested the (E)SPL option, but current reality is that all LSRs support TTL processing; it will take time for the SPL approach to be implemented in forwarding engines.

> But I agree, let’s list all three options as these are sound technical solutions to the realistic scenario and any of TTL based may be used by itself or in combination with (E)SPL.

Good, I will do that.

> (E)SPL may be used only if ring is homogeneous in regard to this capability.

Actually, for node failure, SPL can be used when the nodes adjacent to the egress support the SPL.  But to address Huub’s point (double failure), every node would have to support the SPL.

Cheers,
Kireeti.

> On Oct 30, 2014, at 16:21 , Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Kireeti,
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Kireeti Kompella
> To: [email-masked] <mailto:[email-masked]>
> 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: Gregory Mirsky <[email-masked]>
Date: Wed, 12 Nov 2014 20:50:44 +0000

Hi Kireeti,
I think of dynamic changes to a ring as operator induced, controlled defect. I think that there should be requirement that flows to unaffected by the change nodes, more when removing a node, be unaffected. Whether that be result of explicitly putting links at adjacent neighbors into Lock state thus triggering protection switchover or of some other action, i.e. propagating OAM update that node K is down, we can discuss. But I believe that such changes in the ring should work without disrupting other services. It is possible that controlled topology change and failure happen in what practically can be viewed simultaneously so that protection actions to both overlap. In such case, I think, we have what Huub characterize as ring double failure.

                Regards,
                                Greg

From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wednesday, November 12, 2014 12:06 PM
To: Gregory Mirsky
Cc: Kireeti Kompella; [email-masked]
Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Greg,

On Nov 1, 2014, at 17:39 , Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kireeti,

Good, I will do that.

Cheers,
Kireeti.

                Regards,
                                Greg

From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, October 31, 2014 6:37 PM
To: Gregory Mirsky
Cc: Kireeti Kompella; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Greg,

Hi Kireeti,

Cheers,
Kireeti.

                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: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 13 Nov 2014 08:12:27 +0000

Hi Kireeti,

I see the definition section of this draft briefly describes the architecture of ring LSP, and section 3.3, 3.4  specify the installation of primary and protection labels.  Since section 2.1 of draft-cheng-mpls-tp-shared-ring-protection specified the architecture of ring tunnels and the label distribution on rings, maybe we can build the ring LSP architecture based on that work.

Section 3.6 Protection describes the general protection mechanism used for ring LSPs, while the details of several protection mechanisms, like wrapping, short-wrapping and steering in ring topology were specified in section 2.2~2.4 of draft-cheng-mpls-tp-shared-ring-protection. IMO it would be helpful if the applicability of these protection mechanisms can be discussed or reused.

Regarding configuration and signaling, both are interesting topics for MPLS in ring topology, and I’d appreciate hearing your thoughts on them.

Best regards,
Jie

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

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:

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: Huub van Helvoort <[email-masked]>
Date: Thu, 13 Nov 2014 16:56:29 +0100

Hello Kireeti,

See my response in-line [hh]
> My aim is to treat link and node failures the same way.
 > I don’t see much difference in how one would respond,
 > but I’m happy to listen to other opinions.

[hh] If I understand the draft well enough: node J detects
failure of the link JK between node J and K (whether that is
due to link JK failure or node K failure does not matter).
Node J switches traffic from US to DS and sens a message DS to
node K (unaware of the possibility that node K has failed).
Node L receives the message, but cannot forward it to the
failed node K.
What happens in this case?

>> by Greg for a single node failure.

[hh] OK.

> That is correct.  I think that is the case for all protection
 > schemes; certainly for MPLS protection schemes.

[hh] what is described in your draft I would call "steering"
at the ingress node.
draft-cheng-mpls-tp-shared-ring-protection used "wrapping"
Wrapping has the advantage that packets are lost only during
the defect detection time.
Steering has additional time, the switch times at every node
between the node detecting the failure until the DS message
reaches the ingress node.

Cheers, Huub.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 13 Nov 2014 10:28:58 -1000

Hi Greg,

On Nov 12, 2014, at 10:50 , Gregory Mirsky <[email-masked]> wrote:

> Hi Kireeti,
> I think of dynamic changes to a ring as operator induced, controlled defect.

Good — we’re on the same page.

> I think that there should be requirement that flows to unaffected by the change nodes, more when removing a node, be unaffected.

Good point.  I will add text to address this.

> Whether that be result of explicitly putting links at adjacent neighbors into Lock state thus triggering protection switchover or of some other action, i.e. propagating OAM update that node K is down, we can discuss. But I believe that such changes in the ring should work without disrupting other services. It is possible that controlled topology change and failure happen in what practically can be viewed simultaneously so that protection actions to both overlap. In such case, I think, we have what Huub characterize as ring double failure.

Okay, that makes more sense now.

Kireeti.

> On Nov 1, 2014, at 17:39 , Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Kireeti,
> From: Kireeti Kompella [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Kireeti Kompella; [email-masked] <mailto:[email-masked]>

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 13 Nov 2014 11:18:16 -1000

Hi Huub,

> due to link JK failure or node K failure does not matter).

I’m assuming that J->K is US.

> node K (unaware of the possibility that node K has failed).

Two points here:

a) Node J sends a message to its DS neighbor, not to node K.  This means that traffic switches from US to DS one hop closer to the ingress.  One might want to send the notification to the ingress, but since ring LSPs are multipoint, you really don’t know who the ingress is.

b) for all ring LSPs except the one with node K as egress, the protection action of switching traffic from US to DS works, independent of whether the link JK or the node K failed.  In the case of the ring LSP to node K, nothing can really be done, unless the real destination is dual-homed (separate topic).

> Node L receives the message, but cannot forward it to the

Not sure why you want to send the notification to node K.

KIreeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 13 Nov 2014 12:42:57 -1000

Hi Huub,

> reaches the ingress node.

Not sure what you mean.  The goal in what I’m doing (call it what you will) is to minimize packet loss to detection time.  The node detecting the failure switches traffic as soon as it realizes that the next {link, node} has failed.

The fact that other nodes can short-circuit the protection path is an optimization.

Kireeti.

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 13 Nov 2014 23:59:43 +0100

Hello Kireeti,

You replied:

See my response in-line [hh2]

> I’m assuming that J->K is US.

[hh2] yes, that is correct.

> a) Node J sends a message to its DS neighbor, not to node K.
 >  This means that traffic switches from US to DS one hop
 > closer to the ingress.
 > One might want to send the notification to the ingress,
 > but since ring LSPs are multipoint, you really don’t know
 > who the ingress is.

[hh2] OK, that was not clear to me when I read the draft.

[hh2] Can I conclude that the sending of messages to DS
neighbors stops as soon as the ingress node is reached?

> b) for all ring LSPs except the one with node K as egress,
 > the protection action of switching traffic from US to DS
 > works, independent of whether the link JK or the node
 > K failed.

[hh2] if my conclusion above is correct, then I agree.

> In the case of the ring LSP to node K, nothing can
 > really be done, unless the real destination is
 > dual-homed (separate topic).

[hh2] OK, I would refer to that as drop-and-continue
because there can be more than two nodes involved.

> Not sure why you want to send the notification to node K.

[hh2] if my conclusion above is correct, then forget
this comment.

Cheers, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Nov 2014 00:05:22 +0100

Hello Kireeti,

You reply:

> Not sure what you mean. The goal in what I’m doing (call it
 > what you will) is to minimize packet loss to detection time.

[hh] OK, I see.

> The node detecting the failure switches traffic as soon as
 > it realizes that the next {link, node} has failed.
>

[hh] this was not clear to me after reading the draft.
So you are initially also using wrapping. This is similar
to draft-cheng-mpls-tp-shared-ring-protection

Cheers, Huub.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 14 Nov 2014 05:03:27 +0000

Hi Huub, Kireeti,

> Sent: Friday, November 14, 2014 7:05 AM
> To: [email-masked]
> >> Wrapping has the advantage that packets are lost only during the
> >> defect detection time.
> >> Steering has additional time, the switch times at every node between
> >> the node detecting the failure until the DS message reaches the
> >> ingress node.
> >
> So you are initially also using wrapping. This is similar to
> draft-cheng-mpls-tp-shared-ring-protection

I guess the specified protection is to use wrapping in the beginning to minimize packet loss, when other nodes know the failure, they can switch to shorter paths (i.e. steering) for optimization. 

Best regards,
Jie

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 14 Nov 2014 09:30:07 -1000

Hi Huub,

> [hh2] OK, that was not clear to me when I read the draft.

Clearly, a number of clarifications and details are needed.  Watch this space for updates :)

> neighbors stops as soon as the ingress node is reached?

Yes and no.  Yes for the traffic from that node.  However, since the ring LSP is multipoint, the nodes further DS can also initiate traffic.  So, effectively, the notifications have to go all the way to the ring LSP’s anchor node.

> because there can be more than two nodes involved.

Indeed.

> [hh2] if my conclusion above is correct, then forget

No, you are correct in that (as I said above) every node till the ring LSP anchor needs to know, including node K.  However, one can’t just send a notification to node K — all nodes DS of the fault need to know this.

Cheers,
Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 14 Nov 2014 09:31:53 -1000

Hi Dongjie, Huub:

> I guess the specified protection is to use wrapping in the beginning to minimize packet loss, when other nodes know the failure, they can switch to shorter paths (i.e. steering) for optimization. 

Yes, that would be a good characterization.

Cheers,
Kireeti.