[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Last Calls
fine with me
-----Original Message-----
From: Bala Rajagopalan [mailto:BRaja@tellium.com]
Sent: Friday, May 25, 2001 2:23 PM
To: 'Tarapore, Percy S'; Bala Rajagopalan; 'C. R. Kalmanek'; John Drake
Cc: ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: GMPLS Last Calls
This would be fine with me. John? Lou?
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: Tarapore, Percy S [mailto:tarapore@att.com]
> Sent: Friday, May 25, 2001 4:34 PM
> To: 'Bala Rajagopalan'; 'C. R. Kalmanek'; John Drake
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: 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
> >
>