Re: [mpls] 회신: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Fri, 04 March 2016 11:10 UTC

Return-Path: <matthew.bocci@nokia.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 DFFBD1B36A2 for <mpls@ietfa.amsl.com>; Fri, 4 Mar 2016 03:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 v7srHTuMSslC for <mpls@ietfa.amsl.com>; Fri, 4 Mar 2016 03:10:07 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5711A1B368C for <mpls@ietf.org>; Fri, 4 Mar 2016 03:10:06 -0800 (PST)
Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 135CA34AEAA5; Fri, 4 Mar 2016 11:10:02 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u24BA3nc022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2016 11:10:04 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u24B9Ab3003897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Mar 2016 12:10:01 +0100
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.15]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 4 Mar 2016 12:06:58 +0100
From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
To: EXT 류정동 <ryoo@etri.re.kr>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "draft-ryoo-mpls-tp-aps-updates@tools.ietf.org" <draft-ryoo-mpls-tp-aps-updates@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Thread-Topic: 회신: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt
Thread-Index: AQHRdgX3BAXidtpzsEGSb5zHe/4kug==
Date: Fri, 04 Mar 2016 11:06:58 +0000
Message-ID: <D2FF18A5.95570%matthew.bocci@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6B7B5DE1D7FB2640902D7B752FC43E2D@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/ZxTKDKz2A6v11FFPcGof-bQVc-w>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] 회신: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Mar 2016 11:10:12 -0000

Jong-dong

Thank you for your clarifications. I am fine with these.

Regards

Matthew

On 24/02/2016, 15:02, "EXT 류정동" <ryoo@etri.re.kr> wrote:

>Mattew,
>
>Thank you for your review and comments.
>
>This work of updating RFC 7271 was triggered by
>comments raised by people working on three independent
>implementations of RFC 7271.
>
>I am not sure about the IETF and/or MPLS WG process of exposing
>the names of the companies that implement this RFC as it might
>be sensitive to some of those companies.
>But, as far as I know, there are more than ten equipment vendors who
>implemented or are implementing RFC 7271
>(or ITU-T Recommentation G.8131, which is in line with
>and has the same technical contents as RFC 7271).
>
>A few weeks ago, a South Korean government owned national backbone
>network started being operated with protection provided by RFC 7271.
>Also, we anticipate that major Korean network operators will
>use this technology when their packet transport networks are
>expanded or upgraded as they want to run their networks with
>implementations complying with Internation Standards.
>
>Regarding your comment on Section 4.1,
>the authors' intention is not to define any new state, like INIT.
>However, we understand that your comment is triggered by the facts
>that implementation of the last two bullets (SD and EXER)
>may require some internal states.
>we consider this is an internal implementation decision
>and outside of the scope of this document.
>
>For your nits on Section 4.2,
>we will incorporate them in revision.
>
>Again, I appreciate your time and effort to review the draft.
>
>Best regards,
>
>Jeong-dong
>
>
>
>________________________________________
>보낸 사람: Bocci, Matthew (Nokia - GB) [matthew.bocci@nokia.com] 대신 mpls
>[mpls-bounces@ietf.org]
>보낸 날짜: 2016년 2월 22일 월요일 오후 8:41
>받는 사람: draft-ryoo-mpls-tp-aps-updates@tools.ietf.org;
>mpls-chairs@tools.ietf.org
>참조: mpls@ietf.org
>제목: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt
>
>Authors
>
>I have been selected as an MPLS Review team reviewer for
>draft-ryoo-mpls-tp-aps-updates-02.txt.
>
>In general, I think the draft is technically sound and it is useful to
>provide clarification to sections of RFC7271 if it is the case that this
>is actually causing confusion to implementers. However, I would encourage
>the working group to think about how widely implemented and deployed
>RFC7271 is before progressing this work, since spending working group time
>on something that is not being widely implemented does not seem useful.
>
>Minor Comments/Nits
>‹‹‹‹‹‹‹‹‹‹‹‹‹‹
>4.1
><https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1
>>
>.  Initialization Behavior
>
>   This section defines initialization behavior that is not described in
>   [RFC7271 <https://tools.ietf.org/html/rfc7271>].
>
>MB> It is a little unclear if this is adding a new INIT state to the state
>machine that you can transit to from one or more other states, or if this
>is just stating initial conditions before APS becomes operational. Please
>can you clarify?
>
>4.2
><https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.2
>>
>.  State Transition Modification
>
>   In addition to the initialization behavior described in Section 4.1
><https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1
>>
>,
>   four cells of remote state transition table need to be changed to
>   make two end nodes converged after initialization.
>
>MB> s/four cells of remote state/ four cells of the remote state
>MB> s/two end nodes converged / two end nodes converge
>
>
> Best regards
>
>Matthew
>
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls