[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPLS Last Calls
Bala,
Just getting back to email this evening...
New objects will certainly be needed. As for whether restoration
can be handled purely as extensions to the current drafts remains
to be seen -- it would be nice.
chuck
Bala Rajagopalan wrote:
>
> 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
> >