Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00
Yuji Tochio <tochio@jp.fujitsu.com> Thu, 30 May 2013 05:29 UTC
Return-Path: <tochio@jp.fujitsu.com>
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 9E46A21F930C for <mpls@ietfa.amsl.com>; Wed, 29 May 2013 22:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level:
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGQzFBTCPqL6 for <mpls@ietfa.amsl.com>; Wed, 29 May 2013 22:29:50 -0700 (PDT)
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id 298A421F9301 for <mpls@ietf.org>; Wed, 29 May 2013 22:29:50 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id AF5343EE0C1 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 9F9C345DE3E for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8A54245DE56 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7EE5F1DB8046 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2B0B6E08006 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r4U5ThJN011518 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:48 +0900 (JST)
X-AuditID: 0a19c027-b7f866d00000132d-5c-51a6e3cbd2e1
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id 33.BB.04909.BC3E6A15; Thu, 30 May 2013 14:29:48 +0900 (JST)
Received: from [127.0.0.1] (dhcp92.dream.flab.fujitsu.co.jp [10.25.144.163]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id r4U5ThDG017913 for <mpls@ietf.org>; Thu, 30 May 2013 14:29:47 +0900 (JST)
X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4
Message-ID: <51A6E3A0.5050107@jp.fujitsu.com>
Date: Thu, 30 May 2013 14:29:04 +0900
From: Yuji Tochio <tochio@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mpls@ietf.org
References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> <518C1431.70204@labn.net>
In-Reply-To: <518C1431.70204@labn.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsXCJXkgU/fM42WBBu/vMFrcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGc0Tp7EVnDSoWNB0lKWB8Yh6FyMnh4SAicTR+T+YIWwxiQv3 1rN1MXJxCAk8ZpQ40biLHcLpZpI4cXQTI0SVqcTEdc/AbF4BXYlHV5qAOjg4WARUJV79LAEJ swloSlybeQesRFQgWOL7trvMEOWCEidnPmEBsUWA7GlXj4LZwgJWEgf3bWGC2PWVUaLl3Bw2 kASngJrExwNTwGxmATOJrq1djBC2vETz1tnMExgFZiGZOwtJ2SwkZQsYmVcxSpYVZyeWJ+ql 5SQm6aWVZmWWFJfqJefrZRVsYoQEo/oOxmeLNA8xCnAwKvHwfuleFijEmlhWXJl7iFGCg1lJ hHf+XqAQb0piZVVqUX58UWlOavEhRiYOTqkGRlYfo0nv1HRPBu6a5tS4vSP3BMvkE28d5c2P qLGWclus+DqN/4x20ezfYlkqBXvn+LC+ehX+bOMr34xd02rvyp6pvhva3yTb1JUS/Wp95Nri 5/YL5861WfFkBzunfW8F+43jK67y/maT5L0+jW2/zOJL925/sZc3/rKmxNWgU9h9SnDJu/CM 2UosxRmJhlrMRcWJALM1iTIkAgAA
Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 30 May 2013 05:29:54 -0000
Hi, Reading Lou's comment and LS to ITU-T ( http://datatracker.ietf.org/liaison/1256/ ), I had read RFC 6372 again. As well as the comments below, I also found at the last paragraph in section 4.1.1 as: -- <..> o Force a switchover from a working path to a recovery path or vice versa. Forced switchover may be performed for network optimization purposes with minimal service interruption, <..> -- My question is "Is this rational for the priority between FS and SF-P?" My understanding it should be swapped and update should be in RFC 6378 as I addressed before. So I would like to ask for clarification on this point. If this has been already pointed out and discussed please ignore , but the last sentence of the last paragraph in section 4.1.1 in RFC 6372 should be fixed as editoral (s/Section 4.12/Section 4.13/, since 4.12 is Failure Reporting ) Just my 2c, Yuji (2013/05/10 6:25), Lou Berger wrote: > Eric, > I think you might have missed that rfc6372 section 6.1.2 is consistent > with RFC4427. So perhaps it would be best to have a standalone > draft/rfc that updates both rfc6372 and rfc4427 on this specific point > alone. If this is done, no change to rfc5654 is needed. > > Lou > > On 5/9/2013 11:40 AM, Eric Osborne (eosborne) wrote: >> Hi Alessandro, see inline. >> >>> -----Original Message----- >>> From: D'Alessandro Alessandro Gerardo >>> [mailto:alessandro.dalessandro@telecomitalia.it] >>> Sent: Tuesday, May 07, 2013 3:27 PM >>> To: Eric Osborne (eosborne); mpls@ietf.org >>> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; >>> ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr >>> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 >>> >>> Hi Eric, >>> You wrote "is it appropriate to make this priority swap?" >>> My answer is yes, it shall be done for the reasons explained in liaison >>> 1205, bullet 1. >> Let me paraphrase the three points in those bullets, I want to make sure I understand them: >> >> a. If the protection path fails then the removal of the FS will not be seen because the channel used to provide it is gone. >> b. If there is SF-P and FS is issued by accident then this will cause an outage, which is Bad >> c. (points to Annex 1): similar to (a) above, the loss of the protection channel means there will be an inconsistency in the protection state >> >> Is that an accurate paraphrase? >> >>> You wrote "- what do we need to change? rfc5654? rfc4427? " >>> No I don't believe it is required to change any RFC but RFC 6378 >> To me this decision is a matter of process rather than of technical behavior. >> I believe the current set of opinions is this: >> >> a) some believe that rfc4427 requires the current set of priorities, as per LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) >> b) some believe it does not, and that rfc6378 misinterpreted rfc4427 >> >> I think we all agree that the chain here is: 6378 must obey 5654, and that 5654 requires 4427. >> >> So it's going to come down to - is 4427 written wrong but interpreted correctly, or written correctly but misinterpreted? >> If we decide the former, we need to change 4427 and/or 5654 to clarify the requirement. >> If we decide the latter, we do not need to change 4427 and can probably just change 6378. >> >> Does that sound right? >> >> >> >> eric >> >>> Best regards, >>> Alessandro >>> >>> ------------------------------------------------------------------ >>> Telecom Italia >>> Alessandro Gerardo D'Alessandro >>> Transport Innovation >>> Via Reiss Romoli, 274 - 10148 Torino >>> phone: +39 011 228 5887 >>> mobile: +39 335 766 9607 >>> fax: +39 06 418 639 07 >>> >>> >>> -----Messaggio originale----- >>> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di >>> Eric Osborne (eosborne) >>> Inviato: mercoledì 17 aprile 2013 14:16 >>> A: mpls@ietf.org >>> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 >>> >>> This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In >>> brief, the draft proposes swapping the priorities between FS and SF-P >>> (see section 4.3.2 of rfc6378). This proposed swap has a long history, >>> dating back to when PSC was an ID. For some history, see >>> >>> http://datatracker.ietf.org/liaison/1229/ >>> and >>> http://datatracker.ietf.org/liaison/1234/ >>> >>> The questions that I think are relevant here are: >>> >>> - is it appropriate to make this priority swap? >>> - are there alternative approaches? >>> - what do we need to change? rfc5654? rfc4427? >>> - if we don't make the change, does this expose implementation to >>> problems? >>> - if we do make the change, how do we go about it? >>> >>> but of course any and all discussion is welcome. >>> >>> As with the other threads I'm going to leave my two cents out of this >>> introductory email but I'll chime in when discussion starts. >>> >>> >>> >>> >>> >>> eric >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>> persone indicate. La diffusione, copia o qualsiasi altra azione >>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>> cortesemente pregati di darne immediata comunicazione al mittente e di >>> provvedere alla sua distruzione, Grazie. >>> >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is unauthorised. >>> If you are not the intended recipient, please delete this message and >>> any attachments and advise the sender by return e-mail, Thanks. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >
- [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Eric Osborne (eosborne)
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Yuji Tochio
- [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 D'Alessandro Alessandro Gerardo
- Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority… Huub van Helvoort
- Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority… Yaacov Weingarten
- Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority… Huub van Helvoort
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Eric Osborne (eosborne)
- [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 D'Alessandro Alessandro Gerardo
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Lou Berger
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 BRUNGARD, DEBORAH A
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Cavazzoni Carlo
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Pablo Frank
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Ryoo, Jeong-dong
- Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Yuji Tochio