Re: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 01 September 2016 09:10 UTC
Return-Path: <adrian@olddog.co.uk>
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 C06F412D8B1; Thu, 1 Sep 2016 02:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level:
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 qXLwkMB9lQpI; Thu, 1 Sep 2016 02:10:25 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF8612D8AE; Thu, 1 Sep 2016 02:10:24 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u819AEO3023796; Thu, 1 Sep 2016 10:10:14 +0100
Received: from 950129200 (dsl-dp-81-140-107-254.in-addr.broadbandscope.com [81.140.107.254]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u819ADE4023764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2016 10:10:14 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Ryoo, Jeong-dong '" <ryoo@etri.re.kr>, mpls@ietf.org
References: <5B4A6CBE3924BB41A3BEE462A8E0B75A2920D092@SMTP2.etri.info>
In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A2920D092@SMTP2.etri.info>
Date: Thu, 01 Sep 2016 10:10:14 +0100
Message-ID: <025d01d20430$a7340030$f59c0090$@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: AQE6IgkAOjwH1Zb7MLTfwNYbUalas6GUGncw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22548.006
X-TM-AS-Result: No--12.061-10.0-31-10
X-imss-scan-details: No--12.061-10.0-31-10
X-TMASE-MatchedRID: O/y65JfDwwvZfnct5UBzcdOEZs/2oH3cbv16+gil4jfVMpDytURQKGhx r49KyC8UZzYmwg97TtDijpjet3oGSD4Pcn5OGAtGQpxiLlDD9FWBjLzL4do+Vjdnd59Af7CPqOD wu+49pCU45BFGt6sIDh+3WNmz9u9/qg580YCtM3MuLk8NfSpYep6KYa03LCO2myiLZetSf8mZMP CnTMzfOiq2rl3dzGQ1CDT7/aDNwmE9ArmpKn67PwUxnHcLggXPlPkXnDDMdhLAh3VIcO/KuQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/CHHnuhVbC2WXPiacL6jRBoEpDEs>
Cc: 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
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: <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:10:26 -0000
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
- [mpls] Text proposal on draft-ietf-mpls-tp-aps-up… Ryoo, Jeong-dong
- Re: [mpls] Text proposal on draft-ietf-mpls-tp-ap… Adrian Farrel
- Re: [mpls] Text proposal on draft-ietf-mpls-tp-ap… Ryoo, Jeong-dong