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

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Tue, 7 May 2013 19:26:55 +0000

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.

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

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: [email-masked] [mailto:[email-masked]] Per conto di Eric Osborne (eosborne)
Inviato: mercoledì 17 aprile 2013 14:16
A: [email-masked]
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
[email-masked]
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.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 08 May 2013 21:22:37 +0200

Hi,

> My answer is yes, it shall be done for the reasons explained in liaison 1205, bullet 1.

It should be mandatory to swap to provide consistent behaviour.

> No I don't believe it is required to change any RFC but RFC 6378

Indeed RFC6378 should be fixed.

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 8 May 2013 22:45:01 +0300

Huub, hi

Not sure how consistent your answers are in this email.

You believe that the priority swap should be instituted "to provide
consistent behavior", Yet you say that the change should be made to
RFC6378, which would make the behavior inconsistent with RFC4427.

So do we want to be consistent or inconsistent?

BR,
yaacov

On Wed, May 8, 2013 at 10:22 PM, Huub van Helvoort <[email-masked]>wrote:

>> 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/<http://datatracker.ietf.org/liaison/1229/>
>> and
>> http://datatracker.ietf.org/**liaison/1234/<http://datatracker.ietf.org/liaison/1234/>
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mpls<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
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>>
>>
>
> --
> *********************************************************************
>               请记住，你是独一无二的，就像其他每一个人一样
>
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 08 May 2013 22:27:48 +0200

Yaacov, hi,

> RFC6378, which would make the behavior inconsistent with RFC4427.

As explained in liaison http://datatracker.ietf.org/liaison/1234/
we would like consistency with other transport network linear
protection mechanisms.

> So do we want to be consistent or inconsistent?

If you want consistency between linear protection (using data plane
protocols) and linear restoration (using control plane protocols) you
should consider changing RFC4427 too.

Regards, Huub.

> On Wed, May 8, 2013 at 10:22 PM, Huub van Helvoort <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
> 
>         Hi Eric,
>         Da: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         Per conto di Eric Osborne (eosborne)
>         A: [email-masked] <mailto:[email-masked]>
>         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/
>         <http://datatracker.ietf.org/liaison/1229/>
>         and
>         http://datatracker.ietf.org/__liaison/1234/
>         <http://datatracker.ietf.org/liaison/1234/>
> 
>         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
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/mpls
>         <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.
> 
>         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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mpls
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 
> 
> 
> 
> -- 
> Thanx and BR,
> yaacov
> 
> /Still looking for new opportunity/

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 9 May 2013 15:40:44 +0000

Hi Alessandro, see inline.

> -----Original Message-----
> From: D'Alessandro Alessandro Gerardo
> [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2013 3:27 PM
> To: Eric Osborne (eosborne); [email-masked]
> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto;
> [email-masked]; [email-masked]; [email-masked]
> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00
> 
> Hi Eric,

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?

> 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

> 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
> 
> 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.
> 
> 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.

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 9 May 2013 19:52:25 +0000

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

-----Messaggio originale-----
Da: Eric Osborne (eosborne) [mailto:[email-masked]]
Inviato: giovedì 9 maggio 2013 17:41
A: D'Alessandro Alessandro Gerardo; [email-masked]
Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; [email-masked]; [email-masked]; [email-masked]
Oggetto: RE: PSC: draft-rhd-mpls-tp-psc-priority-00

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.

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.

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 May 2013 17:25:05 -0400

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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 10 May 2013 15:04:12 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, May 09, 2013 5:25 PM
To: Eric Osborne (eosborne)
Cc: [email-masked]; Morro Roberto; Allasia Andrea; Nervo Giacolino
Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

Eric,

Lou

---

From: Cavazzoni Carlo <[email-masked]>
Date: Tue, 14 May 2013 17:08:27 +0200

Eric,

in order to clarify, from a network operator point of view, why I think the SF-P must have higher priority than the FS-P I would make the following simple practical example.

For the execution of a programmed maintenance activity on one or more sections of a MPLS-TP ring, all the connections routed on those sections have been moved to the protection paths with a FS-P command for a defined maintenance window timeframe. The maintenance work is typically done by a team different from that managing the MPLS-TP network: let's imagine maintenance people complete the work well in advance with respect to the planned maintenance window.
Unfortunately a failure (SF-P) happens before the end of the planned maintenance window timeframe, what happens?

a)      If SF-P has higher priority than FS-P then PSC moves the traffic back to the working path so recovering the connectivity in a short protection switching time;
b)      If FS-P has higher priority than SF-P then the traffic remains on the broken connection and it will continue to be lost even when the working  path is up and running (i.e. at the latest at the end of the planned maintenance window): it seems that only a manual (and slow) reconfiguration of both protection endpoints from the management system could recover the normal working state.

Why do we have to define case b) as the standard behavior?
Are there use cases that suggest case b) as the preferred choice?

Hope this can help.

Regards,

Carlo

------------------------------------------------------------------
Telecom Italia
Carlo Cavazzoni
Transport Innovation
Via G. Reiss Romoli, 274 10148 Torino
+39 011 2285732
+39 335 7854045
Fax: +39 06 91861099
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: mercoledì 17 aprile 2013 14:16
To: [email-masked]
Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

eric

---

From: Pablo Frank <[email-masked]>
Date: Fri, 17 May 2013 09:52:07 -0400

Hi Carlo,

Why wouldn't the network operator in your example use a manual switch to
protection instead of a forced switch?  It gives exactly the desired
behaviour for your scenario, does it not?

Consider this counter-example to your scenario:  what if the maintenance
activity that is occurring on the working path is *not* complete?  Suppose
that the working path is technically up but the maintenance team is running
a long-term service activation test that can take several hours.  From the
perspective of BFD and PSC, the working path is 'up' but from the
operator's perspective, it's not ready for use (they're still testing and
stressing the new transport path).  A SF-P suddenly pushing the traffic
back to the path that is under test may be undesirable and in the worst
case, could cause problems for other transport paths especially in a
packet-switched network.  We're now pretty clearly in the murky world of
double failures and I imagine different operators have different policies
for how they want to handle this.  I can see why Eric claims that some
operators have asked for this change.

One of the things that troubles me about making the proposed change in
priority is that we end up with no practicable difference between FS-P and
MS-P.  If I refer back to G.8031, one of the differences between FS-P and
MS-P is that MS-P will be overridden by a Signal Degrade but FS-P will not.
 There seems to be a strong sense on the list that SD is not a meaningful
condition that we can define for packet switched networks.  So assuming
that holds and we make this change, we'll end up with literally no
difference in behaviour between FS-P and MS-P.

I understand the implications that the ITU-T has pointed out that a FS
could lead to a broken network but so could Lockout-of-Protection.  It
seems to me that in either case of LO or FS, you've made a conscious choice
to run unprotected for some period of time.  So buyer beware.  If that was
not your intent, then use MS.  Am I missing something here?

regards,
Pablo

On Tue, May 14, 2013 at 11:08 AM, Cavazzoni Carlo <
[email-masked]> wrote:

> Eric,
>
> in order to clarify, from a network operator point of view, why I think
> the SF-P must have higher priority than the FS-P I would make the following
> simple practical example.
>
> For the execution of a programmed maintenance activity on one or more
> sections of a MPLS-TP ring, all the connections routed on those sections
> have been moved to the protection paths with a FS-P command for a defined
> maintenance window timeframe. The maintenance work is typically done by a
> team different from that managing the MPLS-TP network: let's imagine
> maintenance people complete the work well in advance with respect to the
> planned maintenance window.
> Unfortunately a failure (SF-P) happens before the end of the planned
> maintenance window timeframe, what happens?
>
> a)      If SF-P has higher priority than FS-P then PSC moves the traffic
> back to the working path so recovering the connectivity in a short
> protection switching time;
> b)      If FS-P has higher priority than SF-P then the traffic remains on
> the broken connection and it will continue to be lost even when the working
>  path is up and running (i.e. at the latest at the end of the planned
> maintenance window): it seems that only a manual (and slow) reconfiguration
> of both protection endpoints from the management system could recover the
> normal working state.
>
> 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

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Sat, 18 May 2013 07:24:56 +0000

Pablo,

FS command is usually issued before a network operator performs any network maintenance jobs for the working path, such as replacing a cable, any components of a switch, or the switch itself on the working path. After the maintenance job, the traffic can go back to the working path and protection domain can return to normal by the network operator's clear command.

If MS is issued and a cable is pulled off, then SF-W will occur.
Now, this SF-W will be the top priority request on the protection domain and will dominate any following protection actions, such as running WTR timer, traffic reversion after WTR timer exprires, or entering DNR, etc.

MS and FS are different regardless of SD.

Best regards,

Jeong-dong

________________________________
From : "Pablo Frank" <[email-masked]>
Sent : 2013-05-17 22:52:32 ( +09:00 )
To : Cavazzoni Carlo <[email-masked]>
Cc : [email-masked] <[email-masked]>
Subject : Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

Hi Carlo,

Why wouldn't the network operator in your example use a manual switch to protection instead of a forced switch?  It gives exactly the desired behaviour for your scenario, does it not?

Consider this counter-example to your scenario:  what if the maintenance activity that is occurring on the working path is *not* complete?  Suppose that the working path is technically up but the maintenance team is running a long-term service activation test that can take several hours.  From the perspective of BFD and PSC, the working path is 'up' but from the operator's perspective, it's not ready for use (they're still testing and stressing the new transport path).  A SF-P suddenly pushing the traffic back to the path that is under test may be undesirable and in the worst case, could cause problems for other transport paths especially in a packet-switched network.  We're now pretty clearly in the murky world of double failures and I imagine different operators have different policies for how they want to handle this.  I can see why Eric claims that some operators have asked for this change.

One of the things that troubles me about making the proposed change in priority is that we end up with no practicable difference between FS-P and MS-P.  If I refer back to G.8031, one of the differences between FS-P and MS-P is that MS-P will be overridden by a Signal Degrade but FS-P will not.  There seems to be a strong sense on the list that SD is not a meaningful condition that we can define for packet switched networks.  So assuming that holds and we make this change, we'll end up with literally no difference in behaviour between FS-P and MS-P.

I understand the implications that the ITU-T has pointed out that a FS could lead to a broken network but so could Lockout-of-Protection.  It seems to me that in either case of LO or FS, you've made a conscious choice to run unprotected for some period of time.  So buyer beware.  If that was not your intent, then use MS.  Am I missing something here?

regards,
Pablo

On Tue, May 14, 2013 at 11:08 AM, Cavazzoni Carlo <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

Hope this can help.

Regards,

Carlo

------------------------------------------------------------------
Telecom Italia
Carlo Cavazzoni
Transport Innovation
Via G. Reiss Romoli, 274 10148 Torino
+39 011 2285732<tel:%2B39%20011%202285732>
+39 335 7854045<tel:%2B39%20335%207854045>
Fax: +39 06 91861099<tel:%2B39%2006%2091861099>
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Osborne (eosborne)
Sent: mercoledì 17 aprile 2013 14:16
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

eric
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 30 May 2013 14:29:04 +0900

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