The MPLS WG Archive

[John Drake <jdrake@calient.net>]

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
> > 
>