Subject: [mpls] Linear Protection MIB

From: Vishwas Manral <[email-masked]>
Date: Thu, 26 Jan 2012 13:34:42 -0800

Hi folks,

We recently posted the draft
http://datatracker.ietf.org/doc/draft-smiler-mpls-tp-linear-protection-mib/?include_text=1on
MPLS-TP linear protection MIB support.

Please have a look and send us any comments you may have.

Thanks,
Vishwas

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 29 Jan 2012 09:05:29 +0100

Hi authors,

Just two questions concerning this MIB (that in general seems to my
untrained eyes as being very well presented) -

1. What is the basis for deciding the default values? In particular why
is "nonrevertive 1+1 bidirectional" presented as the default behavior?

2. In the LP RFC, Signal Degrade is mentioned to be for further study
several times, yet I see several fields within the MIB defining
thresholds and statistics of SD situations sprinkled throughout the MIB.
Could you explain what the basis for these are?

Thanx,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Vishwas Manral
Sent: Thursday, January 26, 2012 11:35 PM
To: [email-masked]
Subject: [mpls] Linear Protection MIB

Hi folks,

We recently posted the draft
http://datatracker.ietf.org/doc/draft-smiler-mpls-tp-linear-protection-m
ib/?include_text=1 on MPLS-TP linear protection MIB support.

Thanks,
Vishwas

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 29 Jan 2012 10:09:13 +0200

Hi authors, 

Thanks for sending this draft to the working group. Please see a couple
of suggestions below.

-          I think you should add an object to configure the hold-off
timer (see RFC 6378, section 3.1). Something like:

mplsLpsConfigHoldOff   OBJECT-TYPE

    SYNTAX     Integer32 (0..10000)

    MAX-ACCESS read-create

    STATUS     current

    DESCRIPTION                                                     

         "The hold-off time in milliseconds. Represents the time 

         between SF/SD condition detection and the declaration of 

         an SF/SD request to the protection switching logic. 

         It is intended to avoid unnecessary switching when a lower-

         layer protection mechanism is in place. 

         Can be configured in steps of 100"

    DEFVAL { 0 }

-          I think mplsLpsConfigSdThreshold should be defined in the LSP
MIB and not here. The reason for this is that the SD threshold should
also used to generate an SD defect, regardless of whether protection is
defined or not.

Let me know what you think. 

Regards,

Daniel   

Vishwas Manral

Hi folks,

Thanks,
Vishwas

---

From: Kingston Smiler <[email-masked]>
Date: Mon, 30 Jan 2012 11:13:35 +0530

Hi Daniel,

Thanks for your suggestion and comments.

Please find the comments inline.

On Sun, Jan 29, 2012 at 1:39 PM, Daniel Cohn <[email-masked]> wrote:

> Hi authors, ****
>
> ** **
>
> Thanks for sending this draft to the working group. Please see a couple of
> suggestions below.****
>
> ** **
>
> **-          **I think you should add an object to configure the hold-off
> timer (see RFC 6378, section 3.1). Something like:****
>
> ** **
>
> mplsLpsConfigHoldOff   OBJECT-TYPE****
>
>     SYNTAX     Integer32 (0..10000)****
>
>     MAX-ACCESS read-create****
>
>     STATUS     current****
>
>     DESCRIPTION                                                     ****
>
>          "The hold-off time in milliseconds. Represents the time ****
>
>          between SF/SD condition detection and the declaration of ****
>
>          an SF/SD request to the protection switching logic. ****
>
>          It is intended to avoid unnecessary switching when a lower-****
>
>          layer protection mechanism is in place. ****
>
>          Can be configured in steps of 100"****
>
>     DEFVAL { 0 }****
>
> **
>
<smiler>

The hold-off timer is a property of server layer not the protection
switching group.
As per the RFC definition, when the server layer detects a SF condition the
server layer should not immediately trigger the recovery,
rather it should wait for the hold-off timer value. So IMO the Hold-off
timer should be a property of server layer not the protection
group.

The section 4.9 of RFC states as follows.

"    A hold-off timer is required to coordinate recovery timing in

   multiple layers or across nested recovery domains.  Setting this
   configurable timer involves a trade-off between rapid recovery and
   the creation of a race condition where multiple layers respond to the
   same fault, potentially allocating resources in an inefficient
   manner. *Thus, the detection of a defect condition in the MPLS-TP*

*   layer should not immediately trigger the recovery process if the
   hold-off timer is configured as a value other than zero.*

</smiler>

>  **
>
> **-          **I think mplsLpsConfigSdThreshold should be defined in the
> LSP MIB and not here. The reason for this is that the SD threshold should
> defined or not.****
<smiler>

 The value stored in this object won't be used to generate the SD defect.
 Instead this value will be used for triggering the recovery.
 As mentioned in the description section of this object in the draft, when
the MPLS OAM detects a  signal degrade with greater than
 or equal to this threshold value, the SD event will be given to
this protection domain as a local input.
 The idea is to keep these two threshold (threshold to generate the SD and
threshold to trigger the recovery) separately.

  Please let us know about your views.

</smiler>

>                                              ****
>
> Let me know what you think. ****
>
> ** **
>
> Regards,****
>
> ** **
>
> Daniel   ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Vishwas Manral
>
> *Sent:* Thursday, January 26, 2012 11:35 PM
> *To:* [email-masked]
> *Subject:* [mpls] Linear Protection MIB****
>
> ** **
>
> Hi folks,
>
>
> http://datatracker.ietf.org/doc/draft-smiler-mpls-tp-linear-protection-mib/?include_text=1on MPLS-TP linear protection MIB support.
>
> ****
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Kingston Smiler <[email-masked]>
Date: Mon, 30 Jan 2012 11:22:19 +0530

Hi Yaacov,

Thanks for spending time to review the draft. The idea is to make this MIB
draft more generic and more adoptable for the
future enhancements in the MPLS TP protection switching area. That is the
main reason we had included some of the
objects which are relevant to SD in this draft.

Regarding the default value, just thought of having the basic protection
model as the default. If you have any suggestion
based on the use cases / deployments we are open to consider your inputs.

Regards,
S. Kingston Smiler

On Sun, Jan 29, 2012 at 1:35 PM, Weingarten, Yaacov (NSN - IL/Hod HaSharon)
<[email-masked]> wrote:

> Hi authors,****
> untrained eyes as being very well presented) –****
>
> 1. What is the basis for deciding the default values? In particular why is
> "nonrevertive 1+1 bidirectional" presented as the default behavior?****
>
> ** **
>
> several times, yet I see several fields within the MIB defining thresholds
> and statistics of SD situations sprinkled throughout the MIB.  Could you
> explain what the basis for these are?****
>
> ** **
>
> Thanx,****
>
> yaacov****
>
> ** **
>
> Of *ext Vishwas Manral

---

From: "Daniel Cohn" <[email-masked]>
Date: Mon, 30 Jan 2012 11:54:01 +0200

Hi,

With regards to the holdoff timer (HOT), I see what you mean. In RFC
6378, HOT is defined as applying to server layer indications to the
protection logic. However RFC 6378 references RFC 6372 for more details,
and the latter (section 4.9) defines HOT as implemented by the higher
layer, see e.g. 

"In this case, * the higher layer will configure * a non-zero hold-off
timer and rely on the receipt of a notification from the lower layer if
the lower layer cannot restoration" (my emphasis)

Besides what the RFCs say, I think it's clear that HOT must be an
attribute of the protection logic and not of the server layer.  Think of
the general case where the protected entity is transported by multiple
server layer entities, e.g. an LSP transported by multiple Ethernet
links. Now assume one of the intermediate Ethernet links fails. To avoid
race condition between Ethernet protection and LSP protection, the LSP
protection logic should introduce a delay between the LSP protection
trigger (OAM trigger) and the LSP protection action, without the
intervention of the failed intermediate Ethernet link. So HOT is clearly
not a function of the server layer, as the intermediate server layer
entities do not constitute an input to the client layer protection
logic. 

As an additional reference in a different technology, see G.783 where
holdoff time (Sn_C_MI_Hotime) is an attribute of the protection function
(SN_C).

Regards,

Daniel

From: Kingston Smiler [mailto:[email-masked]] 
Sent: Monday, January 30, 2012 7:44 AM
To: Daniel Cohn
Cc: Vishwas Manral; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] Linear Protection MIB

Hi Daniel,

	Hi authors, 

	Thanks for sending this draft to the working group. Please see a
couple of suggestions below.

	-          I think you should add an object to configure the
hold-off timer (see RFC 6378, section 3.1). Something like:

	    MAX-ACCESS read-create

	    STATUS     current

	    DESCRIPTION

	         between SF/SD condition detection and the declaration
of 

	         It is intended to avoid unnecessary switching when a
lower-

	    DEFVAL { 0 }

<smiler>

As per the RFC definition, when the server layer detects a SF condition
the server layer should not immediately trigger the recovery,

group.

   multiple layers or across nested recovery domains.  Setting this
   configurable timer involves a trade-off between rapid recovery and
   the creation of a race condition where multiple layers respond to the
   same fault, potentially allocating resources in an inefficient
   manner. Thus, the detection of a defect condition in the MPLS-TP
   layer should not immediately trigger the recovery process if the
   hold-off timer is configured as a value other than zero.

</smiler> 

	-          I think mplsLpsConfigSdThreshold should be defined in
the LSP MIB and not here. The reason for this is that the SD threshold
should also used to generate an SD defect, regardless of whether
protection is defined or not.

<smiler>

 The value stored in this object won't be used to generate the SD
defect.  Instead this value will be used for triggering the recovery. 

 As mentioned in the description section of this object in the draft,
when the MPLS OAM detects a  signal degrade with greater than 

 or equal to this threshold value, the SD event will be given to this
protection domain as a local input. 

 The idea is to keep these two threshold (threshold to generate the SD
and threshold to trigger the recovery) separately.

</smiler> 

	Regards,

	Daniel   

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishwas Manral

	Hi folks,

	
	
	Thanks,
	Vishwas

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 30 Jan 2012 11:24:14 +0100

Hello Kingston,

> The hold-off timer is a property of server layer not the protection

The hold-off timer is a property of every protection switching group.

In the server layer closest to the physical layer the hold-off timer
is set to "0" (zero), in any protection group above this server layer
the hold-off timer should be set to a value =/= 0 to allow recovery
toi happen first in the server layer and this avoid race conditions.

> the server layer should not immediately trigger the recovery,

The text you quote mentions "MPLS-TP layer" which is not necessarily
the server layer closest to the physical layer.

> timer should be a property of server layer not the protection

please look at my explanation above.

>     manner.*Thus, the detection of a defect condition in the MPLS-TP*

Regards, Huub.

---

From: Kingston Smiler <[email-masked]>
Date: Mon, 30 Jan 2012 23:39:52 +0530

Hi,

Thanks Daniel and Huub for the comments and suggestions. Will take care of
your comments and will add the HoldOffTimer object.

Regards,
S. Kingston Smiler.

On Mon, Jan 30, 2012 at 3:24 PM, Daniel Cohn <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> With regards to the holdoff timer (HOT), I see what you mean. In RFC 6378,
> HOT is defined as applying to server layer indications to the protection
> logic. However RFC 6378 references RFC 6372 for more details, and the
> latter (section 4.9) defines HOT as implemented by the higher layer, see
> e.g. ****
>
> ** **
>
> “In this case, * the higher layer will configure * a non-zero hold-off
> timer and rely on the receipt of a notification from the lower layer if the
> lower layer cannot restoration” (my emphasis)****
>
> ** **
>
> Besides what the RFCs say, I think it’s clear that HOT must be an
> server layer entities, e.g. an LSP transported by multiple Ethernet links.
> Now assume one of the intermediate Ethernet links fails. To avoid race
> condition between Ethernet protection and LSP protection, the LSP
> entities do not constitute an input to the client layer protection logic.
> ****
>
> ** **
>
> (SN_C).****
> Daniel****
> *From:* Kingston Smiler [mailto:[email-masked]]
> *Sent:* Monday, January 30, 2012 7:44 AM
> *To:* Daniel Cohn
> *Cc:* Vishwas Manral; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [mpls] Linear Protection MIB****
>
> ** **
>
> Hi Daniel,****
>
> ** **
>
> Thanks for your suggestion and comments.****
>
> ** **
>
> Please find the comments inline.****
>
> ** **
>
> On Sun, Jan 29, 2012 at 1:39 PM, Daniel Cohn <[email-masked]> wrote:**
> **
>
> Hi authors, ****
>
>  ****
>
>  <smiler>****
> switching group.****
> the server layer should not immediately trigger the recovery,****
>
> timer should be a property of server layer not the protection****
>
> group.****
>
>  ****
>
> The section 4.9 of RFC states as follows.****
>
> ** **
>
> "    A hold-off timer is required to coordinate recovery timing in****
>
>    multiple layers or across nested recovery domains.  Setting this****
>
>    configurable timer involves a trade-off between rapid recovery and****
>
>    the creation of a race condition where multiple layers respond to the****
>
>    same fault, potentially allocating resources in an inefficient****
>
>    manner. *Thus, the detection of a defect condition in the MPLS-TP*****
>
> *   layer should not immediately trigger the recovery process if the*
>
> *   hold-off timer is configured as a value other than zero.*****
>
> ** **
>
> </smiler> ****
>
>  ****
>
> MIB and not here. The reason for this is that the SD threshold should also
> used to generate an SD defect, regardless of whether protection is defined
> or not.****
>
>     ****
>
> <smiler>****
>
> ** **
>
>  Instead this value will be used for triggering the recovery. ****
>
> the MPLS OAM detects a  signal degrade with greater than ****
>
> this protection domain as a local input. ****
>
> threshold to trigger the recovery) separately.****
>
> ** **
>
>   Please let us know about your views. ****
>
> ** **
>
> </smiler> ****
>
>                                              ****
>
> Of *Vishwas Manral****
> Hi folks,****
> Vishwas****
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>