Re: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates

"Ryoo, Jeong-dong " <ryoo@etri.re.kr> Thu, 01 September 2016 09:38 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04712D8A3; Thu, 1 Sep 2016 02:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level:
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 H0pjDoNQBqtQ; Thu, 1 Sep 2016 02:38:26 -0700 (PDT)
Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE5512D773; Thu, 1 Sep 2016 02:38:14 -0700 (PDT)
Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Sep 2016 18:38:12 +0900
Received: from SMTP2.etri.info ([169.254.2.208]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Thu, 1 Sep 2016 18:38:11 +0900
From: "Ryoo, Jeong-dong " <ryoo@etri.re.kr>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates
Thread-Index: AdIBGo2gkC393KBrS1q/KfR+z4PAYwCyqikAABOnFpM=
Date: Thu, 01 Sep 2016 09:38:11 +0000
Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2921110D@SMTP2.etri.info>
References: <5B4A6CBE3924BB41A3BEE462A8E0B75A2920D092@SMTP2.etri.info>, <025d01d20430$a7340030$f59c0090$@olddog.co.uk>
In-Reply-To: <025d01d20430$a7340030$f59c0090$@olddog.co.uk>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-new-displayname: UnlvbywgSmVvbmctZG9uZyA=
x-originating-ip: [129.254.28.42]
Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2921110DSMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/8hHjVVv6vpBARCUyFRc1ADE4je4>
Cc: "draft-ietf-mpls-tp-aps-updates.chairs@ietf.org" <draft-ietf-mpls-tp-aps-updates.chairs@ietf.org>
Subject: Re: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 01 Sep 2016 09:38:35 -0000

Thank you for your review and support, Adrian.


Yes, you captured it correctly.

When a revised draft is uploaded, it should show your suggested text.


Best regards,


Jeong-dong







________________________________
보낸 사람 : "Adrian Farrel" <adrian@olddog.co.uk>
보낸 날짜 : 2016-09-01 18:10:26 ( +09:00 )
받는 사람 : 류정동 <ryoo@etri.re.kr>, mpls@ietf.org <mpls@ietf.org>
참조 : draft-ietf-mpls-tp-aps-updates.chairs@ietf.org <draft-ietf-mpls-tp-aps-updates.chairs@ietf.org>
제목 : RE: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates



Jeong-dong, all,





Although I don't have an implementation, I am in favour of fixing our RFCs, so I support moving this document forward.





The motivation for your changes looks good. Just some polish to what you propose...





> 4.3. Operation related to State Transition Table Lookup



>



> In addition to the rules related to the state transition table



> lookup listed in Section 11 of [RFC7271], the following rule is



> also applied to the operation related to the state transition



> table lookup:



> O When the local SF-P is cleared and the priorities of the



> local and remote requests are re-evaluated,



> the last received remote message may not be valid any more



> due to the previous failure of the protection path and only



> the local request SHALL be evaluated assuming that the



> remote request is NR.





Suggest to break this into two sentences for clarity. I think I have captured your meaning.





O When the local SF-P is cleared and the priorities of the



local and remote requests are re-evaluated,



the last received remote message may not be valid any more



due to the previous failure of the protection path. Therefore,



the last received message MUST be treated as if it were NR



and only the local request shall be evaluated.





Thanks,



Adrian