Subject: [mpls-tp] Require few clarifications in the draft "draft-ietf-mpls-tp-linear-protection-02

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 19 Aug 2010 19:15:01 +0530

Hi,
We require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02.txt". Kindly help us to understand
the below points:

1. As per *Sec 4.3.2 Priority of inputs*, the "Signal Fail on
protection (OAM/Control Plane/Server Indication)" has higher priority
than "Forced switch (Operator command)".
    But according to *Sec 4.3.3.2.  Unavailable State : *
      “ A *local Forced switch input when in Unavailable state* due to
a  local or remote *failure condition on the protection *path SHALL
      cause the *LER to go into Protecting administrative state* and
begin transmission of a FS(1,1) message.“

  This gives the interpretation that Forced Switch needs to accepted
even when there is signal fault on protection path.

 a) Please clarify which is the correct, intended behavior.
   We feel that the correct behavior is to reject the local Force
switch command when protection group is in unavailable state due to
local or remote failure condition on the protection path.
 Please provide your comment on this

2. "*Sec 4.3.3.5.  Wait-to-restore state", *there is no explicit
handling explained for the *'clear command' on WTR state.
*   a) Is clear command applicable for for WTR state?
   b) If 'yes', should the protection group move from protection path
to working path immediately after issuing 'clear' in the WTR state ?

3.* In section "4.3.3.6.  Do-not-revert state":*
   "The command to revert back to Normal state could  either be a
Lockout of protection (followed be a Clear command), a
   Clear command, *or a new form of the Manual switch command [note:
This would also require some kind of agreement, although it seems to
have
   been adopted by ITU-T in G.8031 for Ethernet]."*

   This text gives the understanding that it is the "manual switch to
working" which is referred here .

   a) Does this draft support "manual switch to working" operation ?
   b) if so the *priority* of *"manual switch to working"* operation
is not defined in "sec 4.3.2 Priority of inputs"
      So what should be the priority of this operation in comparison
with others?
   c) Can you also clarify on the *"[note:]" *as it is not clear  as
to what agreement is meant here ...

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 23 Aug 2010 12:08:49 +0530

Hello Yaacov,
Can you please respond to this query?

Thanks,
Venkat.
On Thu, Aug 19, 2010 at 7:15 PM, venkatesan mahalingam <[email-masked]
> wrote:

> 1. As per *Sec 4.3.2 Priority of inputs*, the "Signal Fail on protection (OAM/Control Plane/Server Indication)" has higher priority than "Forced switch (Operator command)".
>
>       “ A *local Forced switch input when in Unavailable state* due to a  local or remote *failure condition on the protection *path SHALL
>
>       cause the *LER to go into Protecting administrative state* and begin transmission of a FS(1,1) message.“
>
>   This gives the interpretation that Forced Switch needs to accepted even when there is signal fault on protection path.
>
>    We feel that the correct behavior is to reject the local Force switch command when protection group is in unavailable state due to local or remote failure condition on the protection path.
>
> 2. "*Sec 4.3.3.5.  Wait-to-restore state", *there is no explicit handling explained for the *'clear command' on WTR state.
>    b) If 'yes', should the protection group move from protection path to working path immediately after issuing 'clear' in the WTR state ?
>
>
>
>    "The command to revert back to Normal state could  either be a Lockout of protection (followed be a Clear command), a
>
>    Clear command, *or a new form of the Manual switch command [note: This would also require some kind of agreement, although it seems to have
>    This text gives the understanding that it is the "manual switch to working" which is referred here .
>
>
>    b) if so the *priority* of *"manual switch to working"* operation is not defined in "sec 4.3.2 Priority of inputs"
>
>       So what should be the priority of this operation in comparison with others?
>    c) Can you also clarify on the *"[note:]" *as it is not clear  as to what agreement is meant here ...
>
> --
> Best Regards,
> Venkatesan Mahalingam.
>
>

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 24 Aug 2010 09:03:14 +0200

Hi,

Sorry for the delay in responding - see my answers inline.

Best regards,

yaacov

________________________________

From: ext venkatesan mahalingam [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 16:45
To: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02

Hi,

We require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02.txt". Kindly help us to
understand the below points:

1. As per Sec 4.3.2 Priority of inputs, the "Signal Fail on protection
(OAM/Control Plane/Server Indication)" has higher priority than "Forced
switch (Operator command)".

    But according to Sec 4.3.3.2.  Unavailable State : 

      " A local Forced switch input when in Unavailable state due to a
local or remote failure condition on the protection path SHALL

      cause the LER to go into Protecting administrative state and begin
transmission of a FS(1,1) message."
  This gives the interpretation that Forced Switch needs to accepted
even when there is signal fault on protection path. 
 a) Please clarify which is the correct, intended behavior. 

   We feel that the correct behavior is to reject the local Force switch
command when protection group is in unavailable state due to local or
remote failure condition on the protection path.
[yw>] We agree with you that the correct behavior should be that the
Forced Switch is ignored (considering that the protection path is
unavailable there may be difficulty for the two end-points to
communicate the FS condition).  This will be corrected in the next
version. 

 

2. "Sec 4.3.3.5.  Wait-to-restore state", there is no explicit handling
explained for the 'clear command' on WTR state. 

   a) Is clear command applicable for for WTR state? 
[yw>] After some consideration, I feel that the clear command is not
relevant to the WTR state - Keep in mind that the Clear command is a
local command that is initiated by the operator, and is not transmitted
between the two end-points.  The WTR timer is set by the operator,
presumably to allow the network to stabilize before reverting to the
normal state, and therefore it does not seem reasonable that the
operator would intervene to shorten this time while recovery is in
process.

   b) If 'yes', should the protection group move from protection path to
working path immediately after issuing 'clear' in the WTR state ?

3. In section "4.3.3.6.  Do-not-revert state":

   Clear command, or a new form of the Manual switch command [note: This
would also require some kind of agreement, although it seems to have

   been adopted by ITU-T in G.8031 for Ethernet]."
   This text gives the understanding that it is the "manual switch to
working" which is referred here .

   a) Does this draft support "manual switch to working" operation ?
[yw>] The sentence directly after the note states quite clearly that the
draft is written under the assumption of the Lockout/Clear option.  So I
can easily state that the draft does not support the manual switch to
working operation and therefore there is no priority defined for this
operation.

   b) if so the priority of "manual switch to working" operation is not
defined in "sec 4.3.2 Priority of inputs"

   c) Can you also clarify on the "[note:]" as it is not clear  as to
what agreement is meant here ...
[yw>] The agreement that would be needed is of the authors and the WG
that the "manual switch to working " is necessary and that the other
option is too complicated.

-- 

Best Regards,

Venkatesan Mahalingam.

---

From: [email-masked]
Date: Wed, 25 Aug 2010 10:09:17 +0800

hi
 according to your describles, I have a few question about it.
   1 I think that it is necessary for clear command to notify peer node. 
for example, it is Switch state now. when a end node 
     receive a clear command, the end node must switch from protecting 
path back to working path. if no message notify peer node.
     how do peer node know to select which path to send and receive 
traffic? so notify message is necessary to be transmitted between
     the two end-points.

   2 "manual switch to working" is unnecessary and nosense command in my 
mind. because the use of the command is to make service come back to 
working path.
   it shows that current state is auto switch state or Force state. since 
auto switch or FS is more priority that manual switch. so even if we 
   have already defined the command. using the command can't switch 
current protecting path to working path.

    it is my opinions. maybe there miss something important?

    best regards
     liu

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2010-08-24 15:03

收件人
"ext venkatesan mahalingam" <[email-masked]>, <[email-masked]>
抄送

主题
Re: [mpls-tp] Require few clarifications in the draft 
"draft-ietf-mpls-tp-linear-protection-02

Hi,
 
Sorry for the delay in responding – see my answers inline.
 
Best regards,
yaacov

Hi,

      “ A local Forced switch input when in Unavailable state due to a 
local or remote failure condition on the protection path SHALL

      cause the LER to go into Protecting administrative state and begin 
transmission of a FS(1,1) message.“
  This gives the interpretation that Forced Switch needs to accepted even 
when there is signal fault on protection path. 
 a) Please clarify which is the correct, intended behavior. 

   We feel that the correct behavior is to reject the local Force switch 
command when protection group is in unavailable state due to local or 
remote failure condition on the protection path.
[yw>] We agree with you that the correct behavior should be that the 
Forced Switch is ignored (considering that the protection path is 
unavailable there may be difficulty for the two end-points to communicate 
the FS condition).  This will be corrected in the next version. 

 

   a) Is clear command applicable for for WTR state? 
[yw>] After some consideration, I feel that the clear command is not 
relevant to the WTR state – Keep in mind that the Clear command is a 
local command that is initiated by the operator, and is not transmitted 
between the two end-points.  The WTR timer is set by the operator, 
presumably to allow the network to stabilize before reverting to the 
normal state, and therefore it does not seem reasonable that the operator 
would intervene to shorten this time while recovery is in process.

 

   "The command to revert back to Normal state could  either be a Lockout 
of protection (followed be a Clear command), a

 

      So what should be the priority of this operation in comparison with 
others?

   c) Can you also clarify on the "[note:]" as it is not clear  as to what 
agreement is meant here ...
[yw>] The agreement that would be needed is of the authors and the WG that 
the "manual switch to working " is necessary and that the other option is 
too complicated.

-- 

Best Regards,

Venkatesan Mahalingam._______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 30 Aug 2010 10:40:20 +0200

Liu, hi

See my answers inline

Sorry for the slight delay in responding.

Best Regards,

yaacov

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 05:09
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]; ext venkatesan mahalingam
Subject: Re: [mpls-tp] Require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02

 hi 

[yw>] The Clear indication would cause the local LSR to change its state
and begin transmission of the NR PSC message with the appropriate FP,P
field settings.  This in-turn will be received by the far-end LSR that
should react appropriately to the NR message.  Similarly, the Clear SF
would cause the local LSR to change its state and begin transmission of
either the WTR or DNR message that would cause the far-end LSR to switch
its own state and wait for the NR message.  

   2 "manual switch to working" is unnecessary and nosense command in my
mind. because the use of the command is to make service come back to
working path. 
   it shows that current state is auto switch state or Force state.
since auto switch or FS is more priority that manual switch. so even if
we 
   have already defined the command. using the command can't switch
current protecting path to working path. 

[yw>] I agree with your analysis.

    best regards 
     liu