RE: Comments on document coming around one more time

[Malin Carlzon <malin@sunet.se>]

Hi,

I've read the document through and I think it is okay. I have nothing more
to say than have already been commented.

/Malin


On Thu, 12 Jul 2001, Dave McDysan wrote:

> This draft reads rather well. Here are few comments, section-by-section.
> 
> At a higher level, there is a fair amount of solution-specific text from
> which we should try to extract out the driving requirements in the next
> version.
> 
> Dave
> 
> 1. Abstract
> 
> As for hierarchy, there did not appear to be as much need for work on
> “vertical hierarchy”, defined as communication between network layers such
> as TDM/optical and MPLS.
> 		    ^^^^
> Add after above sentence:
> 
> In particular, instead of direct exchange of signaling and routing between
> vertical layers, some looser form of coordination and communication is a
> nearer term need.
> 
> 4.2 Survivability
> 
> The ordering of the definitions in this section is somewhat unnatural.
> Suggested reordering of paragraph topics: Survivability, protection,
> working, extra traffic, revertive mode, restoration, normalization, SRG.
> 
> I think that the definition of restoration in terms of rerouting is not
> consistent. That is, the rerouting definition uses protection switching
> concepts, while restoration is dyanmic selection and establishment of an
> alternate path (not a pre-selected protection entity).
> 
> 4.3 Survivability Concepts
> 
> In a survivable network design, spare capacity and diversity must be
>                                                              ^^^^^^^
>    built into the network from the beginning to support some degree of
>    self-healing whenever failures occur.
> 
> This section primarily covers protection switching. I think that we need to
> add some more text about restoration. Here is some proposed text for the end
> of this section.
> 
> There is also a class on restoration techniques that do not use the working
> and protect entity concepts of protection switching described above. These
> techniques require detection of a fault, communication of the fault to the
> endpoints of the path (e.g., LSP or optical path), computation of one or
> more candidate alternative p-aths, signaling for establishment of such a
> path, and/or updating routing protocol dissemination regarding network state
> to other nodes. Since a number of messages and interactions between multiple
> nodes are involved, restoration techniques generally take longer to recover
> from a failure than protection techniques do.
> 
> 5.1 Scope
> 
> Is OAM truly out of scope if it is necessary for fault notification in
> restoration? Can we say "currently out of scope" instead?
> 
> 5.2.4 Path Restoration
> 
> Suggest that (a few) refererences be given to path-based restoration
> methods.
> 
> 5.3 Suggest that requirements of a mission critical application are priority
> and preemption. For example, a government may require restoration of certain
> paths at the expense of preempting other paths.
> 
> 5.5 Coordination among layers
> 
> I believe that the last sentence of the last paragraph is an example of a
> shortfall in coordination between layers that the second paragraph says does
> not exist at a significant level. Suggest softening this thought and moving
> the last sentence to the second paragraph, as follows:
> 
> It was felt that the current approach to coordination of survivability
> approaches currently did not have significant operational shortfalls.  These
> approaches include protecting traffic solely at one layer (e.g. at the IP
> layer over linear WDM, or at the  SDH/SONET layer).  Where survivability
> mechanisms might be deployed at several layers, such as when a routed
> network rides a SDH/SONET  protected network, it was felt that current
> coordination approaches were sufficient in many cases.  One exception is
> when SONET protection switching is used, MPLS recovery timers must wait
> until SONET has had time to switch. This limits the recovery time of fast
> MPLS restoration. Also, note that failures within a layer can be guarded
> against by techniques either in that layer or at a higher layer, but not in
> reverse.  Thus, the optical layer cannot guard against failures in the IP
> layer such as router system failures, line card failures.
> 
> 6.1 Historical context
> 
> Suggest that last sentence of first paragraph be reworded, as follows:
> 
> While not perfect, it is workable in the near- to mid-term until
> multi-vendor interoperability is achieved.
> 
> 8. Security Considerations
> 
>    Security is ?NOT? considered in this initial version.
> 
> 11. Author's Addresses
> 
> Dave McDysan
> WorldCom
> 22001 Loudoun County Pkwy
> Ashburn, VA 20147
> dave.mcdysan@wcom.com
> 
> > -----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: Wednesday, July 11, 2001 6:30 PM
> > To: tewg-dt@ops.ietf.org
> > Subject: RE: document coming around one more time
> >
> >
> > Team,
> >    Here's the revised version promised below.
> > Thanks, Wai Sum.
> >
> > -----Original Message-----
> > From: Ed Kern [mailto:ejk@tech.org]
> > Sent: Wednesday, July 11, 2001 1:40 PM
> > To: tewg-dt@ops.ietf.org
> > Subject: document coming around one more time
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> >
> >
> > team,
> >
> > the design team document that waisum pushed around this morning was
> > discussed on the call today, we have every intention of getting this
> > document to the editor by friday.  To do this waisum will be making his
> > last minute changes (and possibly putting it into text form) by this
> > evening and sending it to the list.  Please read and comment (OR send
> > waisum a note that you read it and have no comment) by cob thursday.
> >
> > thanks,
> >
> > Ed
> > -----BEGIN PGP SIGNATURE-----
> > Version: Mulberry PGP Plugin v2.0
> > Comment: processed by Mulberry PGP Plugin
> >
> > iQCVAwUBO0yPfemO/gK7ZGvVAQGTPQQArn85qWExD3lvdS27EEDs/jgOOfC2Fa1K
> > NgjcuvAaNiAOQhN0InUbyqV586t+jykVPCtXLKR+N0O6Nkbwhg3nvDxdHHUlDglb
> > 6uQsDVkLx1/yEdtJugxCrYTUBuYsI7WKq4msHM7eFRf+TSZ8fwmRaK11G8ASfrfI
> > vsCUwa/VRA8=
> > =ktrv
> > -----END PGP SIGNATURE-----
> >
> >
> >
> 
> 
>