RE: Comments on document coming around one more time

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

Dave,
   Will do.
Thanks, Wai Sum.

-----Original Message-----
From: Dave McDysan [mailto:dave.mcdysan@wcom.com]
Sent: Friday, July 20, 2001 8:58 AM
To: tewg-dt@ops.ietf.org
Subject: RE: Comments on document coming around one more time


Wai Sum,

I think that if the next version adds the definition that the "protection"
resources for dynamic restoration are the currently unassigned (unreserved)
resources in that layer, this would address my concern.

Dave

> -----Original Message-----
> From: owner-tewg-dt@ops.ietf.org [mailto:owner-tewg-dt@ops.ietf.org]On
> Behalf Of Lai, Wai S (Waisum), ALSVC
> Sent: Friday, July 20, 2001 7:53 AM
> To: tewg-dt@ops.ietf.org
> Subject: RE: Comments on document coming around one more time
>
>
> Dave,
>    Agreed that ordering of definitions needs to be reworked.
> As I said previously, and you also agreed, that this requires
> more time and thought.
>    The reason for the reference to rerouting at the end
> ("In [3], restoration is referred to as recovery by rerouting.")
> is because the document "Framework for MPLS-based recovery"
> (reference [3]) equates restoration as rerouting.  Our document
> clarifies the distinct roles of restoration and rerouting.
>    Did we not all agree at the beginning of the design team
> effort that our document should reference the work of the
> Framework document [3]?
> Thanks, Wai Sum.
>
> -----Original Message-----
> From: Dave McDysan [mailto:dave.mcdysan@wcom.com]
> Sent: Thursday, July 19, 2001 5:57 PM
> To: Lai, Wai S (Waisum), ALSVC; tewg-dt@ops.ietf.org
> Subject: RE: Comments on document coming around one more time
>
>
> As I commented before, the ordering of definitions is somewhat
> difficult to
> follow. If this is to be the terminology used, the definition you
> cited from
> section 4.3 should be given prior to the reference used in recovery in
> section 4.2.
>
> To my taste, the following sentence from section 4.2 is a sufficient
> definiton (I dropped the reference to rerouting at the end).
>
>    Restoration is a survivability technique that dynamically discovers
>    the alternate path from spare resources in network, or establishes
>    new paths on demand, for affected traffic once the failure is
>    detected and the affected traffic is identified.
>
> I think that the reference to working/protect in a dynamic path
> recomputation restoration approach could be confusing. Just my opinion. I
> can see the point of view that "protect" resources are the currently
> unassigned (unreserved) resources in that network layer.
>
> Dave
>
> > -----Original Message-----
> > From: owner-tewg-dt@ops.ietf.org [mailto:owner-tewg-dt@ops.ietf.org]On
> > Behalf Of Lai, Wai S (Waisum), ALSVC
> > Sent: Friday, July 13, 2001 4:01 PM
> > To: tewg-dt@ops.ietf.org
> > Subject: RE: Comments on document coming around one more time
> >
> >
> > Dave,
> >   A protection entity for restoration can be pre-planned (without being
> > pre-established), as stated in the definition of restoration.  A
> > protection
> > entity can have resources reserved-on-demand, as described in
> the 1st para
> > of Section 4.3.  In this sense, the concept of working/protection entity
> > applies also to restoration and is not restricted to protection
> switching.
> > Hence, the defintion of rerouting applies also to restoration.
> > Wai Sum.
> >
> > -----Original Message-----
> > From: Dave McDysan [mailto:dave.mcdysan@wcom.com]
> > Sent: Friday, July 13, 2001 3:04 PM
> > To: Lai, Wai S (Waisum), ALSVC; tewg-dt@ops.ietf.org
> > Subject: RE: Comments on document coming around one more time
> >
> >
> > Wai Sum Lai writes:
> >
> > > Dave,
> > >   Many thanks for your review and the comments below.  I have
> > incorporated
> > > most of them, except:
> > > Section 4.2: Natural ordering is a good suggestion.  Need more time to
> > >   think about it.
> >
> > A reasonable request.
> >
> > Concept of working/protection entities should not be
> > >   restricted to protection switching.  Let's talk more later.
> >
> > To be more specific, the current text defines restoration as performing
> > rerouting, while the definition of rerouting applies only to protection
> > switching. In other words, the definitions are not internally
> consistent.
> > Sorry that I did not have more time to review and comment.
> >
> > > Section 4.3: Will do in next iteration - need to cover both
> > local and path
> > >   restoration
> > > Section 5.2.4: next iteration, in view of Section 4.3
> >
> > This is fine. We are very interested in high-performance path
> > restoration in
> > a multi-vendor environment. Some of this text in this draft implies that
> > this is a fait accompli. I wish that this were so.
> >
> > Dave
> >
>