RE: GMPLS Last Calls: Comments on restoration requirements

[Vishal Sharma <[e-mail]>]

Chuck,

In response to restoration and survivability requirements, I would like to 
point
out that a framework for MPLS recovery is an MPLS WG document (and
has been for some time now; in fact, after we submit the final revision in
the next week or so, based on feedback we received after the last IETF, it
should go to last call as per the decision of the ADs at the last IETF).

http://search.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-02.txt

Also, at the last  IETF, there was support for this document being a  good
starting point for the generation of more general restoration requirements
by the TE WG.

FYI, about a year ago, we had submitted a draft to the TE WG
titled
"Network survivability considerations for traffic engineered IP networks,"
draft-owens-te-network-survivability-00.txt,
which was ahead of its times, and the TE WG was not ready
for it then. The abstract for the draft reads:

"Network survivability refers to the capability of the network to
maintain service continuity in the presence of faults within the
network [1]. This can be accomplished by recovering from network
failures quickly and maintaining the required QoS for existing
services. With the increasing sophistication of network technologies,
survivability capabilities are becoming available at multiple layers,
allowing for protection and restoration to occur at any layer of the
network. This makes it important to: scrutinize the recovery features
of different network layers, understand the pros and cons of performing
recovery at each layer, and assess how the interactions between layers
impact network survivability. With these objectives in mind, this draft
examines the considerations for network survivability at different
layers of the network."

The initial version was an attempt to hightlight all the issues, and an
overview, but it has since expired. Perhaps now
is a good time to resurrect it.

We would be happy to collaborate with any carriers that are interested
in progressing these requirements (in addition to Williams) within the
IETF.

Thanks,

-Vishal

On Friday, May 25, 2001 9:54 AM, C. R. Kalmanek [SMTP:[e-mail]] 
wrote:
> John,
>
> While there currently are no restoration requirements from the
> TE (or other) group, what Percy is saying is that shared mesh
> restoration WILL be a requirement from those groups.  Since the
> current GMPLS drafts don't meet this requirement, they are
> unlikely to meet key SP needs.
>
> I don't understand a process that starts the requirements
> development after last call for the signaling specifications.
>
> chuck
>
> John Drake wrote:
> >
> > Percy,
> >
> > There has been work on protocols for path restoration in mesh networks by a
> > number of
> > people.  However, at the last IETF Kireeti and Vijay clearly indicated that
> > this work,
> > while interesting, wouldn't be allowed to progress in advance of a
> > restoration requirements
> > draft from the TE group.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[e-mail]]
> > Sent: Thursday, May 24, 2001 11:55 AM
> > To: Ash, Gerald R (Jerry); [e-mail]; [e-mail]
> > Subject: RE: GMPLS Last Calls
> >
> > There is a significant issue related to the absence of restoration in the
> > signaling draft
> > 
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> >
> > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > involving protection information for link protection. While link protection
> > schemes may be desirable for fast recovery related to high priority LSP's,
> > more cost-effective shared mesh restoration schemes would be preferred for
> > the majority of traffic from a Service Provider's perspective. This
> > observation is supported by the fact that many vendors are currently
> > developing proprietary schemes for shared mesh restoration. Hence, in
> > addition to the protection information, GMPLS signaling needs to reflect a
> > minimum set of information/attributes required for shared mesh restoration
> > without jeopardizing vendor proprietary solutions.
> >
> > The need for multiple types of restoration capabilities is well documented
> > in the OIF/UNI I-D
> > http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-
> > 00.t
> > xt as follows:
> >
> > " Multiple types of facilities available for restoration are needed
> >    within the network. The following options should be considered for
> >    allocation of facilities to support restoration of failed
> >    connections:
> >    - Dedicated restoration capacity
> >    - Shared restoration capacity. This allows the network to ensure
> >      high quality service for customers, while still managing its
> >      physical resources efficiently.
> >    - Un-restorable
> >    - Pre-emptable"
> >
> > The OIF/UNI I-D supports a range of different restoration schemes through
> > the use of service level as a connection attribute. This attribute is
> > defined as follows:
> >
> > " an integer attribute that indicates a class of service. A carrier may
> > specify a range of different classes of service (e.g. gold, silver, bronze)
> > with predefined characteristics (e.g. restoration plans). The pre-defined
> > service types correspond to different types of network restoration (e.g. no
> > restoration, 1+1 protection), connection set-up and hold priorities,
> > reversion strategies for the connection after failures have been repaired,
> > and retention strategies."
> >
> > It is therefore important that GMPLS be extended to be able to support such
> > restoration schemes.
> >
> > Percy S. Tarapore
> > AT&T Labs
> >
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry)
> > Sent: Thursday, May 24, 2001 2:20 PM
> > To: [e-mail]; [e-mail]
> > Cc: Ash, Gerald R (Jerry)
> > Subject: RE: GMPLS Last Calls
> >
> > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > draft:
> >
> > "Eve - Had hoped that CCAMP formation and expression of requirements would
> > enable us to do more with architecture than reverse architect proposed
> > solution. Think we should also look at carrier requirements and look for
> > discrepancies with architecture.
> > Curtis - requirements of carriers not being addressed?
> > Eve - happy to discuss on mailing list in absence of time"
> >
> > There are still no documented service provider (SP) requirements driving
> > the
> > proposed GMPLS protocol extensions.  This is inconsistent with the current
> > initiatives to provide SP requirements prior to protocol extensions being
> > accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> > MPLS/DiffServ TE, multi-area TE, etc.
> >
> > Here is a sample of SP requirements that are not being addressed (other
> > requirements from our perspective are forthcoming):
> >
> > 1. Restoration requirements, particularly in support of mesh restoration,
> > need to be supported by GMPLS.  For example, Section 7 of the Generalized
> > Signaling I-D
> > 
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> >
> > 4.txt)
> > primarily discusses link protection, restoration capabilities are largely
> > missing and need to be included.
> >
> > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > should be clearly identified in the text and referenced in the GMPLS I-Ds,
> > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > [Reference
> > G.707] is supported by the Generalized Label Request."
> >
> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
> >
> > Jerry Ash
> > AT&T Labs
> >
> > -----Original Message-----
> > From: George Swallow [mailto:[e-mail]]
> > Sent: Monday, May 14, 2001 1:52 PM
> > To: [e-mail]; [e-mail]
> > Subject: GMPLS Last Calls
> >
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> >
> > The drafts are:
> >
> >     1.  Generalized MPLS - Signaling Functional Description
> >
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> >
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> >
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> >
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> >
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> >
> >     4.  GMPLS Extensions for SONET and SDH Control
> >
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> >
> > The last call closes May 29, 12 pm GMT.
> >
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   [phone]
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824