[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Last Calls
Bala,
Are you suggesting that restoration signaling requirements be formulated in
a separate GMPLS draft at a later date? If so, the current draft should add
text regarding the current scope (link protection only) as well as future
work (restoration) in Section 7.
Percy
-----Original Message-----
From: Bala Rajagopalan [mailto:BRaja@tellium.com]
Sent: Friday, May 25, 2001 1:57 PM
To: 'C. R. Kalmanek'; John Drake
Cc: ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: GMPLS Last Calls
Chuck:
I believe that the restoration issue can be
dealt with indepedent of the current drafts
on last call. Do you see any obstacles to
adding new objects/semantics (if any) to support
restoration requirements as they arise?
BTW, there are some drafts floating around
on shared mesh.
regards,
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com
> -----Original Message-----
> From: C. R. Kalmanek [mailto:crk@research.att.com]
> Sent: Friday, May 25, 2001 1: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-generaliz
> ed-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-fram
> ework-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-generaliz
> ed-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
>