Subject: [mpls] Proposed response to Liaison on Linear Protection Switching

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Jul 2012 13:25:00 +0200

Working Group,

A few weeks ago the working group chairs asked for volunteers to do
a first spin on a response to the liaison "Revision of Recommendation
ITU-T G.8131 – Linear protection switching for MPLS-TP networks"
(https://datatracker.ietf.org/liaison/1162/).

Thanks to Yacoov W and Eric O who stepped and did most of the work,
thanks also to people who sent comments and advices.

Included is a proposed response to the liaison.

Please send comments on the proposal to the MPLS working group mailing
list ([email-masked]) July 26th the latest.

/Loa
(MPLS WG co-chair)

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Yaacov Weingarten <[email-masked]>
Date: Tue, 17 Jul 2012 15:22:21 +0300

Loa, hi

Just one editorial comment -
In the second paragraph remove the redundant phrase "that were raised in
your LS" toward the end of the paragraph.

Thank you and BR,
yaacov

On Tue, Jul 17, 2012 at 2:25 PM, Loa Andersson <[email-masked]> wrote:

> (https://datatracker.ietf.org/**liaison/1162/<https://datatracker.ietf.org/liaison/1162/>
> ).
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 17 Jul 2012 18:28:45 +0000

One thing you may wish to add to #3 is that per G.870 clause 3.2.28, "The exercise functionality is optional".  

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Loa Andersson
> Sent: Tuesday, July 17, 2012 7:25 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] Proposed response to Liaison on Linear Protection Switching
> 
> Working Group,
> 
> ITU-T G.8131 - Linear protection switching for MPLS-TP networks"

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 24 Jul 2012 21:55:48 +0000

Is it too late to add something?  

G.808.1 (02/2010), clause 16:

"In principle, it is possible to allocate an APS 
channel on every transport entity. Allocation of this channel on a working transport entity, however, 
would not provide sufficient survivability; i.e., when the working transport entity would fail, 
communication between the two endpoints will fail as well, and protection is not possible. 
Therefore the APS channel is allocated to one or more protection transport entities."

This doesn't say "APS is on both W and P", which is how I think APS is actually done (??).  It says "APS is allocated to one or more protection transport entities", which is exactly how PSC does it.

eric

> From: Eric Osborne (eosborne)
> Sent: Tuesday, July 17, 2012 2:29 PM
> To: 'Loa Andersson'; [email-masked]
> Subject: RE: [mpls] Proposed response to Liaison on Linear Protection
> Switching
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 25 Jul 2012 00:08:37 +0200

Eric,

the response is still open for comments, will close the consensus
call on the morning of July 27th.

/Loa

--

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 24 Jul 2012 22:33:29 +0000

I'd made two comments on this thread.  The first pointed out that per g.870, EXER was optional.  The second, which I sent out just now, pointed out that per G.808.1, APS ran on the protection channel.

Nevermind the second one.  I thought it lined up with one of the points in the most recent liaison, but it does so in a fairly nuanced way so I don't think it's worth putting in the liaison.  

For the record, the subtlety is this: the liaison's first point is that in APS, SF-P > FS.  In PSC, FS > (SF-W, SF-P).  Therefore, the two protocols will behave differently.  Our original response to this was that yes, they will behave differently, but the protocols themselves are different.  When I first wrote text to reply to this point I was under the impression that APS was sent on both W&P.  I may have been mistaken, as g.808.1 clearly calls for it to run only on P.  I propose no changes to the most recent liaison response text.

For the point about EXER...the most recent text from Adrian around this point is:

---
3.	Regarding the EXER function - This comment was raised during the IETF Last Call and was discussed with the individual that raised the comment.  As a result of this discussion an appendix (Appendix B - Page 44) was added that suggests various ways of implementing the functionality that is required.
---

I am fine with this text as it stands.  You may wish to incorporate the point about G.870, and so I suggest the following text, adding two sentences at the end:

---
3.	Regarding the EXER function - This comment was raised during the IETF Last Call and was discussed with the individual that raised the comment.  As a result of this discussion an appendix (Appendix B - Page 44) was added that suggests various ways of implementing the functionality that is required.  In addition, G.870 clause 3.2.26 defines the exercise signal as optional.  If a mandatory EXER function is required in MPLS-TP's PSC, please explain why it is not required in OTN's APS.
---

Whether this text is useful or not is up for discussion.  I am fine with it either in or out.

Note that I could not find text in g.841 (MSP), g.8031 (Ethernet linear protection) or g.8131 (draft MPLS-TP linear protection) that declares EXER to be optional.  So it may not be worth pointing out the inconsistency between ITU standards.

eric

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2012 6:09 PM
> To: Eric Osborne (eosborne)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection
> Switching
> 
> Eric,
> 
> > This doesn't say "APS is on both W and P", which is how I think APS is
> actually done (??).  It says "APS is allocated to one or more protection
> transport entities", which is exactly how PSC does it.
> >
> >
> >
> >
> > eric
> >
> >
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >>> Loa Andersson

---

From: Yoshinori Koike <[email-masked]>
Date: Fri, 27 Jul 2012 21:28:16 +0900

Hello Yacoov and Mr. Osborne,

Thank you very much for preparing the draft liaison to ITU-T.

I'm sorry for these late questions, but I have a few questions for 
clarification on the draft liaison.

Q1) According to the item 1, it is written that the priority order "FS 
over SF-P" was defined also for consistency with the IETF Recovery 
terminology in RFC 4427. Could you be more specific about which part of 
the document can be referred, please?

I have checked RFC4427 and I thought it might refer to the following 
part, but if "command" means internal command(not external command), it 
may imply that SF-P(internal command) could be prioritized.

--------------
D. Forced switch-over for normal traffic:

A switch-over action, initiated externally, that switches normal
traffic to the recovery LSP/span, unless an equal or higher priority
switch-over command is in effect.
---------------

Q2) Regarding item 1, there is a description that 'we note that in PSC 
the FS can be reverted provided one of the paths is active'. Could you 
explain more details about the meaning of this sentence, please? Does 
this mean that, for example, SF-P(with a working path is active) 
overrides FS depending on an implementation, which isn't compliant with 
the priority order of PSC?

Q3) Regarding the description in item 2, 'This feature may be used for 
future optimizations by different implementations.', could you be more 
specific about this sentence, please? I would like to know what kind of 
optimization will be achieved and how differently PSC will be implemented.

Q4) Regarding the description 'because it was felt that this be best 
specified in a management document' in item 6, does the "a management 
document" include both characteristics of equipment functional blocks 
and equipment management aspect?

Just a very minor comment is, regarding Annex B of RFC6378, it is 
written on page 43 actually, although the table of contents point to 
page 44.

Thank you in advance.

Best regards,

Yoshinori

-- 
Yoshinori Koike
[email-masked]

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 31 Jul 2012 11:17:15 +0000

Hi Yoshinori-

 Thank you for your questions, I believe you've identified some confusing language in our original proposed response.  I have included both your questions and our answers below.  Please let us know whether these answer your questions or whether you require further clarification, and we will update the LS response as necessary.

eric  

> Sent: Friday, July 27, 2012 8:28 AM
> To: [email-masked]

A1) Please refer to RFC4427, section 4.13 parts D/E.  In particular:

- part D defines "Forced switch-over for normal traffic", which is executed " unless an equal or higher priority switch-over command is in effect"
- part E defines " Manual switch-over for normal traffic", which is executed " unless a fault condition exists  ... or an equal or higher priority switch-over command is in effect."

Thus, RFC4427 differentiates between switch-over commands, i.e. lockout of  protection, forced switch, manual switch, etc, and fault conditions, i.e. SF-W, SF-P, etc.  Since an FS is executed unless there is a precluding switch-over command, and since MS is executed unless there is a precluding switch-over command or a fault condition, the FS must be executed even in the face of a fault condition.  This requires that FS take precedence over SF-P.

> the priority order of PSC?

A2) We agree that the wording is perhaps unclear.  It may make sense to simply remove that sentence, or we could rephrase it.  

The logic behind FS and SF-P priorities doesn't change.  When an FS is removed, a node processes its remaining inputs and acts accordingly.  

First consider the case where FS is active but no other inputs are present.  When FS is active, traffic is switched from W to P.  When FS is removed, traffic reverts to W.  

Now consider the case where both FS and SF-P are active.  There are two ways this can happen: the operator configures FS and then sees SF-P from the network, or the operator sees SF-P from the network and then configures FS.  The outcome is the same in either case but the latter case seems far less likely, so let's examine the first case.  When the operator configures FS, traffic is bridged into P.  When P fails, the traffic is simply dropped, as it cannot be transmitted.  This obeys the logic of prioritizing FS over SF-P.  Should the operator wish to avoid this case, they should configure MS rather than FS.

Given that explanation, do you have any suggestions about how to handle the text?  Should we remove the sentence, or rewrite it?

> optimization will be achieved and how differently PSC will be implemented.

A3) We believe that changing the text to state - "this behavior may be used by the operators to optimize their network operations, based on more complete status information..." would more clearly state the intention. 

We had no intention of implying that there would be different implementations of PSC, but rather that the more complete network status information provided by PSC, would allow the systems to react in a more efficient manner to protection switching situations.'

> and equipment management aspect?

A4) The IETF tends to standardize management behaviors which are required for interoperability between devices.  This differs from the ITU, which publishes "equipment recommendations" that provide equipment functional blocks and management commands and messages that are generated.  If the ITU feels that these definitions are necessary for their equipment definitions then it is their prerogative to document them there.  I believe that this is in keeping with the spirit of the work-split between the IETF and the ITU on MPLS-TP.

> written on page 43 actually, although the table of contents point to

Thank you for this.  We will remove explicit page number references and simply refer to sections, including this reference to Appendix (not Annex) B.