Re: cleaned up question sheet

[Malin Carlzon <malin@sunet.se>]

On Mon, 2 Jul 2001, Jim Boyle wrote:

> 
> took a pass at cleaning up the question sheet, no new content.
> 
> ------* snip here *--------
> A. Definitions
> 
> 1. In determining the specific requirements, the design team should
>    precisely define  the concepts "survivability", "restoration",
>    "protection", "protection switching", "recovery", "re-routing"
>    etc. and their relations. This would enable the requirements doc to
>    describe precisely which of these will be addressed. 
> 
>    In the following, the term "restoration" is used to indicate the broad
>    set of policies and mechanisms used to ensure survivability.

I agree with Jim and think draft-ietf-mpls-recovery-frmwrk-02.txt
could be a basis used to cover most of the terms.

> 
> 
> B. Network types and protection modes
>
> 1. What is the scope of the requirements with regard to the types
>     of networks covered? Specifically, are the following in scope:
> 
>     -  Restoration of connections in mesh optical networks
>        (opaque or transparent)
>     -  Restoration of connections in hybrid mesh-ring networks
>     -  Restoration of LSPs in MPLS networks (composed of LSRs overlaid on a
>        transport network, e.g., optical)
>     -  Any other types of networks?
>     -  Is commonality of approach, or optimization of approach more important?

I should say that I'm mostly in to IP networks, so that is what I'm
interested in. I'm comming from an IP only environment in Sunet/Nordunet
and an IP as prio one in Utfors (where I have just recently started
working part time) so I guess the IP trafic is what matters to me.

I believe that what should be protected is the IP trafic. Where this
protection is done, is of less importance. (But of course as close to
the IP-layer as possible would be easier since that is where I have
the ability to do anything, especially if I buy a lambda or a virtual
cirquit through someone elses network)

 
> 2.  What are the requirements with regard to
>      the protection modes to be supported in each network type covered?
>(Examples of protection modes include 1+1, M:N, shared mesh,
>      UPSR, BLSR, newly defined modes such as P-cycles, etc.)
> 
> 
> 3.  What are the requirements on local span (i.e., link by link)
>      protection and end-to-end protection, and the interaction between them?
>      E.g.: what should be the granularity of connections for
>      each type (single connection, bundle of connections, etc).

I think local is easier and more useful. When a link goes down, I just
want to get around that link to my next-hop, then let the normal
routing take care of getting me to my final destination.

> 
> C. Hierarchy
> 
> 1. Vertical (between two network layers):
>     What are the requirements for the interaction between restoration
>     procedures across two network layers, when these features are
>     offered in both layers? 
>     (Example, MPLS network realized over pt-to-pt
>     optical connections.) Under such a case,
> 
>     (a) Are there any criteria to choose which layer should provide
>           protection?

I think this varies a lot, it depends from time to time.

If I am a service provider I want it where I am in controll. If I buy my
way through someones network, I want my protection at a layer above. If
the protection of the physical layer is good, fine, then I don't have to
bother at all because I will never even see the problem, if not, I want
the protection to match my criterias, and that is most probably done
at some level close to the IP-level.
If a couple of seconds of outage is okay then OSPF or IS-IS might be
okay, if I want it quicker, MPLS is probably enough. 
  
 
>     (b) If both layers provide survivability features, what are the
>           requirements to coordinate these mechanisms?

As Jim put it, why protect more than once. :-)
But if you want to protect things more than once, I think the layer
closest to the IP-layer should win, that layer is the one that should have
the best knowledge of where the packet is going.


>     (c) How is lack of current functionality of cross-layer
> 	  cooridnation currently hampering operations?
> 
>     (d) Would the benefits be worth additional complexity associated
>           with routing isolation (e.g. VPN, areas), security, address
>           isolation and policy / authentication processes?

No, I'dont think so.

> 
> 
> 
> 2. Horizontal (between two areas or administrative subdivisions within
>     the same network layer):
> 
>     (a) What are the criteria that trigger the creation of protocol or
>           administrative boundaries pertaining to restoration? (e.g.,
>           scalability?  multi-vendor interoperability? what are the
>           practical issues?)  multi-provider? Should multi-vendor
>           necessitate hierarchical seperation?

Multivendor: 
Restoration over boxes from several vendors should be possible.

Multiprovider: 
I think the protection should be kept local as much as possible. But I can
see the point in having protection of a line between two providers. 


> 
>     When such boundaries are defined:
> 
>     (b) What are the requirements on how protection/restoration is
>           performed end-to-end across such boundaries?
> 
>     (c) If different restoration mechanisms are implemented on two
>           sides of a boundary, what are the requirements on their
>           interaction?
> 
>    What is the primary driver of horizontal hierarchy? (select one)
>     - functionality (e.g. metro -v- backbone)
>     - routing scalability
>     - signalling scalability
>     - current network architecture, trying to layer on TE ontop of 
>       already hiearchical network architecture
>     - routing and signalling
> 
>    For signalling scalability, is it
>     - managability
>     - processing/state of network
>     - edge-to-edge N^2 type issue
> 
>     For routing scalability, is it
>     - processing/state of network
>     - are you flat and want to go hierarchical
>     - or already hierarchical?
>     - data or TDM application?
> 
> D. Policy
> 
> 1. What are the requirements for policy support during
> protection/restoration,
>     e.g., restoration priority, preemption, etc.
> 
> E. Signaling Mechanisms
> 
> 1. What are the requirements on the signaling transport mechanism
>    (e.g., in-band over sonet/sdh overhead bytes, out-of-band over
>    an IP network, etc.) used to communicate restoration protocol
>    messages between network elements. What are the bandwidth and
>    other requirements on the signaling channels?
> 
> 2. What are the requirements on fault detection/localization mechanisms
>    (which is the prelude to performing restoration procedures)
>    in the case of opaque and transparent optical networks?
>    What are the requirements in the case of MPLS restoration?
> 
> 3. What are the requirements on signaling protocols to be used in
>    restoration procedures (e.g., high priority processing, security, etc).
> 
> 4. Are there any requirements on the operation of restoration protocols?
> 
> E. Quantitative
> 
> 1. What are the quantitative requirements (e.g., latency) for completing
>    restoration under different protection modes (for both local and
>    end-to-end protection)?

I think to be able to maintain a voice over IP phone call is a good test
case. Other applications normally should not have any more  severe 
requirements than voice. 

> 
> F. Management
> 
> 1. What information should be measured/maintained by the control plane at
>     each network element pertaining to restoration events?
> 
> 2. What are the requirements for the correlation between control plane
>     and data plane failures from the restoration point of view?
> 


/Malin