Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

[Acee Lindem <[e-mail]>]

When all is said and done, more is said than done…
Acee 

On 11/13/13 1:19 PM, "John E Drake" <[e-mail]> wrote:

>It might be fun to enumerate all of the CCAMP drafts that fall into this
>category.
>
>Yours Irrespectively,
>
>John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Huub van Helvoort
>> Sent: Wednesday, November 13, 2013 1:10 PM
>> To: [e-mail]
>> Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-
>> revertive-ps
>> 
>> Hello John,
>> 
>> You replied:
>> 
>> > A nice note.  Dou you think this draft is gilding the lily?
>> 
>> Yes, indeed.
>> 
>> Regards, Huub.
>> 
>> 
>> 
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] On
>> >> Behalf Of Huub van Helvoort
>> >> Sent: Wednesday, November 13, 2013 12:53 PM
>> >> To: [e-mail]
>> >> Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-
>> >> revertive-ps
>> >>
>> >> Hello Zafar,
>> >>
>> >> You wrote:
>> >>
>> >>   > The default parameter value in data plan is deficient for the  >
>> >> following
>> >> reasons:
>> >>>
>> >>>   1. We cannot differentiate between revertive and non-revertive
>>behavior
>> >>>      using default value of wait-to-restore timer.
>> >>
>> >> The value of the WTR timer should not determine the (non-)revertive
>> behavior.
>> >> The (non-)revertive behaviour should be explicitly provisioned.
>> >>
>> >>>      E.g., as far
>> >>>      as I remember default value for WRT is 0, which means
>>protection
>> >>>      is non-revertive.
>> >>
>> >> The typical default value for WTR is 5 minutes to provide a
>> >> hysteresis, it can be overruled by a higher priority event like Sf
>>or SD.
>> >> Setting the value of WTR to 0 does not mean protection is
>>non-revertive.
>> >>
>> >>>      So this default does not work for revertive
>> >>>      protection. I.e., the data plan default cannot cover both
>>revertive
>> >>>      and non-revertive cases.
>> >>
>> >> Again: the WTR value should not be used to indicate (non-)revertive
>> behavior.
>> >>
>> >>>   2. Correct setting for wait-to-restore and hold-off timers need to
>> >>>      account for differential delays between working and protection
>>paths.
>> >>
>> >> No, WTR accounts for repair of the failed path and to encertain that
>> >> the repair can be trusted.
>> >> Hold-off timers are used to allow protection switching in layers
>> >> closer to the physical layer to complete before protection switching
>>in the
>> affected layer.
>> >>
>> >>> In summary, default values cannot cover all use cases. Hence, SP
>> >>> typically wants to set revertive vs. non-revertive behavior,
>> >>> wait-to-restore and hold-off timers on per connection basis.
>> >>
>> >> They will provision default values per layer in the network.
>> >>
>> >> Regards, Huub.
>> >>
>> >> ===========
>> >>> From: Dieter Beller <[e-mail]
>> >>> <mailto:[e-mail]>>
>> >>> Organization: Alcatel-Lucent
>> >>> Date: Sunday, November 10, 2013 9:07 AM
>> >>> To: zali <[e-mail] <mailto:[e-mail]>>
>> >>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail]
>> >>> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
>> >>> <[e-mail] <mailto:[e-mail]>>
>> >>> Subject: Re: [CCAMP] Comment on compatibility in
>> >>> draft-takacs-ccamp-revertive-ps
>> >>>
>> >>>      Hi Zafar,
>> >>>
>> >>>      this draft is defining signaling extensions for the hold-off
>>time as
>> >>>      well as the wait-to-restore time for protected LSPs
>> >>>      where applicable.
>> >>>
>> >>>      There are default values set for these timers in the data
>>plane and
>> >>>      signaling them in the control plane makes only
>> >>>      sense if the timer values shall differ from the default
>>values. Do
>> >>>      you see a need for that? IMO, operators typically
>> >>>      use the defaults and do not set these values on a per
>>connection basis.
>> >>>
>> >>>
>> >>>      Thanks,
>> >>>      Dieter
>> >>>
>> >>>
>> >>>      On 08.11.2013 22:11, Zafar Ali (zali) wrote:
>> >>>>      Hi Lou-
>> >>>>
>> >>>>      You are right, the ctype is TBD, like I mentioned during the
>>meeting
>> that
>> >>>>      we are using different ctype.
>> >>>>
>> >>>>      We would like to take this opportunity to solicit comments
>> >>>> from the WG
>> >> on
>> >>>>      this draft.
>> >>>>
>> >>>>      Thanks
>> >>>>
>> >>>>      Regards Š Zafar
>> >>>>
>> >>>>      -----Original Message-----
>> >>>>      From:"[e-mail]"  <[e-mail]>
>> >>>>      Date: Thursday, November 7, 2013 6:17 PM
>> >>>>      To: zali<[e-mail]>,"[e-mail]"  <[e-mail]>
>> >>>>      Subject: Comment on compatibility in
>> >>>> draft-takacs-ccamp-revertive-ps
>> >>>>
>> >>>>>      Zafar,
>> >>>>>      	My comment in today's session was that you are redefining
>> >>>>> the format
>> >> of
>> >>>>>      an existing object (by adding TLVs) this breaks
>>compatibility.  You
>> >>>>>      stated that this wasn't the case.
>> >>>>>
>> >>>>>      FWIW:
>> >>>>>
>> >>>>>      Your document says:
>> >>>>>
>> >>>>>          0                   1                   2
>>   3
>> >>>>>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
>>8 9 0 1
>> >>>>>         
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>         |            Length             | Class-Num(37) |
>>C-Type(2)   |
>> >>>>>         
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>         |S|P|N|O| Reserved  | LSP Flags |      Reserved     |
>>Link Flags|
>> >>>>>         
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>         |I|R|   Reserved    | Seg.Flags |           Reserved
>>      |
>> >>>>>         
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>         | 
>>      |
>> >>>>>         ~                           sub-TLVs
>>      ~
>> >>>>>         | 
>>      |
>> >>>>>
>> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>
>> >>>>>
>> >>>>>      RFC4872 says
>> >>>>>            0                   1                   2
>>     3
>> >>>>>            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>>7 8 9 0 1
>> >>>>>           
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>           |            Length             | Class-Num(37) |
>>C-Type (2)    |
>> >>>>>           
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>           |S|P|N|O| Reserved  | LSP Flags |     Reserved      |
>>Link Flags|
>> >>>>>           
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>           |                           Reserved
>>        |
>> >>>>>
>> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>>
>> >>>>>      Perhaps you meant C-Type(TBD).  You should address
>>compatibility
>> >>>>>      explicitly in any case.
>> >>>>>
>> >>>>>      Lou
>> >>>>      _______________________________________________
>> >>>>      CCAMP mailing list
>> >>>>      [e-mail]://www.ietf.org/mailman/listinfo/ccamp
>> >>>
>> 
>> 
>> --
>> ***************************************************************
>> **
>>                请记住，你是独一无二的，就像其他每一个人一样
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp