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

Huub van Helvoort <> Sun, 12 July 2015 10:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CE5EE1ACDD9 for <>; Sun, 12 Jul 2015 03:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z4k50h97KQ3N for <>; Sun, 12 Jul 2015 03:46:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2945A1ACDD8 for <>; Sun, 12 Jul 2015 03:46:08 -0700 (PDT)
Received: by wiwl6 with SMTP id l6so78554501wiw.0 for <>; Sun, 12 Jul 2015 03:46:07 -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=xyJVHSTX8jVUhQ6Uh8fnCIKaYOpjmrOUJg3LblCvfFI=; b=JhaG+h3qxU2t7CyjWoZ5gD9TFDRuBrXQCpm8G9rk1iTBx3LVyAsMkY6eGdnC8ICXC0 7YyCIk7Z/3dhxyRyx8li1P2l3WFsU+dpsYzvlHL4XeLZmSjAWeHe2XkvPpHQmCPOUyXz yBA/GS3kzP/X/trDB7Xf72gqW9jk+lYr61REWbnC+lYo5+TVlbfrPuvoDYFNY0h3jGjd KgYi9YqUyyKcpJdI9vpFpE3sBV1pDzl5G/djJRae4DxyuM5OsNddgiyBRD0bkkrqf0pB IFlpwFERdVyLksViSlbMzA+cv9ikwzCvNv+6Lx1rjHbXwrv8RY/fzLggMyVkFhZwhFyD lutQ==
X-Received: by with SMTP id d2mr7385152wik.48.1436697966895; Sun, 12 Jul 2015 03:46:06 -0700 (PDT)
Received: from McAsterix.local ( []) by with ESMTPSA id o6sm8100252wiz.16.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2015 03:46:05 -0700 (PDT)
Message-ID: <>
Date: Sun, 12 Jul 2015 12:46:40 +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: Gregory Mirsky <>, Weiqiang Cheng <>, Ross Callon <>, "" <>, "" <>, "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: lifang <>, "" <>, weiqiang cheng <>, "" <>, Han Li <>, "" <>, WANG Lei <>, "" <>
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 10:46:10 -0000

Hello Greg,

Please find in-line some more responses [Huub]
on behalf of the authors.

Note that I snipped agreed proposals.

Regards, Huub.


The document is coherent, well written and proposes solution to practical scenario. But I’ve found that the document has certain overlap with draft-cui-mpls-tp-mfp-use-case-and-requirements at least in large parts of Section 2 of the draft-cheng-mpls-tp-shared-ring-protection-05. I believe it would bebeneficial if both groups of authors work together  to have single informational draft on requirements towards protection in MPLS-TP under multi-failure condition and have Ring and Interconnected Ring discussed as use cases, including requirements toward Ring Switch Protection protocol.
[Authors] Thanks a lot for your suggestion. Draft-cui described general requirements of Multi-failure protection, and Draft-cheng addressed some multi-failure scenarios. We will contact authors of draft-cui to see if we can work together with them on a requirements and use cases draft or we can contribute some text to draft-cui.

[Huub] draft-cui-mpls-tp-mfp-use-case-and-requirements describes use cases
for end-to-end linear protection only, although that is not specifically mentioned
in that draft. It is not applicable to ring protection.
The multiple failure condition in rings is related to link or node failures along the ring.


·         Section 4.1.3 bullet 4 is hard to parse and once I’ve interpreted it cannot see it fit logically with other comments to Fig.4
[Authors] We will rephrase the section, and make it more clear.

[Huub] we are considering removing bullet 4, it is indeed confusing.

·         Section 4.2
o   I think that proposed protection mechanism uses link OAM and Continuity Check (CC) may be sufficient thus making Connectivity Verification unnecessary;
[Authors] Agree, we will change CC-V to CC.

[Huub] in RFC6371 the term CC-V is used. The CC and CV function are combined in the same
OAM packet that is used in pro-active mode.
The SF detected by the CC-V will trigger protection switch. ITU Document


·         Section discusses node failure scenario but, in fact, the scenario is not much different from link failure discussed already. I believe that the node failure scenario is most interesting to demonstrate behavior of protection mechanism and data flow when the egress (exit) node is the one that failed. Would wrapping prevent from forming infinite loop? Or wrapping without RSP protocol would create infinite loops? What about TTL handling?
[Authors]Agree, we will add some more text to make it more clear.

[Huub] note that wrapping is performed based on the source and destination node information
in the RPS packet and the information in the ring-map present in each ring node.
This will prevent infinite loop.


·         Section 6. It may be beneficial to request IANA to create new registry RSP Request Code registry and allocate codes listed in the table on p.25. And define values not listed in the table as Reserved, e.g. 0b0010, 0b0100, 0b0111, etc.
[Authors]Agree, we will add it.

[Huub] we will use the same IANA request as was used for linear protection.
Section 5 of RFC6378. (for consistency).