Re: [mpls] Linear Protection MIB

[Kingston Smiler <[e-mail]>]

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 <[e-mail]> 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
> 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:[e-mail]]
> *Sent:* Monday, January 30, 2012 7:44 AM
> *To:* Daniel Cohn
> *Cc:* Vishwas Manral; [e-mail]; [e-mail];
> [e-mail]
> *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 <[e-mail]> 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 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.****
>
> ** **
>
>   Please let us know about your views. ****
>
> ** **
>
> </smiler> ****
>
>                                              ****
>
> Let me know what you think. ****
>
>  ****
>
> Regards,****
>
>  ****
>
> Daniel   ****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Vishwas Manral****
>
>
> *Sent:* Thursday, January 26, 2012 11:35 PM
> *To:* [e-mail]
> *Subject:* [mpls] Linear Protection MIB****
>
>  ****
>
> 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****
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls****
>
> ** **
>