Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Huub van Helvoort <> Sun, 12 July 2015 11:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 71D921ACDF0; Sun, 12 Jul 2015 04:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u8asmsKmu8yp; Sun, 12 Jul 2015 04:00:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96CF81ACDED; Sun, 12 Jul 2015 04:00:01 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so41254490wic.1; Sun, 12 Jul 2015 04:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=f7xyJifHBqpS2aqx752RagZ8QonNqBZ+j2WWCaM0Rgw=; b=Fq52HRYMjglW5LW/oV4WtfZL8/he68jEvr+OgDdqcoYD5RRE7mRzCsDSHkEyE/XXGI NHvVA/6QukqPCW8d3xFjwEIT86o5QArkKrimCmjpaWmFnxK/Iv6BYfQUtbwWRe8udwzd Xl+gD41BRECFYnW3fI6cHfE8ENX26/CZFoiqVkai/oVJU0sSRnUK68q/CKofToEd03cR vLGuqQRd03z73kSyugKcHhWmkJuDokPZlM5wB0x+n6L9FoIO4ZModZmdLXqdrx6zc5fM HQj2xUIYkxnXqBhiv93LW8pYBG8VxtCFsZTvFaBMpio2ISypBPAx+B29awd9qaNnHdA4 S/vw==
X-Received: by with SMTP id bk5mr58658213wjb.144.1436698800373; Sun, 12 Jul 2015 04:00:00 -0700 (PDT)
Received: from McAsterix.local ( []) by with ESMTPSA id i6sm22739378wjf.29.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2015 03:59:59 -0700 (PDT)
Message-ID: <>
Date: Sun, 12 Jul 2015 13:00:34 +0200
From: Huub van Helvoort <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Yimin Shen <>, "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jul 2015 11:00:03 -0000

Hello Yimin,

Thank you for your review.
Here is our response: in-line [Huub] on behalf of the authors.

Best regards. Huub.

On 10-07-15 03:37, Yimin Shen wrote:
Dear authors, chairs, and WG
I’ve been asked by the WG chairs to review draft-cheng-mpls-tp-shared-ring-protection-05 for WG adoption. Overall, I think the draft is trying to address a valid MPLS-TP scenario by using a promising solution. However, I have the following comments and questions  for sections 1 to 4, which I would like to request the authors to answer and clarify.
  1. Section 2.1 – Recovery of multiple failures
  • This is misleading to me. The draft seems to only be able to handle a single failure per ring, rather than multiple failures per ring. This may need some clarification.
[Huub] Multiple failures means that more than one link or node in the ring can fail. Protection can still be performed
in the "islands" created in this way. A node failure is in fact the same as adjacent link failures.
We can provide more clarification. 
  1. I’d like to suggest to change term “exit node” to “egress node”.
[Huub] OK.
  1. Section 4.1 - The ring tunnel layer.
  • Given a ring of N nodes, this layer would consist of 4xN ring tunnels. The draft is a little light on the provisioning and management aspects of this layer, while pushing a lot of complexity to this layer.
[Huub] clarifying text can be added. We can add a section describing provisioning the ring-nodes.
  • Each node is traversed by many tunnels. How does it know whether a tunnel is working or protecting,  and whether a tunnel is CW or AW ? How does it associate a working tunnel with a protecting tunnel (to the same egress node, but opposite in direction) ?
[Huub] each node knows this because of the ring-map which contains this information.
  • When an ingress node needs a working tunnel to a particular egress node, how does choose between the CW  tunnel and the AW tunnel, especially when one is significantly longer  (i.e. of higher cost) than the other ?
[Huub] from the ring-map the ingress node knows what the shortest path is and then decides to take the CW or the AW tunnel.
  1. The draft describes 4 tunnels (CW, AW, CP, AP) per egress node ? Is it possible to use only 2 tunnels (i.e. CW and AW) and have them protect each other ?
[Huub] mixing working and protecting traffic in a single tunnel would make the RPS protocol more complex.
An egress node cannot make the distinction.
  1. Section 4.3.2 -- Short wrapping vs. “traditional wrapping”
  • Does “traditional wrapping” refer to the scenario in section 4.3.1 ?
[Huub] No it doesn't, section 4.3.1 explains wrapping for link failure and node failure.
[Huub] the description of traditional wrapping is in the first paragraph of section 4.3.2, more clarification can be added.
  • The 4.3.2 mode seems superior to the 4.3.1 mode in all aspects. If so, would there be any value to keep 4.3.1 mode.
[Huub] 4.3.1 explains wrapping methodology, its application is described in 4.3.2.
  • In 4.3.2 mode, CW tunnel ==CP tunnel and AW tunnel == AP tunnel in path topology, correct ? If so, you could reduce the number of tunnels per egress node from 4 to 2 (as comment [4] above), correct ?
[Huub] No, not correct. During a protection switch CW tunnel ==> AP tunnel and AW tunnel ==> CP tunnel.
  1. Section 4.3.3
  • This is equivalent to “global repair” in MPLS. However, why does the ingress node switch traffic from CW tunnel to AP tunnel instead of AW tunnel ? A working tunnel should be “better” than a protecting tunnel to permanently carry traffic.
[Huub] to operate properly ring protection switching has to be revertive, after repair the traffic should be switched back to working (shortest path)
  1. Section 4.4
  • I’m not sure how label swap would work on an interconnection node, as the draft describes it. In Fig-12, in normal state, F receives a packet from ring-1; The top label X is a tunnel to the node group; The next label Y is the service LSP. So, F pops label X, and “ the label used for working ring tunnel R2cW_I will be pushed based on the inner label” (i.e. label Y). How could F have the knowledge about the service LSP, its label Y, and its egress node, etc ?
[Huub] the ring-map has to take care of this.
  • I may have more questions to follow after the above…
Yimin Shen
Juniper Networks