RE: GMPLS Last Calls

[John Drake <jdrake@calient.net>]

The point is that in GMPLS, as in regular MPLS, restoration consists of
rerouting from the endpoints upon
notification of failure.  There are a whole spectrum of path and span
protection possibilites beyond this
that people (including us) have proposed, but in the absence of firm
requirements, it's hard to know which
to pursue.  I'm not sure 'shared mesh restoration' completely covers it.

Thanks,

John  

-----Original Message-----
From: C. R. Kalmanek [mailto:crk@research.att.com]
Sent: Friday, May 25, 2001 9:54 AM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); ccamp@ops.ietf.org;
mpls@uu.net
Subject: Re: GMPLS Last Calls


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:tarapore@att.com]
> Sent: Thursday, May 24, 2001 11:55 AM
> To: Ash, Gerald R (Jerry); ccamp@ops.ietf.org; mpls@uu.net
> 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: ccamp@ops.ietf.org; mpls@uu.net
> 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:swallow@cisco.com]
> Sent: Monday, May 14, 2001 1:52 PM
> To: ccamp@ops.ietf.org; mpls@uu.net
> 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                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824