Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

"BRUNGARD, DEBORAH A" <db3546@att.com> Fri, 10 May 2013 15:04 UTC

Return-Path: <db3546@att.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 949C421F8B64 for <mpls@ietfa.amsl.com>; Fri, 10 May 2013 08:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Q7NOQIsnU6K2 for <mpls@ietfa.amsl.com>; Fri, 10 May 2013 08:04:34 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2EA21F8B2B for <mpls@ietf.org>; Fri, 10 May 2013 08:04:34 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 28c0d815.2aaaf5a48940.157114.00-576.425696.nbfkord-smmo05.seg.att.com (envelope-from <db3546@att.com>); Fri, 10 May 2013 15:04:34 +0000 (UTC)
X-MXL-Hash: 518d0c8221fd42d4-6d0708bde05ab40a5775bb9f339829051959be86
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 18c0d815.0.157106.00-479.425667.nbfkord-smmo05.seg.att.com (envelope-from <db3546@att.com>); Fri, 10 May 2013 15:04:33 +0000 (UTC)
X-MXL-Hash: 518d0c81655bdee0-b4f757712485948647ad2ad459ef10c5d8e1ef2f
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4AF4Wg1016882; Fri, 10 May 2013 11:04:33 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4AF4Oke016748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 May 2013 11:04:27 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 10 May 2013 15:04:12 GMT
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 10 May 2013 11:04:12 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Lou Berger <lberger@labn.net>, "Eric Osborne (eosborne)" <eosborne@cisco.com>
Thread-Topic: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00
Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgP835SQAFx1EZAAFOjRgAAbKFJw
Date: Fri, 10 May 2013 15:04:12 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C82C9F37@MISOUT7MSGUSR9O.ITServices.sbc.com>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.234.214]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <db3546@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=M6z63VMs c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=RWEAq7CW3jcA:10 a=eeLOSi2EoM8A:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=LUSkZWHcu0cA:10 a=48vgC7mUAAAA:8 a=6n3J-JnjD85qh8]
X-AnalysisOut: [gd4KwA:9 a=wPNLvfGTeEIA:10 a=I7u-ks9roaUA:10 a=lZB815dzVvQ]
X-AnalysisOut: [A:10 a=Hr59RgoP3KgA:10 a=68PJXqtGKPpLVetU:21 a=iIDo4RZNUUw]
X-AnalysisOut: [icBvi:21]
Cc: "mpls@ietf.org" <mpls@ietf.org>, Morro Roberto <roberto.morro@telecomitalia.it>, Allasia Andrea <andrea.allasia@telecomitalia.it>, Nervo Giacolino <giacolino.nervo@telecomitalia.it>
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: Fri, 10 May 2013 15:04:40 -0000

Hi,

Agree with Lou, an update would be good for these documents considering the confusion.

As an author on RFC4427, it's intent was as an informative, generalized document on all types of recovery schemes. The definitions were (quite) shortened and so in this case the 2nd paragraph of G.808.1's definition regarding APS specifics was not included. RFC4427 didn't discuss state machines or any details of any specific scheme. When generalize, it helps with readability but there is always the danger of missed details. So on Eric's items, it falls under a third bullet: "written correctly though lacking in detail causing mis-interpretation":-)

RFC4427 fully intended to align with the ITU-T terminology and in the Recovery Terminology Section (Section 4) referred the reader to the ITU-T Recommendations:
"The reader is invited to read [G.841] and [G.808.1] for references to
   SDH protection and Generic Protection Switching terminology,
   respectively."

Thanks,
Deborah

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Thursday, May 09, 2013 5:25 PM
To: Eric Osborne (eosborne)
Cc: mpls@ietf.org; Morro Roberto; Allasia Andrea; Nervo Giacolino
Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

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