Subject: RE: GMPLS Last Calls

From: "Ash, Gerald R (Jerry)" <[email-masked]>
Date: Thu, 24 May 2001 20:16:56 -0400

Vishal,
You're on target.
Comments below.
Jerry Ash

> I think what he meant was that more service providers should be involved
in
> the discussions for various GMPLS features.

correct, as I mentioned, SPs have been formally asked for their
*requirements*, but not on the GMPLS extensions

> The current drafts are, in fact, weighted
> very heavily in favor of contributors who come from the vendor community,
> with one, perhaps two, exceptions.

correct

> I believe it would be very useful to get some SP input to ensure that
> their operational needs are met and that they can transition to using this
> work, since they, after all, are the ones who will use the protocols.

right, that's the point Tom and Yakov seem to have missed.

---

From: John Drake <[email-masked]>
Date: Thu, 24 May 2001 17:18:16 -0700

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: Bala Rajagopalan <[email-masked]>
Date: Fri, 25 May 2001 17:22:31 -0400

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: [email-masked] 

> Sent: Friday, May 25, 2001 4:34 PM
> To: 'Bala Rajagopalan'; 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> 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
> 
> From: Bala Rajagopalan [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 1:57 PM
> To: 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> 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: [email-masked] 
> 
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 1:08 PM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > 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
> > > 
> > > 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,
> > > > specify a range of different classes of service (e.g. 
> > gold, silver,
> > > bronze)
> > > > service types correspond to different types of network 
> > restoration (e.g.
> > > no
> > > > It is therefore important that GMPLS be extended to be 
> > able to support
> > > such
> > > > restoration schemes.
> > > >
> > > > Percy S. Tarapore
> > > > AT&T Labs
> > > >
> > > > There are still no documented service provider (SP) 
> > requirements driving
> > > the
> > > > e.g., in Section 3.1 of the Generalized Signaling I-D, 
> add "G.707
> > > [Reference

---

From: Bala Rajagopalan <[email-masked]>
Date: Sun, 27 May 2001 13:40:21 -0400

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: [email-masked] 

> Sent: Friday, May 25, 2001 8:18 PM
> To: Bala Rajagopalan
> 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:
> > 
> > > > > involving protection information for link protection. 
> While link
> > > > protection
> > > > > e.g., in Section 3.1 of the Generalized Signaling 
> I-D, add "G.707
> > > > [Reference

---

From: Bala Rajagopalan <[email-masked]>
Date: Mon, 28 May 2001 11:04:21 -0400

hi ping:

The precise problem addressed and the network
node capabilities are described in
our draft 

http://www.ietf.org/internet-drafts/draft-bala-restoration-signaling-00.txt

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: [email-masked] 

> From: Ping Pan [mailto:[email-masked]]
> Sent: Sunday, May 27, 2001 2:08 PM
> To: Bala Rajagopalan
> Cc: 'C. R. Kalmanek'; [email-masked]; [email-masked]
> Many backbone links are SONET, which can redirect traffic to a backup
> channel within 50 msec. This is the requirement that we are 
> dealing here
> in MPLS. So in backbone, we have to rely on pre-established LSP' for
> restoration. I doubt there is any simple method for network nodes to
> detect link failure, setup a new session and adjust all sort 
> of stuff on
> *real-time*.  I could be wrong. Does anybody have the 
> measurement timing
> data on ATM crankback?
> 
> IMHO, the only reason for using real-time restoration signaling is to
> satisfy end-user applications, where based on the network 
> feedback, the
> user application can apply various adaptive mechanisms to renew
> sessions. I don't think this is the within the framework of MPLS.
> 
> 2 cents,
> 
> - Ping
>

---

From: Vishal Sharma <[email-masked]>
Date: Mon, 28 May 2001 12:59:27 -0700

Dimitri, Bala,

I agree with your philosopy. Especally the part that points out that there are 
no
semantics associated with an LSP setup via GMPLS signaling, as currently
defined. Therefore, any type of LSP (working, protect, shared, etc. ) can be
established with GMPLS signaling.

The issue of restoration signaling and how to associate LSPs with working or
protection routes is something that can be (and in fact has been; at least in 
the
MPLS, IPO, and TE WGs) worked on in parallel.

In my view, the issue being raised by Chuck, Jerry, Eve, and others wrt 
restoration is
whether the current
signaling specs. should specify restoration signaling as well, and whether it
would be possible to completely isolate restoration signaling from GMPLS-SIG
in such a way that later developments of restoration signaling do not affect
GMPLS-SIG. You've said that you feel strongly that these can be decoupled.

I feel that it might be worth spending some CPU cycles to make sure that
this is the case (or is largely the case), since it saves considerable 
retrofitting
in the future. When we began work on the GMPLS SIG specs. over a year ago,
restoration was only just beginning to surface in the IETF, and it is only in 
the
last 6 months or so that there has be greater focus on it. So it makes sense
to take a little time to examine GMPLS-SIG in the light of this.

As for Jerry's point, I think all he is saying is that over the last couple of 
IETFs,
there have been formal calls by the ADs, Acting ADs, and different WG advisors
to formally obtain SP input on several items (such as restoration, TE best 
practices,
etc.), but this does not seem to have been the case for GMPLS signaling specs.
(Of course, as Eric rightly pointed out, this does not prevent any SP or their
representatives from providing such input.)

Finally, and others can correct me if I am wrong, isn't there  a little bit of
contradiction in the IETF stance with respect to SP input, given that 
(technically) we
all come to the IETF, not as representatives of our companies, but rather
as individual contributors.

If so, I am a little confused about what it means
to ask for SP input? Are we asking for individual contributors from the
SP community, and hoping that they will bring in (by osmosis) the overall 
philosophy
of their company, or are we asking for companies to specifically send
their representatives to provide inputs on certain topics that have been
deemed to require SP input?

ADs, Chairs, any comments or clarifications?

Thanks,

-Vishal

On Monday, May 28, 2001 6:17 AM, Dimitri Papadimitriou 
[SMTP:[email-masked]] wrote:
> Eric,
>
> Don't be so pessimistic...
>
> I think (and as also proposed by Bala) that today LSP
> "provisioning" which is specified within the GMPLS-SIG
> can be associated with working, protection, shared-
> protection LSP etc. Meaning there is not "semantic"
> associated with the LSP established through GMPLS so
> they can be used for any purpose.
>
> "Restoration signalling" which can be implemented in
> many ways is today under discussion. Bala thinks about
> a dedicated lighweight protocol but other solution are
> feasible using current signalling protocol extensions
> or not. The good thing is that an open discussion has
> been today engaged.
>
> I don't see any problem with respect to GMPLS-SIG
> document over there. I strongly believe that the
> restoration issues can be proceeded indepedently
> from the current GMPLS drafts today on last call.
>
> - Dimitri.
>
> "Mannie, Eric" wrote:
> >
> > Hello Jerry
> >
> > Sorry ! It is an OPEN process since the beginning, everybody can contribute
> > and write a draft. There is no formal process where requirements from
> > operators are asked for. I am not aware of any IETF rule about that !
> >
> > You were welcome to work with us since 1.5 years but you never came to us.
> > You cannot blame us that you never worked on it (we are not responsible for
> > that)! This is true for the thousands of internet drafts being written at
> > the IETF.
> >
> > It is the responsibility of each company individually to decide if they
> > want
> > to contribute or not ! It is not the job of others companies to go to each
> > possible operator/manufacturer and to lobby to have them involved.
> >
> > Regards,
> >
> > Eric << File: dimitri.papadimitriou.vcf >>

---

From: Heiles Juergen <[email-masked]>
Date: Tue, 29 May 2001 02:36:28 +0200

I am sending this email again as comments on the GMPLS last call, as I havent received any response up to now on my comments.

Juergen

> From:	Heiles Juergen [SMTP:[email-masked]]
> Sent:	Monday, May 07, 2001 5:08 PM
> To:	[email-masked]; [email-masked]
> Subject:	Comments on G-PID
> 
> I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt.
> 
> Juergen
> 
> 
> 
> The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID intorduciton text
> "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload."
> 
> Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required.
> 
> Now to the detailed comments:
> The follwoing G-PIDs have to be removed as they are not defined:
>             8     Bit synchronous mapping of E3
>             9     Byte synchronous mapping of E3
>            12     Byte synchronous mapping of DS2/T2
> 
> As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore:
>            19     Same as 12 but in a VC-12
>            20     Same as 13 but in a VC-12
>            21     Same as 14 but in a VC-12
> 
> SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals):
> The whole set of SONET/SDH G-PIDs:
>                 Asynchronous mapping of E4 PDH framed
>                 Asynchronous mapping of E4 SDH framed
>                 Asynchronous mapping of E4 transparent
>                 Asynchronous mapping of DS3 M23
>                 Asynchronous mapping of DS3 C-Bit Parity
>                 Asynchronous mapping of DS3 transparent
>                 Asynchronous mapping of E3 PDH framed 
>                 Asynchronous mapping of E3 SDH framed 
>                 Asynchronous mapping of E3 transparent 
>                 Asynchronous mapping of DS2/T2
>                 Bit synchronous mapping of DS2/T2
>                 Asynchronous mapping of E1 framed
>                 Asynchronous mapping of E1 transparent
>                 Byte synchronous mapping of E1 framed
>                 Byte synchronous mapping of 31 * 64kbit/s
>                 Asynchronous mapping of DS1/T1 SF
>                 Asynchronous mapping of DS1/T1 ESF
>                 Asynchronous mapping of DS1/T1 transparent
>                 Bit synchronous mapping of DS1/T1 SF
>                 Bit synchronous mapping of DS1/T1 ESF
>                 Bit synchronous mapping of DS1/T1 transparent
>                 Byte synchronous mapping of DS1/T1 SF
>                 Byte synchronous mapping of DS1/T1 ESF
>                 VTG/TUG  
>                 STS Group/AUG
>                 POS - No Scrambling, 16 bit CRC
>                 POS - No Scrambling, 32 bit CRC> 
>                 POS - Scrambling, 16 bit CRC
>                 POS - Scrambling, 32 bit CRC
>                 ATM mapping
>                 FDDI mapping
>                 DQDB mapping
>                 GFP mapping
>                 LAPS IP (X.85)
>                 LAPS Ethernet (X.86)
>                 SDL, set-reset scrambler
>                 SDL, self-synchronizing scrambler
>                 O.181 test signal
> 
> Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be payload of an PDH LSP, only of a SONET/SDH and this is already defined. As I assume that no one will setup PDH LSPs the ANSI-PDH technology should be removed completley. The mapping into SONET/SDH is covered under SONET/SDH technology.
> 
> 
> The G-PIDs
> 
>            33     Ethernet                               Lambda, Fiber specific
>            34     SDH                                    Lambda, Fiber    "
>            35     SONET                                  Lambda, Fiber    "
>            36     Digital Wrapper                        Lambda, Fiber    "
>            37     Lambda                                 Fiber            "
> are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown?
> "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID.
>                 
>

---

From: "Tarapore, Percy S" <[email-masked]>
Date: Fri, 25 May 2001 16:34:02 -0400

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:[email-masked]]
Sent: Friday, May 25, 2001 1:57 PM
To: 'C. R. Kalmanek'; John Drake
Cc: [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

Chuck:

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: [email-masked] 

> > that people (including us) have proposed, but in the absence of firm

---

From: "Mannie, Eric" <[email-masked]>
Date: Mon, 28 May 2001 11:57:57 +0200

Dear Jerry and Percy,

I understand you concerns very well. Of course the restoration is of
paramount importance and all GMPLS co-authors are convinced about that. We
didn't forgot it, indeed we specifically decided to not include it at this
stage.

The process is first (if possible) to define an MPLS based restoration and
then to generalize it for GMPLS. This is still this idea of re-engineering
that we are doing since the beginning.

Another point is that this is very touchy and requires a lot of additional
thinking. Also if you consider the amount of religious debate that we
already have for SDH/SONET transparency and concatenation, I let you guess
what it will be for restoration (the IETF defining protection/restoration
protocols applicable to SDH/SONET.... we will have a lot of fun on mailing
lists :-)

The GMPLS specification in WG last call today is the first version. We
didn't want to include and cover everything. Additional work is still
needed. In some cases it should first fit the MPLS concepts and then go to
GMPLS.

Kind regards,

Eric

-----Original Message-----
From: Tarapore, Percy S [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 8:55 PM
To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

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

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

The drafts are:

---

From: "Mannie, Eric" <[email-masked]>
Date: Mon, 28 May 2001 13:43:25 +0200

Hello Chuck,

We are working per step, this is GMPLS step one (first capability set). It
is like the IN approach of ITU-T (capability set one, then capability set
two defined on the top of the first one, etc).

End-to-end protecion/restoration is not part of this first capability set.

Rgds,

Eric

-----Original Message-----
From: C. R. Kalmanek [mailto:[email-masked]]
Sent: Friday, May 25, 2001 7:08 PM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
[email-masked]

chuck

John Drake wrote:
> 
> The point is that in GMPLS, as in regular MPLS, restoration consists of
> notification of failure.  There are a whole spectrum of path and span
> to pursue.  I'm not sure 'shared mesh restoration' completely covers it.
> 
> Thanks,
> 
> John
> 
> > There has been work on protocols for path restoration in mesh networks
by

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 May 2001 07:40:35 -0400

Sounds reasonable to me...

Lou

---

From: John Drake <[email-masked]>
Date: Tue, 29 May 2001 14:00:55 -0700

fine with me

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Friday, May 25, 2001 2:23 PM
To: 'Tarapore, Percy S'; Bala Rajagopalan; 'C. R. Kalmanek'; John Drake
Cc: [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

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: [email-masked]

---

From: "Irfan Lateef" <[email-masked]>
Date: Wed, 30 May 2001 14:03:30 -0400

Dimitri,

The para from your email as I quoted below or some form of it,
explaining or atleast mentioning the independence of the protocol
to the model should be included in the text. This will go a long
way in future helping the readers in understanding the position of
the protocol with reference to the models.

Irfan Lateef

>You speak about GMPLS profiles for the UNI at the OIF, and potentially
>in the future for ASTN/ASON which are completely independent of the
>current GMPLS specification (self-consistency). We don't taylor a
>protocol suite based on the model to which we have to apply it since
>if the model change - you have to re-design your protocol ! -. Today
>GMPLS can be accomodated to any UNI/NNI interfaces coming from
>wherever you want. Why ? Because from the beginning it is a model
>independent specification ! By defining the profile you desire you
>can apply it to the OIF UNI / ASON UNI (if still needed) / etc.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Eve Varma <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked],        
>[email-masked], [email-masked]
>Subject: Re: [IP-Optical] RE: GMPLS Last Calls
>Date: Tue, 29 May 2001 22:40:31 +0200
>
>Hi,
>
>In this e-mail you speak about a "Requirements Design Team"
>do you refer to the NNI OIF project here i guess ?
>
>I wouldn't like to (re-)explain here the nice "reception" offered
>during the San Diego IETF meeting on the BT draft. Moreover, what's
>sound very strange here is that the author himself didn't present
>his draft during the last IETF meeting (since there was a -01 version)!
>Are you serious when you speak about ASON UNI requirements at the
>IETF ?
>
>You speak about GMPLS profiles for the UNI at the OIF, and potentially
>in the future for ASTN/ASON which are completely independent of the
>current GMPLS specification (self-consistency). We don't taylor a
>protocol suite based on the model to which we have to apply it since
>if the model change - you have to re-design your protocol ! -. Today
>GMPLS can be accomodated to any UNI/NNI interfaces coming from
>wherever you want. Why ? Because from the beginning it is a model
>independent specification ! By defining the profile you desire you
>can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also,
>don't spend to many time at the OIF to define the architecture it is
>already done...
>
>Now you mention one question which is under discussion about the
>correlation between the planes... the good point is that with the
>current work done at the IETF and OIF a solution will be found.
>However this does not mean AT ALL that the current GMPLS
>specifications are not going toward a very good direction. Therefore
>i don't think we need the additional text as you propose. In fact this
>is clearly an extended problem of the "restoration" issue already
>discussed on this mailing list and we already agree upon.
>
>Thanks,
>- Dimitri.
>
>Eve Varma wrote:
> >
> > Hi all,
> >
> > Watching the various emails regarding the GMPLS drafts, I see several
> > issues being raised related to some concerns that service provider
> > requirements haven't been sufficiently reflected in the GMPLS signaling
> > specifications - or at least, not been tested against.  (An initial set
> > of requirements was provided by BT on
> > Considerations on the development of an Optical Control Plane -
> > http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
> > Monica has mentioned other currently available sources of service
> > provider requirements as well, such as the Carriers Optical Services
> > Framework and Associated Requirements for the UNI, developed in the OIF
> > and submitted to T1 and ITU-T.  Some requirements were also submitted
> > earlier in the draft Requirements on the ASON UNI -
> > 
>http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
> > )
> >
> > For example, assuring separation of the control plane from the data
> > plane continues to arise - the GMPLS architecture document mentions this
> > separation, but it's not clear how the GMPLS signaling specifications
> > reflect the implications of this decoupling.  This is best illustrated
> > in the handling of control plane failures.  In particular, what happens
> > to established circuit connections if the control plane fails? If the
> > control plane recovers, how do we sync the connection state?  As an
> > example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
> > the reservation state in routers and hosts. RSVP soft state is created
> > and periodically refreshed by Path and Resv messages. The state is
> > deleted if no matching refresh messages arrive before the expiration of
> > a "cleanup timeout" interval." This means that if for whatever reason
> > control messages are lost, the associated data paths will be released.
> > Thus there is strong failure correlation between the control plane and
> > data plane, which is inconsistent with the GMPLS architecture document,
> > and also results in tearing down optical connections resulting from even
> > temporary failures in the control plane.
> >
> > I also understand the other comments from Hirokazu and Shehzad re
> > exclusion of NSAP, having been at the last OIF meeting where there was
> > considerable and spirited discussion of this issue.  The current GMPLS
> > architecture document specifically excludes NSAP, and from the last OIF
> > meeting 6 out of 12 operators discussing this issue felt there was some
> > need to support NSAP addressing.
> >
> > Given that the Requirements Design Team will be starting shortly, I
> > concur with Yuri's suggestion for inclusion of a clear statement of what
> > is - and isn't - covered in the GMPLS Signaling Description, RSVP
> > Extensions, LDP Extensions drafts.   A suggestion for such text is
> > provided below (the intro will need to be tailored to each draft):
> >
> > "Overall, the objective of Generalized MPLS is to adapt MPLS signaling
> > and other protocols to enable their applicability to various switching
> > technologies.   A key motivating application has been applicability to
> > support a distributed control plane for various circuit-switching
> > technologies.   The signaling specifications contained within the these
> > drafts offer a starting point towards this goal; their current scope and
> > applicability, and areas for further assessment, are summarized below:
> >
> > These drafts provide some extensions to traditional MPLS signaling and
> > the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
> > standard track documents) have not been modified.   It is noted that
> > MPLS signaling has been designed with a focus upon packet-switched
> > network based applications, utilizing  requirements and architectural
> > constructs suitable for such applications.   There may be significant
> > distinguishing characteristics with regard to requirements and
> > architectural considerations  for a distributed control plane that
> > supports circuit-switched network applications.  One well acknowledged
> > instance involves the decoupling of the control plane from the data
> > plane.  Such differences may have substantive impact on the signaling
> > mechanisms, the details of which require further study.  In addition,
> > upon further study of operational requirements and circuit-switching
> > technology specific aspects, further signaling extensions may be
> > required.
> >
> > These drafts are focussed upon intra-area signaling interfaces, and do
> > not address issues and considerations related to other domains of
> > usage.   Applicability to inter-area and inter-domain interfaces
> > requires further study."
> >
> > Hope this helps us move forward.
> >
> > Cheers,
> >   Eve
> >
> > itu
> >
> > [email-masked] wrote:
> > >
> > > Hi,
> > >
> > > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS 
>signalling
> > > drafts.
> > >
> > > (1) Decoupling of the control plane from the data plane should be 
>clearly
> > > stated.
> > >
> > > This decoupling clearly has an impact on how the protocols should be 
>defined
> > > to cope with control plane failures.
> > >
> > > (2) Exclusion of NSAP
> > >
> > > The GMPLS architecture document, (which logically speaking should 
>perhaps
> > > have been put forward for last call, ahead of the functional 
>description)
> > > explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> > > communications channels (DCC bytes) therefore the use of alternative
> > > addressing within the same channels may have an adverse effect on
> > > interworking with legacy equipment, particularly with regard to 
>management.
> > > This raises the general concern of what level of compatibility is
> > > required/desired with legacy SDH/SONET equipment.  This debate whilst 
>likely
> > > to be contentious, is unavoidable as the interworking of control 
>plane,
> > > management plane and transport will have a direct impact on how this
> > > equipment is deployed and the economics of whether such deployments 
>will
> > > ever pay off.
> > >
> > > (3) Requirements from both security and OSS has not been discussed 
>fully
> > > yet.
> > >
> > > Security concerns have not been fully addressed, particularly at the
> > > architectural level.  The use of separate control network may 
>necessitate
> > > the need for 24 hour staff to protect against 'Denial of Service' 
>attacks as
> > > currently happens for IP router networks.  The interaction between the
> > > management plane and control plane need to be addressed, for example 
>it is
> > > undesirable to have multiple alarms generated when circuits are 
>created and
> > > torn down otherwise the management of a large scale network will 
>become
> > > impossible.  Discussions on service aspects need to take place, 
>otherwise
> > > the adoption of GMPLS equipment may be hampered, by these (solvable)
> > > concerns.
> > >
> > > Best regards
> > >
> > > Shehzad Mirza
> > >
> > >
> > >
> > > > From: Hirokazu Ishimatsu [SMTP:[email-masked]]
> > > > Sent: 29 May 2001 02:46
> > > > To:   George Swallow; ccamp; mpls
> > > > Cc:   ip-optical; tsg15q11; tsg13q10
> > > > Subject:      [IP-Optical] RE: GMPLS Last Calls
> > > >
> > > > Hi,
> > > >
> > > > From a carrier's perspective, my concerns about GMPLS signaling 
>drafts
> > > > are as follows:
> > > >
> > > > (1) Decoupling of the control plane from the data plane should be 
>clearly
> > > >      stated.
> > > > (2) Exclusion of NSAP
> > > > (3) Requirements from both security and OSS (Operating Support 
>System)
> > > >      has not been discussed fully yet.
> > > >
> > > > Best regards,
> > > > Hirokazu Ishimatsu
> > > > Japan Telecom
> > > >
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > > > > Behalf Of George Swallow
> > > > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: Eaves John <[email-masked]>
Date: Wed, 30 May 2001 15:08:59 -0400

I agree fully with the proposed text in "" in Eve's suggestion below
John Eaves
TyCom (US) Labs

-----Original Message-----
From: Eve Varma [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [IP-Optical] RE: GMPLS Last Calls

Hi all,

Cheers,
  Eve

itu

[email-masked] wrote:
> 
> Hi,
> 
> I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
> drafts.
> 
> (1) Decoupling of the control plane from the data plane should be clearly
> stated.
> 
defined
> The GMPLS architecture document, (which logically speaking should perhaps
> have been put forward for last call, ahead of the functional description)
management.
likely
> to be contentious, is unavoidable as the interworking of control plane,
> equipment is deployed and the economics of whether such deployments will
> ever pay off.
> 
> (3) Requirements from both security and OSS has not been discussed fully
> yet.
> 
> architectural level.  The use of separate control network may necessitate
> the need for 24 hour staff to protect against 'Denial of Service' attacks
as
> management plane and control plane need to be addressed, for example it is
> undesirable to have multiple alarms generated when circuits are created
and
> torn down otherwise the management of a large scale network will become
> impossible.  Discussions on service aspects need to take place, otherwise
> > From a carrier's perspective, my concerns about GMPLS signaling drafts
> > are as follows:
> >
clearly
> >      stated.
> > (2) Exclusion of NSAP
> > (3) Requirements from both security and OSS (Operating Support System)