[mpls] wglc on draft-ietf-mpls-smp-requirements

Qin Wu <bill.wu@huawei.com> Mon, 16 December 2013 07:25 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E81AE2BF for <mpls@ietfa.amsl.com>; Sun, 15 Dec 2013 23:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me0t431_3dfY for <mpls@ietfa.amsl.com>; Sun, 15 Dec 2013 23:25:12 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA9891AE2BA for <mpls@ietf.org>; Sun, 15 Dec 2013 23:25:10 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZA99476; Mon, 16 Dec 2013 07:25:09 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 07:23:37 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 07:24:01 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 15:23:56 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Thread-Topic: [mpls] wglc on draft-ietf-mpls-smp-requirements
Thread-Index: Ac76L8gPAbx7QpzERKO4dZ+zkusX+g==
Date: Mon, 16 Dec 2013 07:23:56 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43C6C955@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C6C955nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [mpls] wglc on draft-ietf-mpls-smp-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 07:25:18 -0000

Hi,all:
I have reviewed draft-ietf-mpls-smp-requirements. Here are a few comments I have below.
1. Abstract said:
"
This document presents the basic network objectives for the behavior
of shared mesh protection (SMP) not based on control-plane support.

"
[Qin]: Can SMP behavior be based on management plane, if not, why not say the SMP behavior is based on data-plane support directly.

2. Section 1, Paragraph two said:
"
MPLS provides control-plane tools to support various survivability
   schemes (Editor's note - add references).

"
[Qin]: What reference should be put here needs to be fixed.

3. Section 1, Paragraph three said:
"
When considering a full-mesh network and the protection of different
   paths that criss-cross the mesh, it is possible to provide an
   acceptable level of protection while conserving the amount of
   protection resources needed to protect the different data paths.

"

[Qin]: It is not clear to me what criss-cross is? Would it be good to add a reference for "criss-cross" here?

4.Section 4, it said:
"
"Hard Preemption" requires the programming of selectors at the ingress of
each shared segment to enforce which backup path has the highest
priority when committing protection resources, the others being
preempted.

"

[Qin]: Is selector one of protection endpoints? Is selector belong to shared segment or unshared

portions of segment? Is selector in the protection path or working path?
It is better to be clear in the text.

5. Section 5.1, last paragraph said:
"
What is required is a preemption mechanism to
   implement business priority when multiple failure scenarios occur.

"
[Qin]: Is priority business related or policy decision related? Can both preemption and priority
policy decision related? It is not clear to me the difference between business related and policy
decision related. Would you like to clarify a little bit?

6. Section 5.2, 1st  paragraph said:
"
For those networks, in particular for networks that support the requirements in
[RFC5654][and in particular support for requirement 58], that require
the exclusive use of the protection resources, i.e. hard preemtion,
the following behavior SHOULD be supported:
"
[Qin]: s/preemtion/preemption

7.Section 5.2, last bullet said:
"
During preemption, if there is an over subscription of resources
protected traffic SHOULD be treated as defined in [RFC5712] or
[RFC3209]
"
[Qin]s/[RFC3209]/[RFC3209].

[Qin]: It is not clear to me why soft preemption behavior defined
in RFC5712 should be applied to hard preemption part of section
5.2 described in this document?

Is there any common behavior between soft preemption and hard preemption?
It is better to be clear about this in the text.

8.Section 5.5, 1st paragraph said:
"
   Protection switching time refers to the transfer time (Tt) defined in
   [G.808.1] and recovery switching time defined in [RFC4427], and is
   defined as the interval after a switching trigger is identified until
   the traffic begins to be transmitted on the protection path.

"

[Qin]:
What the relationship between "protection switching time"
and "transfer time" or "recovery switching time"
Can I parse this relation as:
Protection switching time = the transfer time + recovery switching time?

9.Section 5.5, 1st paragraph said:
"
   In order to prevent multiple switching actions for a single switching
   trigger, SMP SHOULD be controlled by a hold-off timer that would
   allow lower level mechanisms to complete their switching actions
   before invoking SMP protection actions.

"
[Qin]:Why are there multiple switching actions for a single switching
trigger? Isn't one switching trigger corresponding to one switching action?
Can you give an example for that?

10.Section 5.5, 1st paragraph said:
"
   In order to prevent multiple switching actions for a single switching
   trigger, SMP SHOULD be controlled by a hold-off timer that would
   allow lower level mechanisms to complete their switching actions
   before invoking SMP protection actions.

"

[Qin]:What lower level means? What the difference between low level
and high level? Does this relate to lower priority or high priority?


On Tue, Dec 10, 2013 at 8:37 AM, Loa Andersson <loa at pi.nu> wrote:
> Working Group,
>
>
> this is to start a 2 week working group last call on
> draft-ietf-mpls-smp-requirements-02.
>
> Please review the document and send comments to the MPLS WG
> mailing list (mpls at ietf.org) .
>
> There are no IPR claims against this document.
>
> All the authors have stated on the MPLS wg mailing list that they
> are unaware of any IPRs that relate to this document.
>
> The working group last call ends Monday December 27 - 2013.
>
> Yes - that is is in the middle of the Holiday season, but at least
> one wg chair will be working partly between Xmas and New Year and be
> able to evaluate next steps. We count on most reviews taking place
> in the almost two weeks before Xmas.
>
> /Loa

________________________________