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

[Huub van Helvoort <[e-mail]>]

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
>>>


-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样