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

Hi Eric,
Please see my answer in line...
Best regards,
Alessandro

-----Messaggio originale-----
Da: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
Inviato: giovedì 9 maggio 2013 17:41
A: D'Alessandro Alessandro Gerardo; mpls@ietf.org
Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr
Oggetto: RE: PSC: draft-rhd-mpls-tp-psc-priority-00

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?
[D'Alessandro] about point a, your statement is correct but does not address the actual issue. A more accurate interpretation is: If the protection path fails then service cannot recover promptly and it is interrupted because FS priority is higher than the SF-P priority.

> 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.
[D'Alessandro] I would prefer saying that 6378 must obey 5654, and that 5654 references 4427 in informative way.

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?
[D'Alessandro] yes, it does.
[D'Alessandro] Anyway I would like highlighting that according to RFC5654 R83A "External controls  ... unable to be signaled to the remote end (e.g., due to a coordination failure of the protection state) MUST be dropped". This requirement stated in RFC5654 applies to FS too and it appears to me overruling RFC 4427 which is referenced in an informative way from RFC5654.

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.

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.