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

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
>