[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Last Calls
Hi,
There are two aspects to this problem:
Pre-establishment of protection paths: This
is something requiring signaling support during
provisioning. Don't see any problem in supporting
this under the current GMPLS framework.
Real-time restoration signaling: Our
view is that a dedicated lightweight protocol
is appropriate. (of course, there are other
views on this :-). )
I don't see an obvious show-stopper here w.r.t
progressing the current drafts for last call.
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 8:18 PM
> To: Bala Rajagopalan
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: 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
> > >
>