Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 26 January 2014 12:14 UTC
Return-Path: <adrian@olddog.co.uk>
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 21E101A0138 for <mpls@ietfa.amsl.com>; Sun, 26 Jan 2014 04:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 nqjDj19usJXo for <mpls@ietfa.amsl.com>; Sun, 26 Jan 2014 04:14:01 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A34B41A0136 for <mpls@ietf.org>; Sun, 26 Jan 2014 04:14:01 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QCDq4M019169; Sun, 26 Jan 2014 12:13:53 GMT
Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0QCDnnU019145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jan 2014 12:13:50 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Ryoo, Jeong-dong'" <ryoo@etri.re.kr>, 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org
References: <0bc301cf16ea$3981cd00$ac856700$@olddog.co.uk> <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info>
In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A286B3846@SMTP2.etri.info>
Date: Sun, 26 Jan 2014 12:13:48 -0000
Message-ID: <009101cf1a90$132a5d30$397f1790$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIDDGELNpZkSuNS/NSgW0Szz71cHAI+7oqomh0Mk1A=
Content-Language: en-gb
Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org
Subject: Re: [mpls] AD review : working group last call draft-ietf-mpls-tp-psc-itu-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sun, 26 Jan 2014 12:14:03 -0000
Hi Jeong-dong, > In my opinion, all the wording from AD review should be taken except the > followings that I would need further clarifications or confirmations from AD: > --- > Abstract and Introduction > Due to the limitation in the length of Abstract and the nature of the abstract, > which gives the main points of *this* document, I would like to see if we can > add the sentence in the Introduction section only. Yes. Good point. > Section 4.1 > The second paragraph in Section 4.1 is to emphasis the importance of the > PSC communication channel in delivering the external switch command, > so that the failure of PSC communication channel has higher priority than FS. > I would like to propose to change the paragraph as follows: > === OLD === > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means > that external switch commands, e.g., FS, can be transferred to the > remote Label Edge Router (LER) only by using the PSC communication > channel and should not rely on the presence of a control plane. > === NEW === > According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to > operate an MPLS-TP network without using a control plane. This means > that the PSC communication channel is very important for the transfer > of external switch commands (e.g., FS), and these commands should not > rely on the presence of a control plane. In consequence, the failure > of the PSC communication channel has higher priority than FS. Yes. Thanks. I had completely missed this point. Your new wording is helpful. > Section 4.3 > You suggested “s/broken, the Freeze command,/broken. > The Freeze command,/”. > But, my reading of two separate sentences is not ok. The > first sentence doesn’t seem to be complete. Would you > please check this again? You're right. My mistake. Leave it as it is. > Sections 9.1.1, Section 9.1.2, Section 9.1.3.2 and Section 9.1.3.3 > For those four comments on Section 9, I can understand the > concerns. In my opinion, the questions given in the AD review > comments are very valid and should be answered. I think the > text needs to be changed rather significantly. I will prepare a > new text proposal and further communicate with Adrian. OK. I'll look for that. Many thanks for the quick turn around and the constructive approach. Regards, Adrian
- [mpls] AD review : working group last call draft-… Adrian Farrel
- Re: [mpls] AD review : working group last call dr… Ryoo, Jeong-dong
- Re: [mpls] AD review : working group last call dr… Adrian Farrel
- Re: [mpls] AD review : working group last call dr… Ryoo, Jeong-dong
- Re: [mpls] AD review : working group last call dr… Adrian Farrel