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

"Ryoo, Jeong-dong" <ryoo@etri.re.kr> Mon, 06 January 2014 03:10 UTC

Return-Path: <ryoo@etri.re.kr>
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 0A3B01ADF64 for <mpls@ietfa.amsl.com>; Sun, 5 Jan 2014 19:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.457
X-Spam-Level:
X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 eWhnVNqVFAPJ for <mpls@ietfa.amsl.com>; Sun, 5 Jan 2014 19:10:33 -0800 (PST)
Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0761ADF63 for <mpls@ietf.org>; Sun, 5 Jan 2014 19:10:32 -0800 (PST)
Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Jan 2014 12:10:16 +0900
Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Mon, 6 Jan 2014 12:10:15 +0900
From: "Ryoo, Jeong-dong" <ryoo@etri.re.kr>
To: Qin Wu <bill.wu@huawei.com>, "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+gQR6SgP
Date: Mon, 06 Jan 2014 03:10:15 +0000
Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7B@SMTP2.etri.info>
References: <B8F9A780D330094D99AF023C5877DABA43C6C955@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43C6C955@nkgeml501-mbs.china.huawei.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-new-displayname: UnlvbywgSmVvbmctZG9uZw==
x-originating-ip: [129.254.28.46]
Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286AFE7BSMTP2etriinfo_"
MIME-Version: 1.0
Subject: Re: [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, 06 Jan 2014 03:10:36 -0000

Qin, thanks for your comments.

Please, see in lines ...

Best regards,

Jeong-dong




________________________________
From : "Qin Wu" <bill.wu@huawei.com>
Sent : 2013-12-16 16:25:49 ( +09:00 )
To : mpls@ietf.org <mpls@ietf.org>, mpls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>
Cc :
Subject : [mpls] wglc on draft-ietf-mpls-smp-requirements

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.
 [Jeong-dong] SMP is a data plane protocol, which may need some supports from management plane for configuration, alarm, etc.


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.
[Jeong-dong] Yes, it needs to be fixed. A candidate might be RFC 4426 - GMPLS Recovery Functional Specification.


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?
[Jeong-dong]  "criss-cross" from Oxford Dictionaries:
 (verb ) [with object] form a pattern of intersecting lines or paths on (a place); the green hill was criss-crossed with a network of sheep tracks,  [no object]: the smaller streets criss-crossed in a grid pattern; move or travel around (a place) by going back and forth repeatedly: the President criss-crossed America

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.
[Jeong-dong] Selector is in the endpoints of the working and protection paths and selects the traffic from one of the paths. Please see RFC 4427, which is normatively referred by this document.


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?
[Jeong-dong]  The business priority can be thought as the priority assigned to a path according to the policy of network administration.


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
[Jeong-dong] This should be fixed.


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?
in
Is there any common behavior between soft preemption and hard preemption?
It is better to be clear about this in the text.
[Jeong-dong] The last bullet applies during preemption. It means that while the preemption action is in progress, the traffic should be  treated as specified in the last bullet.


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?
[Jeong-dong] protection switching time = transfer time in G.808.1 = recovery switching time in RFC4427


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?
[Jeong-dong] A single failure can trigger the protection switching actions both in server layer (OTN for example) and client layer (MPLS-TP for example).

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?
[Jeong-dong] See the above answer.  For better clarification, we can rewrite it something like:
   "In order to prevent multiple switching actions for a single switching
   trigger when there are multiple layers of networks,
   SMP SHOULD be controlled by a hold-off timer that would
   allow lower layer mechanisms to complete their switching actions
   before invoking SMP protection actions."


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

________________________________