Subject: RE: GMPLS Last Calls

From: John Drake <[email-masked]>
Date: Fri, 25 May 2001 09:58:16 -0700

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:[email-masked]]
Sent: Friday, May 25, 2001 9:54 AM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
[email-masked]
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:[email-masked]]
> Sent: Thursday, May 24, 2001 11:55 AM
> To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> 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-generalized-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-framework-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: [email-masked]; [email-masked]
> 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-generalized-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:[email-masked]]
> Sent: Monday, May 14, 2001 1:52 PM
> To: [email-masked]; [email-masked]
> 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

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Fri, 25 May 2001 13:07:36 -0400

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

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Fri, 25 May 2001 19:24:16 +0200

Hi all,

From that point of view it is clear that during the last IETF meeting
and if i am not making a mistake there were at least 3 presentations
from that aspect (as John mentioned) these edge-to-edge restoration
mechanisms are based either on extending current notification and 
signalling mechanisms (here signalling protocols are the same than 
those used to provision or establish the LSPs) or using a specific 
signalling protocol different from the one used to provision or setup
these LSPs. Notice as well that link restoration (and not only 
protection) could be also discussed from that perspective.

Notice that IETF AB have asked us to wait upon the TE WG requirements
on "network survivability" prior to continue to propose technical 
solutions. I agree with John that with the current status it is rather
difficult to know if (even partially) which direction to pursue.

Regards,
- Dimitri.

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Fri, 25 May 2001 13:56:09 -0400

Hi, Dimitri,

I agree with the IAB direction on this.  We're also familiar 
with all of the proposals that you mention and believe that 
there are some things missing.  In any event, as I'm sure you 
would agree, without requirements it would be hard to say with
confidence that the current GMPLS specs can be readily extended
to meet the (non-existent) requirements :).

chuck