[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Last Calls
Hello Chuck,
We are working per step, this is GMPLS step one (first capability set). It
is like the IN approach of ITU-T (capability set one, then capability set
two defined on the top of the first one, etc).
End-to-end protecion/restoration is not part of this first capability set.
Rgds,
Eric
-----Original Message-----
From: C. R. Kalmanek [mailto:crk@research.att.com]
Sent: Friday, May 25, 2001 7:08 PM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); ccamp@ops.ietf.org;
mpls@uu.net
Subject: Re: GMPLS Last Calls
I fully agree: there are a whole spectrum of options that we
need to sort through, and clear requirements are needed to
guide that process. Our concern is with the last call. It
doesn't make sense to progress drafts to RFC that are likely
in hindsight to be viewed as having serious deficiencies in
meeting restoration requirements.
chuck
John Drake wrote:
>
> 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