Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-linear-protection-04

From: Loa Andersson <[email-masked]>
Date: Thu, 03 Feb 2011 12:41:44 +0100

Working Group,

this is to start a four week working group last call on
"MPLS-TP Linear Protection" (draft-ietf-mpls-tp-linear-protection-04).

Please send comments to the [email-masked] mailing list.

This working group last call ends on February 28, 2011.

Loa, George and Ross

MPLS wg co-chairs

-- 

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: Jie Dong <[email-masked]>
Date: Fri, 11 Feb 2011 16:44:06 +0800

Dear authors,

Here are some comments on linear protection draft.

1. In section 1.2, it says:
" The basic protocol is designed for use in conjunction with the 1:1
protection architecture (for both unidirectional and bidirectional
protection) and for 1+1 protection of a bidirectional path (for both
unidirectional and bidirectional protection switching). "

Would you please explain why coordination is needed for unidirectional
protection switching in 1+1 protection of a bidirectional path? Because
section 4.7.2 of tp-survive-fwk says:
"In 1+1 unidirectional protection switching there is no need to coordinate
the protection state between the protection controllers at both ends of the
protection domain."

I guess you mean 1+1 protection may need coordination to keep traffic on
co-routed paths, but that would be bidirectional protection switching.
Hope this could be made clearer in this draft.

2. Section 2.1, Acronyms
The full name of "LER" should be "Label Edge Router"
"PST" is an old term replaced by SPME (Sub-Path Maintenance Entity), but
neither is used in the following sections, so it may be removed from
acronyms.

3. In Section 3, there is only one level-2 subsection (3.1), so what about
promote the level-3 subtitles (3.1.1, 3.1.2, ...) to level-2, and level-4
(3.1.6.1) to level-3?

4. Section 4, 3rd paragraph, s/single-phase/single-phased, to be consistent
with 2nd paragraph.

5. Section 4.1, 4th paragraph,
" In the event a signal fail condition is detected on the protection path,
the received PSC specific information should be evaluated."
The statement is vague. What would be the state and action when a signal
fail is detected on the protection path? Would you please elaborate on this
point?

6. Section 4.2.2, 4th paragraph,
" The Fpath field SHALL identify the path that is reporting the failure
condition (i.e. if protection path then Fpath is set to 0...".
Since PSC message are only transmitted on protection path, if protection
path has signal fail, the PSC message may not be able to be sent out to
far-end.

7. Section 4.3.2, there is signal degrade on working path as input, but no
signal degrade on protection path.

8. Section 4.3.3, I go through this part fast, a general question is: are
the PSC operations for 4 different protection types identical ? In this
section there is no description about operation of each specific protection
type, but to my understanding, there may be different operations, e.g., for
bidirectional 1:1 protection, the end point may need to switch the sink
selector and transmitting bridge simultaneously according to some input, but
for unidirectional 1:1 the end point may only need to switch the
transmitting bridge OR the sink selector. And the PSC message sent may also
be different for different protection types. (Please correct me if there is
anything wrong with this thought).

Best Regards,
Jie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Loa Andersson
> Sent: Thursday, February 03, 2011 7:42 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] mpls wg last call on
draft-ietf-mpls-tp-linear-protection-04
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 16 Feb 2011 15:08:46 +0100

Jie, hi

Thank you for your very detailed comments, see replies in-line

BR,
yaacov

>> Behalf Of ext Jie Dong
>> Sent: Friday, February 11, 2011 10:44 AM
>> Subject: Re: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-
>> protection-04
>> 
>> Dear authors,
>> 

yw> Yes, you are correct that there is no need for coordination for
unidirectional protection however this protocol could be used by the
endpoints to coordinate information regarding the state of the network. 
>> Hope this could be made clearer in this draft.

yw> we will try to clarify this better in the next version.
>> neither is used in the following sections, so it may be removed from

Yw>  You are correct and this will be corrected as suggested.
>> promote the level-3 subtitles (3.1.1, 3.1.2, ...) to level-2, and

yw> Thank you for pointing this out!
>> 4. Section 4, 3rd paragraph, s/single-phase/single-phased, to be

yw> Thank you
>> fail is detected on the protection path? Would you please elaborate
on
>> this

yw> will try to clarify in the next version.
>> path has signal fail, the PSC message may not be able to be sent out

yw>  Actually, if there is a signal failure on the protection path,
there is a possibility that the messages may not be received by the
far-end, however, it is advisable that the source end-point continue to
transmit these messages.
>> signal degrade on protection path.

yw> Currently, the signal degrade input in this list is a place holder -
the issue of how to deal with SD in general is for further study as
stated in section 4.2.2.  Note - there have been lengthy discussions at
several IETF meetings on how to deal with SD without any conclusions.

>> transmitting bridge OR the sink selector. And the PSC message sent
may
>> also

yw> Can you clarify for which scenario you believe that the messages
generated should be different dependent upon the protection type (aside
from the value of the protection type field)?  The exact actions of the
selector and transmitting bridges are not fully described in the
document aside from the note at the end of section 4.3.1.  In addition,
in the introductory text of each state description in section 4.3.3.3.x
describe how the user data is being transmitted.  Is there a feeling
that we need to describe this separately for each scenario?

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 16 Feb 2011 11:58:09 -0600

Hi Jie-

  Yaacov has replied to most of your comments, but let me add two

> path has signal fail, the PSC message may not be able to be sent out
to

As Yaacov has mentioned, we would like the PSC to send messages anyways
in the chance that they may get through.  This is explicitly noted in
section 4.3.3.2:

---
"When the domain is in unavailable state the PSC messages may not get
through and therefore the protection is more dependent on the local
inputs rather than the remote messages (that may not be received)."
----

Is that sufficient, or do you think we need additional text to reinforce
this point?

> section there is no description about operation of each specific
> protection type, but to my understanding, there may be different
> operations, e.g., for bidirectional 1:1 protection, the end point may
need
> to switch the sink selector and transmitting bridge simultaneously
> according to some input, but for unidirectional 1:1 the end point may
only
> need to switch the transmitting bridge OR the sink selector. And the
PSC
> message sent may also be different for different protection types.
(Please
> correct me if there is anything wrong with this thought).

PSC is not, in my view, tightly coupled to the four protection types.
That is to say, PSC is a tool that allows the device vendor and network
operator to build protection in an MPLS-TP network.  This protection can
be one of the four protection types you describe, but PSC is merely a
protocol to accomplish the end goal.  It may, for example, be possible
in the future to use PSC to build one or more types of 1:n protection;
when and if this is done, the message types would likely remain the same
as they are now.

eric

> > this is to start a four week working group last call on "MPLS-TP
> > Linear Protection" (draft-ietf-mpls-tp-linear-protection-04).
> >

---

From: [email-masked]
Date: Thu, 17 Feb 2011 10:55:26 +0800

Dear authors，

Below are two comments:

1. in section 3.1.6.  PSC Control States
the definition of unavailable state is :
"Unavailable state - The protection path is unavailable - either as a 
result of an operator Lockout command or a failure/degrade condition 
detected on the protection path."
but in the first paragraph of section 4.3.3.2.,  the cause of unavailable 
state does not include  this degrade condition detected on the protection 
path.

these two descriptions are not consistent.

2. typo 
the first paragragh  in section 4.3.3.4., "remote SF PCS message" shall be 
changed to "remote SF PSC  message" 

Best Regards,
xuehui

Loa Andersson <[email-masked]> 
发件人:  [email-masked]
2011-02-03 19:41

收件人
[email-masked], [email-masked]
抄送
[email-masked]
主题
[mpls-tp] mpls wg last call on  draft-ietf-mpls-tp-linear-protection-04

Working Group,

Loa, George and Ross

MPLS wg co-chairs

--

---

From: Jie Dong <[email-masked]>
Date: Fri, 18 Feb 2011 08:56:45 +0000

Hi Yaacov,

> far-end, however, it is advisable that the source end-point continue to

[Jie] Actually this comment is also about the first sentence in 4.1:
"The PSC control packets SHALL be transmitted over the protection path only"
IMO, If the transmitting end knows (either through remote PSC message or local information) the transmitting direction of the protection path is in fault, it may use working path to send PSC message. This way the PSC message would always be sent on only one path, and the remote end could still receive this message in protection path failure scenarios.

> several IETF meetings on how to deal with SD without any conclusions.

[Jie] OK. So will the SD part be added to this draft later, or it will be specified in a separate document?

> >> protection

[Jie] As draft-sur-fwk specified, 
"For bidirectional P2P paths, both unidirectional and bidirectional protection switching are supported."

So an example is one end of the bidirectional path receives local signal fail on working path. This would normally be a failure in receiving direction on working path.
For 1:1 unidirectional protection, the protection actions in each direction are independent, then maybe one direction has switched to the protection path, while in the opposite direction the traffic is still on the working path. In this case the output PSC message should indicate the remote end to switch the transmitting bridge to protection path and keep the remote selector bridge unchanged. For this the "Path" Field may need to be extended to TxPath and RxPath, and the PSC message with the format REQ(Fpath, TxPath, RxPath) would be SF(1,0,1). 
If later a remote signal fail on working path is received, then the output message would be changed to SF(1,1,1).

For 1+1 bidirectional protection, the output PSC message should indicate the remote end to switch both the transmitting bridge and the selector bridge to protection path. Thus the output message would be SF(1,1,1).

Thus IMO for unidirectional and bidirectional protection the action would be different, and the messages may need be different to convey clear information.

Best regards,
Jie

---

From: Jie Dong <[email-masked]>
Date: Fri, 18 Feb 2011 09:14:33 +0000

Hi Eric, 

Thanks for your reply, and please see in-line with [Jie]:

> From: Eric Osborne (eosborne) [mailto:[email-masked]]
> Sent: Thursday, February 17, 2011 1:58 AM
> To: Jie Dong; [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] mpls wg last callon

> Is that sufficient, or do you think we need additional text to reinforce

[Jie] I acknowledge this purpose, and my further comment would be the same as to Yaacov: what about sending this message through working path if it is known the transmitting direction of the protection path is in failure? In this way the message is still sent on only one path.

> when and if this is done, the message types would likely remain the same

I agree that PSC protocol can be used for all these protection types, and may also be applicable to 1:n protection, but for each protection type the state machine may be slightly different. The draft-tp-cc-cv-rdi also works in this way. The message types are likely the same, but some fields in the message may be different.

Best regards,
Jie

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 23 Feb 2011 07:31:15 -0600

Hi Jie-

  Two comments inline with EO#

> > As Yaacov has mentioned, we would like the PSC to send messages
> > anyways in the chance that they may get through.  This is explicitly
> > noted in section 4.3.3.2:
> 
> > ---
> > Is that sufficient, or do you think we need additional text to
> > reinforce this point?
> 
> [Jie] I acknowledge this purpose, and my further comment would be the
same
> as to Yaacov: what about sending this message through working path if
it
> is known the transmitting direction of the protection path is in
failure?
> In this way the message is still sent on only one path.

EO#

  We discussed this early on when writing the draft, but decided against
it.  The concern was that providing multiple channels to send a message
on could open us up to complications and race conditions.  What happens,
for example, if you get different messages on the W and P SPMEs, for
example?  I see your point about only sending the message on one path,
but there are some types of failure where one end could think an SPME is
down and the other might not.  What happens if the rx node thinks the P
SPME is down (and thus expects messages on the W SPME), but the tx node
thinks the P SPME is up, and thus does not send anything on the W SPME?

  Bottom line is that there are always going to be ugly cases we can't
easily resolve, especially with the constraint that this protocol must
be fairly simple; the more dynamic it is, the longer it will take to
react to a failure, and in a protection protocol that's not something we
can afford.

> > > 8. Section 4.3.3, I go through this part fast, a general question
is:
> > are
> > That is to say, PSC is a tool that allows the device vendor and
> > network operator to build protection in an MPLS-TP network.  This
> > protection can be one of the four protection types you describe, but
> > PSC is merely a protocol to accomplish the end goal.  It may, for
> > example, be possible in the future to use PSC to build one or more
> > types of 1:n protection; when and if this is done, the message types
> > would likely remain the same as they are now.
> >
> 
> I agree that PSC protocol can be used for all these protection types,
and
> may also be applicable to 1:n protection, but for each protection type
the
> state machine may be slightly different. The draft-tp-cc-cv-rdi also
works
> in this way. The message types are likely the same, but some fields in
the
> message may be different.

EO#  Can you be more specific?  Which field(s) would be different?  What
functionality would these fields provide that can't be provided with PSC
as defined in our draft?  As part of the PSC work we looked at other
protection protocols (you may notice a striking similarity to APS), and
I didn't see any type-specific redefinition of fields in those.

eric

> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of Loa Andersson