[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 ________________________________
- [mpls] wglc on draft-ietf-mpls-smp-requirements Loa Andersson
- Re: [mpls] wglc on draft-ietf-mpls-smp-requiremen… Andrew G. Malis
- [mpls] wglc on draft-ietf-mpls-smp-requirements Qin Wu
- Re: [mpls] wglc on draft-ietf-mpls-smp-requiremen… Loa Andersson
- Re: [mpls] wglc on draft-ietf-mpls-smp-requiremen… Sam Aldrin
- Re: [mpls] wglc on draft-ietf-mpls-smp-requiremen… Ryoo, Jeong-dong
- Re: [mpls] wglc on draft-ietf-mpls-smp-requiremen… Qin Wu