definitions, signalling commonality, and solution priorities

[Jim Boyle <jimpb@nc.rr.com>]

Definitions:

  On the call, there was a concern that folks might have overlapping
  definitions, I'd suggest those found in

	         draft-ietf-mpls-recovery-frmwrk-02.txt 

   What is missing or confusing in there in terms of definitions?

   In fact, as that draft is a fairly comprehensive set of definitions
   and taxonomy of solution space, I suggest that whatever we come up
   with should be done in the context of this draft.

Signalling commonality:

  It's obvious that there will be a variety of scenarios that should
  be protected against, and that these can happen in packet and
  non-packet based networks, and that the same scenario could
  potentially be protected against using a small set of different
  approaches (e.g. a span failure can be handled on a span, link or
  path basis).

  I think we'd all agree that at first, we should try to limit the
  number of solutions that are required to a small set of usful points
  in the spectrum of protection approaches.

  The question I have is, what commanality is desired among the
  mechanisms used to achieve the different protection approaches?

  For instance, it is possible that a variety of information is
  present in the singalling messages for the LSPs, such as whether the
  LSP is carrying working traffic, or is in standby for protection, or
  is actively protecting working traffic, as well as whether it is
  serving to protect multiple LSPs against a given link failure or
  whether it is edge to edge or middle to edge protecting a single
  LSP.

  So would it be better to have solutions which allow such
  complexity to be transported (and tracked) in the network? 

  With another approach, the network may or may not be able to
  distinquish these LSPs from classical LSPs.  I lean heavily towards
  this approach, though I know that many, particulary software
  developers, would tend to refer to this type of approach as
  overloading of semantics, I prefer to refer to it as maximizing use
  of general mechanisms. 

Prioritizing initial solutions:

  There have been a slew of approaches that folks have put forward,
  and that many have accomplished in proprietary implementations.  In
  order to foster some progress on a coarse set of multi-vendor,
  standardized approaches, perhaps it would be good to start listing
  some of the must-cover cases for protection.

  We had discussed coming up with a list of failure scenarios, and
  that'd probably still be a good thing.  I'm likely to lean initially
  to scenarios that can be met with some pretty typical protection
  approaches.  I'll start off with a short list of what I consider
  typical protection approaches:

     - 1:1 edge to edge path protection for data or tdm
	   - what triggers a switch?
	   - "hard" reservations on protect LSPs

     - soft/mesh edge to edge path protection for data or tdm
	   - what triggers a switch?
	   - are paths pre-established, and then what locks resources in?
	   - is bandwidth accounted for (against expected failure scenarios)?

     - 1:N link protection for data or tdm
	   - how is the sharing accomplished?
	     - LSP aggregation?
	     - link resource "double booking"?
	     - roll the dice?

  Also, for the edge to edge approaches, are there ways to protect
  closer to the failure, using detour LSPs that don't just go to the
  other side of a link, but head further down the path (potentially
  the destination), combining with other associated detour LSPs.  I
  think swallow's draft might have touched on this.

  For all cases, how, if at all, are the LSPs in different roles
  differentiated in terms of information in signalling?  What control
  does the connection owner (head end NE) have?

  And as a design team, how can we take these somewhat mechanistic
  focused discussions, and turn them into more general requirements
  that folks can go off and propose sound solutions to?  How do we
  frame it in such a way so as to somewhat limit the set of
  "standardized" approaches at this pass?  Again, I think placing this
  in the context of the mpls-restoration-framework draft would be a
  good thing, perhaps we can provide some prioritized feedback, that
  if the WG and ADs agree with, we can try to keep folks effort on
  approaches that meet those requirements first.  Perhaps some
  additonal motherhood and apple pie requirements (must be scalable,
  robust) as well as some thoughts on what (if any) commonality there
  should be in the solutions in terms of semantics and syntax.