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

[John E Drake <[e-mail]>]

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