RE: Comments on document coming around one more time

[Dave McDysan <dave.mcdysan@wcom.com>]

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