Re: [mpls] soliciting comments on response to liaison from SG15

[Loa Andersson <[e-mail]>]

Working Group,

we sent this mail soliciting comments on the on the outgoing liaison
text. There have been no comments on the list, but some directly
to the working group chairs. We have updated the text and intend to
send this version the day before the dead line.

------------- proposed liaison text -----------------------

Thank you for your liaison statement COM15-LS435-E "Recommendation
ITU-T G.8131/Y.1382 revision - Linear protection switching for
MPLS-TP networks" with the questions and concerns that it raises
about RFC 6378 MPLS-TP linear protection.

We have passed your concerns to the working group. We hope that
anyone who agrees with them and is concerned to modify the
MPLS-TP linear protection specification will write an Internet-Draft
using the normal IETF process. We know that a number of people have
been actively discussing the issues you raised with a view to making
modifications to the specification presented in RFC 6378.

Here are some additional notes for the specific points in your liaison.

#1 RFC5654 includes R.83, which states "The external controls as
defined in [RFC4427] MUST be supported."  RFC4427 clearly requires
FS > SF-P; please see the LS from the IETF to the ITU dated 2012-08-06.
An alternate approach allowing SF-P > FS could be defined such that
it can co-exist with FS > SF-P.

#2 The scenario described in Annex 2 of your liaison describes a defect
in RFC 6378. It makes no sense to continue to send SF(1,1) when W has
not failed.

#3 No requirement for EXER was documented in RFC5654. There is also
no mention of EXER in RFCs 4427 an 6372. EXER could be added to the
MPLS-TP function-set.

#4 There is currently no definition of SD for an MPLS environment.
SD is included in RFC6378 as a placeholder (see RFC6378
Section 3.1: "The determination and actions for SD are for
further study and may appear in a separate document"). We encourage
interested parties to submit an Internet-Draft for consideration by
the IPPM and MPLS working groups.
There is no requirement MS-W in RFC5654 or RFC4427.  We encourage
interested parties to submit an Internet-Draft for consideration
by the MPLS working group.

#5 You ask whether your understanding that Clear Signal Fail (SFc)
is used to trigger the WTR in section 4.3.3.5 of RFC 6378. CSF should
not be thought of as a trigger, but as the removal of a trigger.  If
a node has multiple alarms active, the removal (Clear) of the highest
priority alarm causes a node to re-evaluate its current inputs and
act accordingly.  If a SF is Cleared and there are no other active
inputs, the resulting transition into Normal will trigger WTR, per
rfc6378 sec. 3.5.

#6 RFC6378 is a protocol specification and does not describe how to
implement error reporting to the operator. An error reporting paradigm 
could be defined.

#7 Mechanisms for alerting operators about mismatches are outside
of the scope of the protocol specification: they may be considered
as issues for implementers. A default operational state for MPLS-TP 
linear protection in absence of any specific configuration could
be defined.

#8 The scenario described in Annex 3 of your liaison should be
addressed in an Internet-Draft describing the problem and proposing
a solution.

#9 RFC5654 R.83 requires that the external commands in RFC4427
be implemented. RFC4427 defines 'Freeze' as "A configuration
action.that prevents any switch-over action from being taken".
This is a local behavior on a node (there is no signaled message as
a result) and thus it is not part of the MPLS-TP linear protection
protocol specification.
RFC4427 defines "Manual switch-over for recovery LSP/span" as
"A switch-over action, initiated externally, that switches normal
traffic to the working LSP/span, unless a fault condition exists
on the working LSP/span or an equal or higher priority switch-over
command is in effect".  This function is provided by the FS and MS
messages in RFC6378.  If there is a desire for a switchover
behavior which differs from FS or MS then it should be documented
in an Internet-Draft for consideration by the MPLS working group.

Loa Andersson
Ross Callon
George Swallow
mpls working group chairs

------------------- end liaison text ---------------------






On 2012-12-12 14:55, Loa Andersson wrote:
> Working Group,
>
> I sent this one time, but it came out "weird" - resending with another
> subject line!
>
> We've had a small team that prepared a response to and incoming liaison
> from ITU-T SG15 on linear protection; both the liaison and the proposed
> response is included in this mail. In my opinion this team has done a
> tremendous job in creating the proposed response.
>
> This mail is to start soliciting comments on the response.
>
> We need to send the response before the end of the year, but will have
> meeting the 18th to check that everything is OK. Comments will be
> useful whenever we get, all the way up to when the response is sent; but
> they will particular if we get them before 10am (Boston time) on
> December 18.
>
> Thanks to the team (Eric O, Scott M and Yaacov W) for all the work they
> have put into this, thanks also to the support from our ADs, Adrian and
> Stewart.
>
> /Loa
> for the wg chairs

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]