[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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