Subject: Re: Label Set and Suggested Label
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 29 Jun 2001 18:24:11 -0700

Suresh,
        The SDH/SONET case u are talking of is not mentioned in GMPLS
drafts. But the O-UNI draft clearly talks about this case. I think the
GMPLS draft also need to have this information.

Regards,
manoj.

>From: Suresh Katukam <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: Label Set and Suggested Label
>Date: Fri, 29 Jun 2001 18:06:35 -0700
>
>
>Manoj,
>
> >         In the GMPLS drafts, it is mentioned that the use of label set
> > is in the following cases :
> >
> >            a) End equipment is only capable of transmitting and
> >               receiving on a small set of wavelengths.
> >            b) There are sequence of interfaces which can't support
> >               wavelength conversion.
> >            c) It is desireable to limit the amount of wavelength
> >               conversion to reduce the distortion on the optical
> >               signals.
> >            d) Two ends of a link support different sets of wavelengths.
> >
> > All the above four points are valid only in case LSP encoding type is
> > lambda. Does this mean if a label set is received in cases where LSP
> > encoding type is other than Lambda, it should be ignored or considered
> > protocol error ?
>
>I am not sure whether it is the intention of GMPLS authors to list
>all possible scenerios under which a label set is used. There are
>other scenerios under which label set can be used. In TDM, for example,
>one may want to use same time slot (for BLSRs) assigned along the
>entire BLSR segment. In such a scenerio, BLSR headend lists all available
>labels and forwards the PATH message. Each node in BLSR knows what
>label to use when it receives a RESV message.
>
>There may be other reasons too. In anycase, you should not consider
>that to be a protocol error.
>
>Thanks,
>Suresh
> >
> > What about the suggested Label ? Is it also defined to take care of
> > specific LSP encoding type ?
> >
> > Please Clarify.
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com

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

Delivery-date: Fri, 29 Jun 2001 18:09:00 -0700
Date: Fri, 29 Jun 2001 18:06:35 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: manoj juneja <[email-masked]>
CC: [email-masked]
Subject: Re: Label Set and Suggested Label

Manoj,

>         In the GMPLS drafts, it is mentioned that the use of label set
> is in the following cases :
> 
>            a) End equipment is only capable of transmitting and
>               receiving on a small set of wavelengths.
>            b) There are sequence of interfaces which can't support
>               wavelength conversion.
>            c) It is desireable to limit the amount of wavelength
>               conversion to reduce the distortion on the optical
>               signals.
>            d) Two ends of a link support different sets of wavelengths.
> 
> All the above four points are valid only in case LSP encoding type is
> lambda. Does this mean if a label set is received in cases where LSP
> encoding type is other than Lambda, it should be ignored or considered
> protocol error ?

I am not sure whether it is the intention of GMPLS authors to list
all possible scenerios under which a label set is used. There are
other scenerios under which label set can be used. In TDM, for example,
one may want to use same time slot (for BLSRs) assigned along the
entire BLSR segment. In such a scenerio, BLSR headend lists all available
labels and forwards the PATH message. Each node in BLSR knows what
label to use when it receives a RESV message. 

There may be other reasons too. In anycase, you should not consider
that to be a protocol error.

Thanks,
Suresh
> 
> What about the suggested Label ? Is it also defined to take care of
> specific LSP encoding type ?
> 
> Please Clarify.
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 29 Jun 2001 17:13:57 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: LSP Encoding Type
Date: Fri, 29 Jun 2001 17:13:23 -0700

Hi All,
         If a particular implementation supports LSP encoding type
as SDH ITU-T G-707 1996, Does this mean it can't support signals like
AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how?

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

Delivery-date: Fri, 29 Jun 2001 17:11:57 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: GMPLS Doubt
Date: Fri, 29 Jun 2001 17:11:21 -0700

Hi All,
        In the draft draft-ietf-mpls-generalized-signalling-04.txt,
different values of LSP encoding type are defined. What all values
of LSP encoding type are currently supported by GMPLS ?

The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH
etc.

I think the only supported values of LSP encoding type are :

SDH ITU-T G.707 1996
SONET ANSI T1.105-1995
SDH ITU-T G.707 2000
SONET ANSI T1.105-2000
Fiber
Lambda
Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ]

Please comment.

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

Delivery-date: Fri, 29 Jun 2001 17:11:49 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bandwidth Encoding Type Doubt .....
Date: Fri, 29 Jun 2001 17:10:02 -0700

Hi,
    Can someone please tell me the reason for bandwidth encoding
parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
will be drived from the signal type field. How the bandwidth
encoding type will be interpreted in case of other LSP encoding types ?

Regards,
manoj.

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

Delivery-date: Fri, 29 Jun 2001 16:06:30 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Explicit Label Control
Date: Fri, 29 Jun 2001 16:05:51 -0700

Hi All,
          In GMPLS drafts, the concept of Egress/explicit Label control
is described. Is this valid only at egress or intermediate nodes also ?
I mean to say whether the Egress Label object will only be at the end
of ERO or it can appear in between ?

Regards,
manoj.

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

Delivery-date: Fri, 29 Jun 2001 15:55:03 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bi-directional LSPs
Date: Fri, 29 Jun 2001 15:54:02 -0700

Hi All,

        In case of bi-directional LSPs, it is mentioned that an
intermediate node must allocate a label on the outgoing interface and
establish internal data paths before filling in an outgoing upstream
label and propagating the path message.  Furthermore, the terminator
node process the path message as usual, with the exception that the
upstream label can immediately be used to transport data towards the
initiator.
What is the benefit of doing this ? We are also mentioning that if
there is an error in processing of the path message, both the labels
will be invalid. I think there may be some billing issues if the
receiver node start transmitting the data packets, but the path message
received from the prior node is in error.

I think, the downstream label will be valid only after receipt of RESV
message at the source and the upstream label will be valid after the
receipt of RESVCONF at the destination.

Regards,
manoj.

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

Delivery-date: Fri, 29 Jun 2001 15:16:06 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject:  lmp mib
Date: Fri, 29 Jun 2001 15:12:40 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C100E8.9CACAF60
Content-Type: text/plain;
	charset="iso-8859-1"

> Hi,
> 
> In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType
> SYNTAX is given as uint32 in table entry index and when it is
> defined it is given as INTEGER type.  which one is correct?
> 
> thanks
> regards
> bhaskara

------_=_NextPart_001_01C100E8.9CACAF60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE> lmp mib</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In lmpTeLinkTable of&nbsp; =
&quot;draft-dubuc-lmp-mib-02.txt&quot; , lmpTeLinkEncodingType SYNTAX =
is given as uint32 in table entry index and when it is</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">defined it is given as INTEGER =
type.&nbsp; which one is correct?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">regards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bhaskara</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C100E8.9CACAF60--

Delivery-date: Fri, 29 Jun 2001 13:09:59 -0700
Date: Fri, 29 Jun 2001 22:04:40 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Heiles Juergen <[email-masked]>
CC: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: draft-fontana-gmpls-control-g709-00.txt

This is a multi-part message in MIME format.
--------------40F56A4E57D25EB88717B4D0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Juergen,

Yes, the alignment of the last section of the previous version
needed to be performed (it is quite normal, since last version 
publication ODUk multiplexing has been now clearly defined, also
we have update the GPID list of values, and much more).

Now it has been done. The updated version will be published very 
soon and in order to let people the time to read it, comment it, 
etc.

Regards,
Dimitri.

Heiles Juergen wrote:
> 
> My vote is c) and b).
> Even so it is not all wrong, large parts and specially the GMPLS extensions in section 5 to not fit to G.709.
> I will contribute to the work.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Kireeti Kompella [SMTP:[email-masked]]
> > Sent: Tuesday, June 19, 2001 4:00 AM
> > To:   [email-masked]
> > Subject:      draft-fontana-gmpls-control-g709-00.txt
> >
> > Hi All,
> >
> > There is a draft on signaling for G.709 networks, URL:
> > http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt
> >
> > Please send comments to the CCAMP mailing list on whether you
> > think that this draft should be made a CCAMP WG document or not,
> > and why:
> >    a) yes, this draft is pretty good as it stands;
> >    b) yes, this draft needs some work, but is okay;
> >    c) no,  this draft is all wrong, but signaling in G.709 networks
> >       is something that the IETF should be working on;
> >    d) no,  this is not a subject that the IETF should touch.
> >
> > (Just to make it clear: this proposal is not an architecture, or even
> >  a re-architecture of G.709 -- that work belongs in the ITU.)
> >
> > Thanks,
> > Kireeti & Vijay.
--------------40F56A4E57D25EB88717B4D0
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------40F56A4E57D25EB88717B4D0--

Delivery-date: Fri, 29 Jun 2001 10:38:27 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Label Set and Suggested Label
Date: Fri, 29 Jun 2001 10:34:11 -0700

Hi All,
        In the GMPLS drafts, it is mentioned that the use of label set
is in the following cases :

           a) End equipment is only capable of transmitting and
              receiving on a small set of wavelengths.
           b) There are sequence of interfaces which can't support
              wavelength conversion.
           c) It is desireable to limit the amount of wavelength
              conversion to reduce the distortion on the optical
              signals.
           d) Two ends of a link support different sets of wavelengths.

All the above four points are valid only in case LSP encoding type is
lambda. Does this mean if a label set is received in cases where LSP
encoding type is other than Lambda, it should be ignored or considered
protocol error ?

What about the suggested Label ? Is it also defined to take care of
specific LSP encoding type ?

Please Clarify.

Regards,
manoj.

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

Delivery-date: Thu, 28 Jun 2001 12:42:09 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: {SUKLM} numbering scheme
Date: Thu, 28 Jun 2001 21:38:10 +0200

Hello Manoj,

The label is the same of course.

The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a
small bug coming from an old version. That should be removed by Lou. We
should have only one SDH LSP encoding type value for SDH (same for SONET).

Lou: thanks to correct it.

For the conversion table, Maarten should still have it.

Kind regards,

Eric

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 8:28 PM
To: [email-masked]
Subject: {SUKLM} numbering scheme

Hi All,
          I have a doubt regarding {SUKLM} numbering scheme. If I
allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
ITU-T G.707 2000 ?

Eric, on the ipo u and marteen once exchanged the conversion table for
EDCBA and SU, If that table is correct, can u please tell me the
formula from which u derived that table ?

Regards,
manoj.

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

Delivery-date: Thu, 28 Jun 2001 12:33:11 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: LSP Encoding Type 
Date: Thu, 28 Jun 2001 12:31:07 -0700

Hi All,
         If a particular implementation supports LSP encoding type as
SDH ITU-T G-707 1996, Does this mean it can't support signals like
AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how ?

Regards,
manoj.

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

Delivery-date: Thu, 28 Jun 2001 11:28:23 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: {SUKLM} numbering scheme
Date: Thu, 28 Jun 2001 11:27:35 -0700

Hi All,
          I have a doubt regarding {SUKLM} numbering scheme. If I
allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be
different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH
ITU-T G.707 2000 ?

Eric, on the ipo u and marteen once exchanged the conversion table for
EDCBA and SU, If that table is correct, can u please tell me the
formula from which u derived that table ?

Regards,
manoj.

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

Delivery-date: Thu, 28 Jun 2001 11:15:21 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: looking for LMP
Date: Thu, 28 Jun 2001 11:10:49 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FFFD.A9462850
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Does any one know about the LMP public domain availability?
Or any interop testing tool for testing the functionality of LMP?

thank you

with regards
bhaskara

------_=_NextPart_001_01C0FFFD.A9462850
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>looking for LMP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi,</FONT>
</P>

<P><FONT SIZE=2>Does any one know about the LMP public domain availability?</FONT>
<BR><FONT SIZE=2>Or any interop testing tool for testing the functionality of LMP?</FONT>
</P>

<P><FONT SIZE=2>thank you</FONT>
</P>

<P><FONT SIZE=2>with regards</FONT>
<BR><FONT SIZE=2>bhaskara</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0FFFD.A9462850--

Delivery-date: Thu, 28 Jun 2001 08:35:58 -0700
Date: Thu, 28 Jun 2001 10:30:08 -0400
From: Eric Gray <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: Re: Question

Bert,

    I think most people would agree that being told to subscribe to
yet another mailing list is an inferior proposal even in comparison
with simply cross-posting.  Just for example, if I were to use your
proposal, I would be obliged to post the message -

===================================================================
    Hey CCAMP people!  There's a discussion of "MIBs for GMPLS"
going on on the MPLS mailing list.  If this topic is of interest to
you and you are not already subscribed to the MPLS mailing list,
then you should subscribe to the MPLS mailing list now.
===================================================================

- because this is exactly what is happening.

    What I would suggest is that - if indeed the mailing lists have
so many subscribers in common (an assertion you, and some others,
have made but nobody can prove) - then collapse the mailing lists.
Since it is not POSSIBLE for an individual to ascertain on their own
what overlap - if any - exists between the CCAMP and MPLS mailing
lists, then no one has any business climbing down anyone else's
throat because they decide to cross-post rather than send separate
messages on multiple lists.

--
Eric Gray

You wrote (in part):

> I did send that posting about "pls do not cross-post".
> I think that if we have a specific topic, then we should be able
> to figure out in which WG it belongs, or which WG chairs agree
> to discuss the topic on their WG mailing list. Once we have
> decided that, then it is appropriate to ONLY discuss it there,
> and then if anyone feels that some other mlist should be aware,
> then you could do a short posting to state that "discussion X
> is going on over in WG Z, pls join us on mlist Z if this topic
> is in your interest area".
>
> Bert

Delivery-date: Thu, 28 Jun 2001 06:41:04 -0700
From: Heiles Juergen <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: draft-fontana-gmpls-control-g709-00.txt
Date: Thu, 28 Jun 2001 15:40:32 +0200

My vote is c) and b).
Even so it is not all wrong, large parts and specially the GMPLS extensions in section 5 to not fit to G.709.
I will contribute to the work.

Regards

Juergen

> -----Original Message-----
> From:	Kireeti Kompella [SMTP:[email-masked]]
> Sent:	Tuesday, June 19, 2001 4:00 AM
> To:	[email-masked]
> Subject:	draft-fontana-gmpls-control-g709-00.txt
> 
> Hi All,
> 
> There is a draft on signaling for G.709 networks, URL:
> http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt
> 
> Please send comments to the CCAMP mailing list on whether you
> think that this draft should be made a CCAMP WG document or not,
> and why:
>    a) yes, this draft is pretty good as it stands;
>    b) yes, this draft needs some work, but is okay;
>    c) no,  this draft is all wrong, but signaling in G.709 networks
>       is something that the IETF should be working on;
>    d) no,  this is not a subject that the IETF should touch.
> 
> (Just to make it clear: this proposal is not an architecture, or even
>  a re-architecture of G.709 -- that work belongs in the ITU.)
> 
> Thanks,
> Kireeti & Vijay.

Delivery-date: Thu, 28 Jun 2001 06:14:59 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Question
Date: Thu, 28 Jun 2001 15:13:51 +0200

> ----------
> From: 	Eric Gray[SMTP:[email-masked]]
> Sent: 	Wednesday, June 27, 2001 5:31 PM
> To: 	Common Control and Measurement Protocols - List Manager
> Cc: 	Common Control and Measurement Protocols
> Subject: 	Question
> 
> Hi.
> 
>     My understanding of IETF policy is that the mailing lists are
> required to be public.  This is necessary in order for someone who
> is posting to such a list to be able to determine who might be a
> recipient.
> 
I am not aware that there are any rules that anybody should be able 
to find out. In fact... I'd rather see that not just anybody can go and 
query the IETF mailing list subscriptions and then use that info for 
spamming us.

>     This turns out to be a fair and important requirement based on
> recent discussions concerning 'cross-posting'.  I would like to
I did send that posting about "pls do not cross-post".
I think that if we have a specific topic, then we should be able
to figure out in which WG it belongs, or which WG chairs agree
to discuss the topic on their WG mailing list. Once we have
decided that, then it is appropriate to ONLY discuss it there,
and then if anyone feels that some other mlist should be aware,
then you could do a short posting to state that "discussion X
is going on over in WG Z, pls join us on mlist Z if this topic
is in your interest area".

Bert
> be able to determine - on my own - whether or not there is in
> fact a large cross-section in common between this mailing list
> and the mailing list for MPLS.  I would also like to be able to
> explicitly detemine who is 'missing' from each list.  This is very
> useful when - for example - I discover that I (or someone else)
> has inadvertently posted to the wrong list and I do not want to
> send duplicate messages.
> 
>     Please advise how I am supposed to be able to do this if you
> have disabled the 'who' command for this public mailing list?
> 
> --
> Eric Gray
> 
> 

Delivery-date: Wed, 27 Jun 2001 23:53:57 -0700
From: Sasha Vainshtein <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Cc: "Igor Danilovich (E-mail)" <[email-masked]>
Subject: RE: sdh Doubt
Date: Thu, 28 Jun 2001 09:48:57 +0200

Manoj,
AFAIK, the answer is YES. In SDH, once you have performed concatenation, 
on a certain stream, you cannot allocate access separate substreams.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 9:12 PM
> To: [email-masked]
> Subject: sdh Doubt
> 
> 
> Hi All,
>          AUG-256 may consist of :
>                   1. 4 AUG-64
>                   2. 1 AU-4-256c
> 
>   If AUG-256 consists of 1 AU-4-256c, does this mean it can't 
> allocate 
> signals of less granularity than this (viz. one VC-4 or 
> VC-4-64c or VC-4-16c 
> etc) ?
> 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 

Delivery-date: Wed, 27 Jun 2001 12:29:06 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: GMPLS Doubt
Date: Wed, 27 Jun 2001 12:27:33 -0700

Hi All,
        In the draft draft-ietf-mpls-generalized-signalling-04.txt,
different values of LSP encoding type are defined. What all values
of LSP encoding type are currently supported by GMPLS ?

The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH
etc.

I think the only supported values of LSP encoding type are :

SDH ITU-T G.707 1996
SONET ANSI T1.105-1995
SDH ITU-T G.707 2000
SONET ANSI T1.105-2000
Fiber
Lambda
Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ]

Please comment.

Regards,
manoj.

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

Delivery-date: Wed, 27 Jun 2001 12:13:00 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: sdh Doubt
Date: Wed, 27 Jun 2001 12:11:32 -0700

Hi All,
         AUG-256 may consist of :
                  1. 4 AUG-64
                  2. 1 AU-4-256c

  If AUG-256 consists of 1 AU-4-256c, does this mean it can't allocate 
signals of less granularity than this (viz. one VC-4 or VC-4-64c or VC-4-16c 
etc) ?

Regards,
manoj.

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

Delivery-date: Wed, 27 Jun 2001 09:56:54 -0700
From: Randy Bush <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: Common Control and Measurement Protocols <[email-masked]>
Subject: Re: Question
Date: Wed, 27 Jun 2001 09:51:15 -0700

>     My understanding of IETF policy is that the mailing lists are
> required to be public.  This is necessary in order for someone who
> is posting to such a list to be able to determine who might be a
> recipient.

the postings to the list are public.  i am not aware of a requirement
that the list of subscribers should be.

randy

Delivery-date: Wed, 27 Jun 2001 09:56:54 -0700
From: Fong Liaw <[email-masked]>
To: 'Suresh Katukam' <[email-masked]>, Yangguang Xu <[email-masked]>
Cc: Eric Gray <[email-masked]>, [email-masked]
Subject: RE: Suggested Label Doubt
Date: Wed, 27 Jun 2001 09:51:27 -0700

Suresh

>  
>  It is completely waste for bidirectional LSPs in TDM 
>  networks. In TDM networks,
>  the label must be same and current draft (OIF) specifies 
>  that the upstream
>  lable should be same as Suggested label. It should be really 
>  made optional
>  so that if an upstream node wants to suggest, then it has 
>  freedom to do so.

Can you elaborate on which one should be optional, in context
of either OIF or GMPLS. The current OIF UNI applies only to
SONET/SDH, and it also said that a node should specify 
the same label in Label Set if it does not support different 
labels of upstream and downstream for bidirectional LSP. 
Suggested label is always optional in both cases, and if
you specify Label Set in this case, you would most likely
not need to specify Suggested label ...

Thanks.
-Fong

>  
>  Thanks,
>  Suresh
>  

Delivery-date: Wed, 27 Jun 2001 09:43:41 -0700
From: John Drake <[email-masked]>
To: 'Giovanni Fiaschi' <[email-masked]>, John Drake <[email-masked]>
Cc: John Drake <[email-masked]>, 'Heiles Juergen' <[email-masked]>, 'Yangguang Xu' <[email-masked]>,  Diego Caviglia <[email-masked]>, Ayan Banerjee <[email-masked]>, [email-masked]
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 09:39:53 -0700

The unreserved bandwidth information is useful but it is thresholded so that
an LSA is not
issued every time an LSp is activated or deactivated, and the thresholds may
be configured
by the network owner so that the volume of LSA traffic is controlled. 

-----Original Message-----
From: Giovanni Fiaschi [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 9:36 AM
To: John Drake
Cc: John Drake; 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia; Ayan
Banerjee; [email-masked]
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Ok, got it. If I understand well, this advises against dynamic information
distribution for the unreliability of this kind of information.
Thus, for example, the Unreserved Bandwidth TLVs in
draft-ietf-ospf-diff-te-00.txt should not be used.

John Drake <[email-masked]> on 27/06/2001 18.07.38

 

                                                              

 To:      Giovanni Fiaschi/MAIN/MC1@MCMAIN, John Drake        
          <[email-masked]>                                
                                                              
 cc:      "'Heiles Juergen'" <[email-masked]>, 
          John Drake <[email-masked]>, "'Yangguang Xu'"   
          <[email-masked]>, Diego Caviglia/MAIN/MC1@MCMAIN,  
          Ayan Banerjee <[email-masked]>,              
          [email-masked]                                  

                                                              
 Subject: RE: Optical impairments in                          
          draft-ietf-mpls-generalized-signaling-   04         

The point is that there is always a race condition wrt to resource
availability.  Routing
can give you an acceptable path but signalling tells you whether the
resources along that
path are available at the time the attempt is made to establish the LSP.
Advertising
resource availability information is usually not a good idea as it causes a
flooding load
and doesn't prevent the race condition.

Advertising impairments in routing and using them to determine whether a
path is feasible
makes sense but advertising wavelength availability or wavelength conversion
capapbility,
if it is a limited resource, doesn't.

-----Original Message-----
From: Giovanni Fiaschi [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:53 AM
To: John Drake
Cc: 'Heiles Juergen'; John Drake; 'Yangguang Xu'; Diego Caviglia; Ayan
Banerjee; [email-masked]
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

I don't see the point of some calculations during routing and some other
during
signaling.
Either I find during routing a path that works, that is with both wavelength
continuty (if conversion is not allowed in some network sub areas) and
acceptable signal degradation, or I accept crankback or unavailable resource
answers during signaling (when it is too late to attempt alternate routes)
due
to any of wavelength not found or unacceptable signal.

JD:  I think that we might be agreeing with each other;  i.e., impairments
should be handled in routing and wavelength continuity should be handled in
signalling.

Delivery-date: Wed, 27 Jun 2001 09:13:29 -0700
From: John Drake <[email-masked]>
To: 'Giovanni Fiaschi' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Heiles Juergen' <[email-masked]>, John Drake <[email-masked]>, 'Yangguang Xu' <[email-masked]>, Diego Caviglia <[email-masked]>, Ayan Banerjee <[email-masked]>,  [email-masked]
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 09:07:38 -0700

The point is that there is always a race condition wrt to resource
availability.  Routing
can give you an acceptable path but signalling tells you whether the
resources along that
path are available at the time the attempt is made to establish the LSP.
Advertising
resource availability information is usually not a good idea as it causes a
flooding load
and doesn't prevent the race condition.  

Advertising impairments in routing and using them to determine whether a
path is feasible
makes sense but advertising wavelength availability or wavelength conversion
capapbility,
if it is a limited resource, doesn't.   

-----Original Message-----
From: Giovanni Fiaschi [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:53 AM
To: John Drake
Cc: 'Heiles Juergen'; John Drake; 'Yangguang Xu'; Diego Caviglia; Ayan
Banerjee; [email-masked]
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

I don't see the point of some calculations during routing and some other
during
signaling.
Either I find during routing a path that works, that is with both wavelength
continuty (if conversion is not allowed in some network sub areas) and
acceptable signal degradation, or I accept crankback or unavailable resource
answers during signaling (when it is too late to attempt alternate routes)
due
to any of wavelength not found or unacceptable signal.

JD:  I think that we might be agreeing with each other;  i.e., impairments
should be handled in routing and wavelength continuity should be handled in
signalling.

Delivery-date: Wed, 27 Jun 2001 08:52:35 -0700
From: John Drake <[email-masked]>
To: 'Diego Caviglia' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Heiles Juergen' <[email-masked]>, 'Yangguang Xu' <[email-masked]>, Ayan Banerjee <[email-masked]>,  [email-masked], Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 08:51:35 -0700

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 2:27 AM
To: John Drake
Cc: 'Heiles Juergen'; 'Yangguang Xu'; Ayan Banerjee; [email-masked];
Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Hi John,
                   please see my comments in line.

Best regards.

Diego.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

John Drake <[email-masked]> on 26/06/2001 23.57.48

 

                                                              

 To:      "'Heiles Juergen'" <[email-masked]>, 
          "'Yangguang Xu'" <[email-masked]>, Diego           
          Caviglia/MAIN/MC1@MCMAIN                            
                                                              
 cc:      Ayan Banerjee <[email-masked]>,              
          [email-masked], Giovanni                        
          Fiaschi/MAIN/MC1@MCMAIN                             

                                                              
 Subject: RE: Optical impairments in                          
          draft-ietf-mpls-generalized-signaling-   04         

Announcing wavelength availability information in routing doesn't work
because of the flooding traffic it would generate, plus there are still race
conditions that would have to be handled by signalling anyway.

[dc] John could you please clarify why distribute wavelength availability
 that could be even encoded in only 160 bits per fiber (1 lambda available
0 lambda unavailable) doesn't scale while distribute other link related
information such as those described in OSPF TE extension scales?

JD:  A 160 bit vector may not be sufficient, rather we might have to
advertise frequency and spacing information.  In any case, we would be
causing
excessive flooding if we issued an LSA every the value of the bit vector
changed.  There are provider configurable thresholds associated with
unreserved
bandwidth so that an LSA is not issued whenever an LSP is created or
deleted.
Wavelength availability can't be dealt with the same way.

Yes I agree that race condition is always a problem when resource
information is
distributed in a non-instantaneous way.

But this is also valid for Unreserved Bandwidth sub-TLV in OSPF TE
extension.

Label set was intended to support wavelength continuity issues.

Also, in the short term, we're dealing with transponder based interfaces to
the DWDM systems so this is a non-issue.  In the longer term, this is just
another issue like PMD and OSNR that will need to be dealt with.

[dc] I know that at present OXC are bordered with transponder
but in this case what is the purpose of Label set object?
I mean in this scenario (DWDM line terminal always perform OEO conversion)
 from a routing perspective we don't have to worry at all about optical
impairments
we have just to leave them to DWDM network planning engineers.

JD:  I think that the intent of label sets was to deal with heterogeneous
node/link capabilities in the future.  I.e., address it now so that when
nodes or links without wavelength conversion capabilities are added to a 
network things don't break. 

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 7:43 AM
To: 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Yangguang,

wavelength conversion is in my view an issue for path selection as you
cannot select a certain path if the wavelength doesn't fit and you have no
wavelength conversion.

Regards

Juergen

> -----Original Message-----
> From:   Yangguang Xu [SMTP:[email-masked]]
> Sent:   Tuesday, June 26, 2001 3:13 PM
> To:     Diego Caviglia
> Cc:     Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:     Re: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
>
>
> Diego,
>
> As indicated by the document that Ayan pointed to you, there are many
constrains
> for the optical networking. These constrains can be considered at network
> planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
connection
> setup time(GMPLS signaling). When a constrain is considered is an
engineering
> issue. We just have to figure out when and where is the best and cheapest
to
> consider a constrain. To wavelength conversion, GMPLS signaling is a good
place
> to handle.
>
> Thanks,
>
> Yangguang
>
> Diego Caviglia wrote:
> >
> > Ayan,
> >
> >           Thanks for your answer but I don't understand why lambda
conversion is
> > a  signalling  problem and thus is covered in generalized signalling
draft while
> > others  optical  impairments  are  routing problem and are covered in a
separate
> > document.
> >
> > Moreover  even  if the document you quoted is a well written and very
useful one
> > it  is  an  informative  contribution  that  simply  points  out  the
physically
> > impairments  of  an  all  optical  network.  It doesn't propose any
extension to
> > OSPF/IS-IS in order to support optical routing.
> >
> > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
lots of new
> > information,  as  you  stated  in  your document, are we sure that OSPF,
in this
> > environment, scales?
> >
> > I  mean if it doesn't scale for wavelength availability information
distribution
> > why it has to scales for other optical impairment distribution?
> >
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> >
> > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> >
> >
> >
> >
> >
> >
> >
> >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> >           [email-masked], [email-masked]
> >
> >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> >
> >
> >
> >  Subject: RE: Optical impairments in
> >           draft-ietf-mpls-generalized-signaling-  04
> >
> >
> >
----------------------------------------------------------------------------
----
> >
> > Diego,
> >
> > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> >
> > Thanks,
> > Ayan
> >
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 6:19 AM
> > To: [email-masked]; [email-masked]
> > Cc: Giovanni Fiaschi
> > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> >
> > Peter ,all,
> >
> >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
In
> > the
> > draft  there is the label set object that is very useful in All optical
> > networks
> > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > problems
> > related  to  path  establishment  in  such networks.  I mean what about
OSNR
> > and
> > non-linear  impairments? What about gain variation and power
equalization?
> > Where
> > are covered these topic?
> >
> > If  I  can  find  a  path  feasible from the lambda continuity point of
view
> > who
> > assure me that I have the needed Q at the end of the all optical path?
> >
> > Best regards.
> >
> > ----------------------------------------------------------------
> > Diego Caviglia>
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com

Delivery-date: Wed, 27 Jun 2001 08:42:40 -0700
From: John Drake <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, John Drake <[email-masked]>, 'Yangguang Xu' <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Ayan Banerjee <[email-masked]>, [email-masked],  Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 08:37:58 -0700

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 12:19 AM
To: 'John Drake'; Heiles Juergen; 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

John,

wavelength availability and wavelength conversion are two different points
in my view.
A optical corss-connect without wavelength conversion can be seen as a
connection matrix with limited connectivity (e.g. only connections between
inputand output ports with the same lambda are possible), while a
corss-connect with wavelength conversion has full connectivity if no other
constrains apply. This is a static information that doesn't change over
time. It is detected during startup of the network and will not result in
flooding traffic. 

JD:  Good point, and as I indicated in my note, today we're implicitly
assuming that every link is capable of wavelength conversion and has no
impairments.  Perhaps a note to this effect should be added to the routing
draft.  (In general, I think the plan was to assume as a default that links
were unimpaired and that links with impairments would be advertised as
exceptions.)  However, wavelength conversion capabilities are not advertised
between areas or ASs, so signalling still has to deal with wavelength
continuity.  Further, in the future wavelength conversion may be a node
based limited resource, both wrt capacity as well as capability (i.e., which
input frequency can be converted to which output frequency), so it probably
won't be static and advertising it could cause a flooding load.  And, again,
it doesn't help between areas or ASs and there are race conditions so
signalling still has to deal with wavelength continuity. 

The available connectivity of a connection matrix can be taken into account
by the routing.
Wavelength availability is a second issue. If you want to annouce the used
and unused wavelengths in real-time you end up with flooding traffic and
race conditions, I agree. But this is independent of wavelength conversion
availability. A label set helps in my view only if you have wavelength
conversion as it allows you to select between different wavelengths. 

JD:  Peter and Lou are the experts, but I think that the point of label sets
was to allow you to discover points along the path with wavelength
conversion capabilities as part of signalling. 

Without wavelength conversion you are stuck to a fixed wavelength. What you
need is a cranck back mechanism if you detect that all possible wavelengths
are occupied.
The availabiity of wavelength conversion and the connectivity of a
connection matrix as such is a separate issue from PMD or OSNR.
Note that even in TDM systesm (SONET) you may have limited connectivity.
Some SONET ADMs for example don'tsupport time slot interchange for the
line-line connection. That results in the same connectivity restricitions as
an Optical ADM without wavelength conversion between the line interfaces.
We should separate the issue of wavelength conversion (-> limited
connectivity) and signal impairments.
Wavelength conversion usually has impact on signal parameters, but that can
be modelled as a separate process wich can also exists without wavelength
conversion.
Today wavelength conversion ist mostly based on o-e-o conversin with
re-timing (3-R). The 3-R process resets the otpical signal parameters, but
it influences timing parameters (jitte, wander).
Wavelength conversion based on o-e-o conversion with re-shaping (limiting
amplifier), but without re-timing is also available (2-R). This has
influence on other parameters.
Pure optical wavelength conversion will have other influences. We don't know
exactly which today and it may depend on the specific process used.
Consideration of signal impairments in the routing process is a much more
complex issue compared to limited connectivity if I look on the tools we use
today to design an optical path.

JD:  I think that we might be agreeing with each other;  i.e., impairments
should be handled in routing and wavelength continuity should be handled in
signalling.  

Juergen
 
> -----Original Message-----
> From:	John Drake [SMTP:[email-masked]]
> Sent:	Tuesday, June 26, 2001 11:58 PM
> To:	'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia
> Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:	RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04
> 
> Announcing wavelength availability information in routing doesn't work
> because of the flooding traffic it would generate, plus there are still
race
> conditions that would have to be handled by signalling anyway.  Label set
> was intended to support wavelength continuity issues.  
> 
> Also, in the short term, we're dealing with transponder based interfaces
to
> the DWDM systems so this is a non-issue.  In the longer term, this is just
> another issue like PMD and OSNR that will need to be dealt with.
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:43 AM
> To: 'Yangguang Xu'; Diego Caviglia
> Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject: RE: Optical impairments in
> draft-ietf-mpls-generalized-signaling- 04
> 
> 
> Yangguang,
> 
> wavelength conversion is in my view an issue for path selection as you
> cannot select a certain path if the wavelength doesn't fit and you have
no> 
> wavelength conversion.> 
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From:	Yangguang Xu [SMTP:[email-masked]]
> > Sent:	Tuesday, June 26, 2001 3:13 PM
> > To:	Diego Caviglia
> > Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> > Subject:	Re: Optical impairments in
> draft-ietf-mpls-generalized-signaling-04
> > 
> > 
> > Diego,
> > 
> > As indicated by the document that Ayan pointed to you, there are many
> constrains
> > for the optical networking. These constrains can be considered at
network
> > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
> connection
> > setup time(GMPLS signaling). When a constrain is considered is an
> engineering
> > issue. We just have to figure out when and where is the best and
cheapest
> to
> > consider a constrain. To wavelength conversion, GMPLS signaling is a
good
> place
> > to handle.
> > 
> > Thanks,
> > 
> > Yangguang
> > 
> > Diego Caviglia wrote:
> > > 
> > > Ayan,
> > > 
> > >           Thanks for your answer but I don't understand why lambda
> conversion is
> > > a  signalling  problem and thus is covered in generalized signalling
> draft while
> > > others  optical  impairments  are  routing problem and are covered in
a
> separate
> > > document.
> > > 
> > > Moreover  even  if the document you quoted is a well written and very
> useful one
> > > it  is  an  informative  contribution  that  simply  points  out  the
> physically
> > > impairments  of  an  all  optical  network.  It doesn't propose any
> extension to
> > > OSPF/IS-IS in order to support optical routing.
> > > 
> > > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
> lots of new
> > > information,  as  you  stated  in  your document, are we sure that
OSPF,
> in this
> > > environment, scales?
> > > 
> > > I  mean if it doesn't scale for wavelength availability information
> distribution
> > > why it has to scales for other optical impairment distribution?
> > > 
> > > ----------------------------------------------------------------
> > > Diego Caviglia
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com
> > > 
> > > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> > >           [email-masked], [email-masked]
> > > 
> > >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > > 
> > > 
> > > 
> > >  Subject: RE: Optical impairments in
> > >           draft-ietf-mpls-generalized-signaling-  04
> > > 
> > > 
> > >
>
----------------------------------------------------------------------------
> ----
> > > 
> > > Diego,
> > > 
> > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > > 
> > > Thanks,
> > > Ayan
> > > 
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:19 AM
> > > To: [email-masked]; [email-masked]
> > > Cc: Giovanni Fiaschi
> > > Subject: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
> > > 
> > > Peter ,all,
> > > 
> > >            a  comment  about
draft-ietf-mpls-generalized-signaling-04.
> In
> > > the
> > > draft  there is the label set object that is very useful in All
optical
> > > networks
> > > with  CI-incapable  nodes  but  lambda  conversion  is  only one of
the
> > > problems
> > > related  to  path  establishment  in  such networks.  I mean what
about
> OSNR
> > > and
> > > non-linear  impairments? What about gain variation and power
> equalization?
> > > Where
> > > are covered these topic?
> > > 
> > > If  I  can  find  a  path  feasible from the lambda continuity point
of
> view
> > > who
> > > assure me that I have the needed Q at the end of the all optical path?
> > > 
> > > Best regards.
> > > 
> > > ----------------------------------------------------------------> 
> > > Diego Caviglia> 
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com

Delivery-date: Wed, 27 Jun 2001 08:35:21 -0700
Date: Wed, 27 Jun 2001 11:31:19 -0400
From: Eric Gray <[email-masked]>
To: Common Control and Measurement Protocols - List Manager <[email-masked]>
Cc: Common Control and Measurement Protocols <[email-masked]>
Subject: Question

Hi.

    My understanding of IETF policy is that the mailing lists are
required to be public.  This is necessary in order for someone who
is posting to such a list to be able to determine who might be a
recipient.

    This turns out to be a fair and important requirement based on
recent discussions concerning 'cross-posting'.  I would like to
be able to determine - on my own - whether or not there is in
fact a large cross-section in common between this mailing list
and the mailing list for MPLS.  I would also like to be able to
explicitly detemine who is 'missing' from each list.  This is very
useful when - for example - I discover that I (or someone else)
has inadvertently posted to the wrong list and I do not want to
send duplicate messages.

    Please advise how I am supposed to be able to do this if you
have disabled the 'who' command for this public mailing list?

--
Eric Gray

Delivery-date: Wed, 27 Jun 2001 08:20:42 -0700
From: John Drake <[email-masked]>
To: 'Yangguang Xu' <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 08:15:32 -0700

I'll defer to Peter Ashwood-Smith or Lou Berger, as they were the ones who
designed label sets

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:06 AM
To: John Drake
Cc: [email-masked]
Subject: Re: Optical impairments in
draft-ietf-mpls-generalized-signaling-04

John, 

Can you (or anybody else) give me an example that there are more than one
labels
in the label set for the inclusive case?

Here is a simple picture: A,B,C and D are OXCs

        +---+     +---+    +---+   +---+
   -----| A |-----| B |----| C |---| D |
        |   |-----|   |----|   |---|   |
        |   |-----|   |----|   |---|   |-----
        +---+     +---+    +---+   +---+

In your example, please specify your assumption about each OXC, that is
whether
or not it support wavelength conversion.

Thanks a lot,

Yangguang

John Drake wrote:
> 
> Announcing wavelength availability information in routing doesn't work
> because of the flooding traffic it would generate, plus there are still
race
> conditions that would have to be handled by signalling anyway.  Label set
> was intended to support wavelength continuity issues.
> 
> Also, in the short term, we're dealing with transponder based interfaces
to
> the DWDM systems so this is a non-issue.  In the longer term, this is just
> another issue like PMD and OSNR that will need to be dealt with.
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:43 AM
> To: 'Yangguang Xu'; Diego Caviglia
> Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject: RE: Optical impairments in
> draft-ietf-mpls-generalized-signaling- 04
> 
> Yangguang,
> 
> wavelength conversion is in my view an issue for path selection as you
> cannot select a certain path if the wavelength doesn't fit and you have no
> wavelength conversion.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Yangguang Xu [SMTP:[email-masked]]
> > Sent: Tuesday, June 26, 2001 3:13 PM
> > To:   Diego Caviglia
> > Cc:   Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> > Subject:      Re: Optical impairments in
> draft-ietf-mpls-generalized-signaling-04
> >
> >
> > Diego,
> >
> > As indicated by the document that Ayan pointed to you, there are many
> constrains
> > for the optical networking. These constrains can be considered at
network
> > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
> connection
> > setup time(GMPLS signaling). When a constrain is considered is an
> engineering
> > issue. We just have to figure out when and where is the best and
cheapest
> to
> > consider a constrain. To wavelength conversion, GMPLS signaling is a
good
> place
> > to handle.
> >
> > Thanks,
> >
> > Yangguang
> >
> > Diego Caviglia wrote:
> > >
> > > Ayan,
> > >
> > >           Thanks for your answer but I don't understand why lambda
> conversion is
> > > a  signalling  problem and thus is covered in generalized signalling
> draft while
> > > others  optical  impairments  are  routing problem and are covered in
a
> separate
> > > document.
> > >
> > > Moreover  even  if the document you quoted is a well written and very
> useful one
> > > it  is  an  informative  contribution  that  simply  points  out  the
> physically
> > > impairments  of  an  all  optical  network.  It doesn't propose any
> extension to
> > > OSPF/IS-IS in order to support optical routing.
> > >
> > > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
> lots of new
> > > information,  as  you  stated  in  your document, are we sure that
OSPF,
> in this
> > > environment, scales?
> > >
> > > I  mean if it doesn't scale for wavelength availability information
> distribution
> > > why it has to scales for other optical impairment distribution?
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com
> > >
> > > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> > >           [email-masked], [email-masked]
> > >
> > >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > >
> > >
> > >
> > >  Subject: RE: Optical impairments in
> > >           draft-ietf-mpls-generalized-signaling-  04
> > >
> > >
> > >
>
----------------------------------------------------------------------------
> ----
> > >
> > > Diego,
> > >
> > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > >
> > > Thanks,
> > > Ayan
> > >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:19 AM
> > > To: [email-masked]; [email-masked]
> > > Cc: Giovanni Fiaschi
> > > Subject: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
> > >
> > > Peter ,all,
> > >
> > >            a  comment  about
draft-ietf-mpls-generalized-signaling-04.
> In
> > > the
> > > draft  there is the label set object that is very useful in All
optical
> > > networks
> > > with  CI-incapable  nodes  but  lambda  conversion  is  only one of
the
> > > problems
> > > related  to  path  establishment  in  such networks.  I mean what
about
> OSNR
> > > and
> > > non-linear  impairments? What about gain variation and power
> equalization?
> > > Where
> > > are covered these topic?
> > >
> > > If  I  can  find  a  path  feasible from the lambda continuity point
of
> view
> > > who
> > > assure me that I have the needed Q at the end of the all optical path?
> > >
> > > Best regards.
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia>
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com

Delivery-date: Wed, 27 Jun 2001 08:10:03 -0700
Date: Wed, 27 Jun 2001 11:05:47 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04

John, 

Can you (or anybody else) give me an example that there are more than one labels
in the label set for the inclusive case?

Here is a simple picture: A,B,C and D are OXCs

        +---+     +---+    +---+   +---+
   -----| A |-----| B |----| C |---| D |
        |   |-----|   |----|   |---|   |
        |   |-----|   |----|   |---|   |-----
        +---+     +---+    +---+   +---+

In your example, please specify your assumption about each OXC, that is whether
or not it support wavelength conversion.

Thanks a lot,

Yangguang

John Drake wrote:
> 
> Announcing wavelength availability information in routing doesn't work
> because of the flooding traffic it would generate, plus there are still race
> conditions that would have to be handled by signalling anyway.  Label set
> was intended to support wavelength continuity issues.
> 
> Also, in the short term, we're dealing with transponder based interfaces to
> the DWDM systems so this is a non-issue.  In the longer term, this is just
> another issue like PMD and OSNR that will need to be dealt with.
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:43 AM
> To: 'Yangguang Xu'; Diego Caviglia
> Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject: RE: Optical impairments in
> draft-ietf-mpls-generalized-signaling- 04
> 
> Yangguang,
> 
> wavelength conversion is in my view an issue for path selection as you
> cannot select a certain path if the wavelength doesn't fit and you have no
> wavelength conversion.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Yangguang Xu [SMTP:[email-masked]]
> > Sent: Tuesday, June 26, 2001 3:13 PM
> > To:   Diego Caviglia
> > Cc:   Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> > Subject:      Re: Optical impairments in
> draft-ietf-mpls-generalized-signaling-04
> >
> >
> > Diego,
> >
> > As indicated by the document that Ayan pointed to you, there are many
> constrains
> > for the optical networking. These constrains can be considered at network
> > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
> connection
> > setup time(GMPLS signaling). When a constrain is considered is an
> engineering
> > issue. We just have to figure out when and where is the best and cheapest
> to
> > consider a constrain. To wavelength conversion, GMPLS signaling is a good
> place
> > to handle.
> >
> > Thanks,
> >
> > Yangguang
> >
> > Diego Caviglia wrote:
> > >
> > > Ayan,
> > >
> > >           Thanks for your answer but I don't understand why lambda
> conversion is
> > > a  signalling  problem and thus is covered in generalized signalling
> draft while
> > > others  optical  impairments  are  routing problem and are covered in a
> separate
> > > document.
> > >
> > > Moreover  even  if the document you quoted is a well written and very
> useful one
> > > it  is  an  informative  contribution  that  simply  points  out  the
> physically
> > > impairments  of  an  all  optical  network.  It doesn't propose any
> extension to
> > > OSPF/IS-IS in order to support optical routing.
> > >
> > > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
> lots of new
> > > information,  as  you  stated  in  your document, are we sure that OSPF,
> in this
> > > environment, scales?
> > >
> > > I  mean if it doesn't scale for wavelength availability information
> distribution
> > > why it has to scales for other optical impairment distribution?
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com
> > >
> > > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> > >           [email-masked], [email-masked]
> > >
> > >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > >
> > >
> > >
> > >  Subject: RE: Optical impairments in
> > >           draft-ietf-mpls-generalized-signaling-  04
> > >
> > >
> > >
> ----------------------------------------------------------------------------
> ----
> > >
> > > Diego,
> > >
> > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > >
> > > Thanks,
> > > Ayan
> > >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:19 AM
> > > To: [email-masked]; [email-masked]
> > > Cc: Giovanni Fiaschi
> > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> > >
> > > Peter ,all,
> > >
> > >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
> In
> > > the
> > > draft  there is the label set object that is very useful in All optical
> > > networks
> > > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > > problems
> > > related  to  path  establishment  in  such networks.  I mean what about
> OSNR
> > > and
> > > non-linear  impairments? What about gain variation and power
> equalization?
> > > Where
> > > are covered these topic?
> > >
> > > If  I  can  find  a  path  feasible from the lambda continuity point of
> view
> > > who
> > > assure me that I have the needed Q at the end of the all optical path?
> > >
> > > Best regards.
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia>
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com

Delivery-date: Wed, 27 Jun 2001 02:38:55 -0700
From: "Diego Caviglia" <[email-masked]>
To: John Drake <[email-masked]>
cc: "'Heiles Juergen'" <[email-masked]>, "'Yangguang Xu'" <[email-masked]>, Ayan Banerjee <[email-masked]>, [email-masked], "Giovanni Fiaschi" <[email-masked]>
Date: Wed, 27 Jun 2001 11:27:04 +0200
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04

Hi John,
                   please see my comments in line.

Best regards.

Diego.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

John Drake <[email-masked]> on 26/06/2001 23.57.48

                                                                                

                                                              

 To:      "'Heiles Juergen'" <[email-masked]>, 
          "'Yangguang Xu'" <[email-masked]>, Diego           
          Caviglia/MAIN/MC1@MCMAIN                            
                                                              
 cc:      Ayan Banerjee <[email-masked]>,              
          [email-masked], Giovanni                        
          Fiaschi/MAIN/MC1@MCMAIN                             

                                                              
 Subject: RE: Optical impairments in                          
          draft-ietf-mpls-generalized-signaling-   04         

Announcing wavelength availability information in routing doesn't work
because of the flooding traffic it would generate, plus there are still race
conditions that would have to be handled by signalling anyway.

[dc] John could you please clarify why distribute wavelength availability
 that could be even encoded in only 160 bits per fiber (1 lambda available
0 lambda unavailable) doesn't scale while distribute other link related
information such as those described in OSPF TE extension scales?

Yes I agree that race condition is always a problem when resource information is
distributed in a non-instantaneous way.

But this is also valid for Unreserved Bandwidth sub-TLV in OSPF TE extension.

Label set was intended to support wavelength continuity issues.

Also, in the short term, we're dealing with transponder based interfaces to
the DWDM systems so this is a non-issue.  In the longer term, this is just
another issue like PMD and OSNR that will need to be dealt with.

[dc] I know that at present OXC are bordered with transponder
but in this case what is the purpose of Label set object?
I mean in this scenario (DWDM line terminal always perform OEO conversion)
 from a routing perspective we don't have to worry at all about optical
impairments
we have just to leave them to DWDM network planning engineers.

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 7:43 AM
To: 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Yangguang,

wavelength conversion is in my view an issue for path selection as you
cannot select a certain path if the wavelength doesn't fit and you have no
wavelength conversion.

Regards

Juergen

> -----Original Message-----
> From:   Yangguang Xu [SMTP:[email-masked]]
> Sent:   Tuesday, June 26, 2001 3:13 PM
> To:     Diego Caviglia
> Cc:     Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:     Re: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
>
>
> Diego,
>
> As indicated by the document that Ayan pointed to you, there are many
constrains
> for the optical networking. These constrains can be considered at network
> planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
connection
> setup time(GMPLS signaling). When a constrain is considered is an
engineering
> issue. We just have to figure out when and where is the best and cheapest
to
> consider a constrain. To wavelength conversion, GMPLS signaling is a good
place
> to handle.
>
> Thanks,
>
> Yangguang
>
> Diego Caviglia wrote:
> >
> > Ayan,
> >
> >           Thanks for your answer but I don't understand why lambda
conversion is
> > a  signalling  problem and thus is covered in generalized signalling
draft while
> > others  optical  impairments  are  routing problem and are covered in a
separate
> > document.
> >
> > Moreover  even  if the document you quoted is a well written and very
useful one
> > it  is  an  informative  contribution  that  simply  points  out  the
physically
> > impairments  of  an  all  optical  network.  It doesn't propose any
extension to
> > OSPF/IS-IS in order to support optical routing.
> >
> > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
lots of new
> > information,  as  you  stated  in  your document, are we sure that OSPF,
in this
> > environment, scales?
> >
> > I  mean if it doesn't scale for wavelength availability information
distribution
> > why it has to scales for other optical impairment distribution?
> >
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> >
> > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> >
> >
> >
> >
> >
> >
> >
> >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> >           [email-masked], [email-masked]
> >
> >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> >
> >
> >
> >  Subject: RE: Optical impairments in
> >           draft-ietf-mpls-generalized-signaling-  04
> >
> >
> >
----------------------------------------------------------------------------
----
> >
> > Diego,
> >
> > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> >
> > Thanks,
> > Ayan
> >
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 6:19 AM
> > To: [email-masked]; [email-masked]
> > Cc: Giovanni Fiaschi
> > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> >
> > Peter ,all,
> >
> >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
In
> > the
> > draft  there is the label set object that is very useful in All optical
> > networks
> > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > problems
> > related  to  path  establishment  in  such networks.  I mean what about
OSNR
> > and
> > non-linear  impairments? What about gain variation and power
equalization?
> > Where
> > are covered these topic?
> >
> > If  I  can  find  a  path  feasible from the lambda continuity point of
view
> > who
> > assure me that I have the needed Q at the end of the all optical path?
> >
> > Best regards.
> >
> > ----------------------------------------------------------------
> > Diego Caviglia>
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com

Delivery-date: Wed, 27 Jun 2001 00:19:58 -0700
From: Heiles Juergen <[email-masked]>
To: "'John Drake'" <[email-masked]>, Heiles Juergen <[email-masked]>, "'Yangguang Xu'" <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Ayan Banerjee <[email-masked]>, [email-masked], Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 09:19:00 +0200

John,

wavelength availability and wavelength conversion are two different points in my view.
A optical corss-connect without wavelength conversion can be seen as a connection matrix with limited connectivity (e.g. only connections between inputand output ports with the same lambda are possible), while a corss-connect with wavelength conversion has full connectivity if no other constrains apply. This is a static information that doesn't change over time. It is detected during startup of the network and will not result in flooding traffic. The available connectivity of a connection matrix can be taken into account by the routing.
Wavelength availability is a second issue. If you want to annouce the used and unused wavelengths in real-time you end up with flooding traffic and race conditions, I agree. But this is independent of wavelength conversion availability. A label set helps in my view only if you have wavelength conversion as it allows you to select between different wavelengths. Without wavelength conversion you are stuck to a fixed wavelength. What you need is a cranck back mechanism if you detect that all possible wavelengths are occupied.
The availabiity of wavelength conversion and the connectivity of a connection matrix as such is a separate issue from PMD or OSNR.
Note that even in TDM systesm (SONET) you may have limited connectivity. Some SONET ADMs for example don'tsupport time slot interchange for the line-line connection. That results in the same connectivity restricitions as an Optical ADM without wavelength conversion between the line interfaces.
We should separate the issue of wavelength conversion (-> limited connectivity) and signal impairments.
Wavelength conversion usually has impact on signal parameters, but that can be modelled as a separate process wich can also exists without wavelength conversion.
Today wavelength conversion ist mostly based on o-e-o conversin with re-timing (3-R). The 3-R process resets the otpical signal parameters, but it influences timing parameters (jitte, wander).
Wavelength conversion based on o-e-o conversion with re-shaping (limiting amplifier), but without re-timing is also available (2-R). This has influence on other parameters.
Pure optical wavelength conversion will have other influences. We don't know exactly which today and it may depend on the specific process used.
Consideration of signal impairments in the routing process is a much more complex issue compared to limited connectivity if I look on the tools we use today to design an optical path.

Juergen
 
> -----Original Message-----
> From:	John Drake [SMTP:[email-masked]]
> Sent:	Tuesday, June 26, 2001 11:58 PM
> To:	'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia
> Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:	RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
> 
> Announcing wavelength availability information in routing doesn't work
> because of the flooding traffic it would generate, plus there are still race
> conditions that would have to be handled by signalling anyway.  Label set
> was intended to support wavelength continuity issues.  
> 
> Also, in the short term, we're dealing with transponder based interfaces to
> the DWDM systems so this is a non-issue.  In the longer term, this is just
> another issue like PMD and OSNR that will need to be dealt with.
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:43 AM
> To: 'Yangguang Xu'; Diego Caviglia
> Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject: RE: Optical impairments in
> draft-ietf-mpls-generalized-signaling- 04
> 
> 
> Yangguang,
> 
> wavelength conversion is in my view an issue for path selection as you
> cannot select a certain path if the wavelength doesn't fit and you have no> 
> wavelength conversion.> 
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From:	Yangguang Xu [SMTP:[email-masked]]
> > Sent:	Tuesday, June 26, 2001 3:13 PM
> > To:	Diego Caviglia
> > Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> > Subject:	Re: Optical impairments in
> draft-ietf-mpls-generalized-signaling-04
> > 
> > 
> > Diego,
> > 
> > As indicated by the document that Ayan pointed to you, there are many
> constrains
> > for the optical networking. These constrains can be considered at network
> > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
> connection
> > setup time(GMPLS signaling). When a constrain is considered is an
> engineering
> > issue. We just have to figure out when and where is the best and cheapest
> to
> > consider a constrain. To wavelength conversion, GMPLS signaling is a good
> place
> > to handle.
> > 
> > Thanks,
> > 
> > Yangguang
> > 
> > Diego Caviglia wrote:
> > > 
> > > Ayan,
> > > 
> > >           Thanks for your answer but I don't understand why lambda
> conversion is
> > > a  signalling  problem and thus is covered in generalized signalling
> draft while
> > > others  optical  impairments  are  routing problem and are covered in a
> separate
> > > document.
> > > 
> > > Moreover  even  if the document you quoted is a well written and very
> useful one
> > > it  is  an  informative  contribution  that  simply  points  out  the
> physically
> > > impairments  of  an  all  optical  network.  It doesn't propose any
> extension to
> > > OSPF/IS-IS in order to support optical routing.
> > > 
> > > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
> lots of new
> > > information,  as  you  stated  in  your document, are we sure that OSPF,
> in this
> > > environment, scales?
> > > 
> > > I  mean if it doesn't scale for wavelength availability information
> distribution
> > > why it has to scales for other optical impairment distribution?
> > > 
> > > ----------------------------------------------------------------
> > > Diego Caviglia
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com
> > > 
> > > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> > >           [email-masked], [email-masked]
> > > 
> > >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > > 
> > > 
> > > 
> > >  Subject: RE: Optical impairments in
> > >           draft-ietf-mpls-generalized-signaling-  04
> > > 
> > > 
> > >
> ----------------------------------------------------------------------------
> ----
> > > 
> > > Diego,
> > > 
> > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > > 
> > > Thanks,
> > > Ayan
> > > 
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:19 AM
> > > To: [email-masked]; [email-masked]
> > > Cc: Giovanni Fiaschi
> > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> > > 
> > > Peter ,all,
> > > 
> > >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
> In
> > > the
> > > draft  there is the label set object that is very useful in All optical
> > > networks
> > > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > > problems
> > > related  to  path  establishment  in  such networks.  I mean what about
> OSNR
> > > and
> > > non-linear  impairments? What about gain variation and power
> equalization?
> > > Where
> > > are covered these topic?
> > > 
> > > If  I  can  find  a  path  feasible from the lambda continuity point of
> view
> > > who
> > > assure me that I have the needed Q at the end of the all optical path?
> > > 
> > > Best regards.
> > > 
> > > ----------------------------------------------------------------> 
> > > Diego Caviglia> 
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 20:04:29 -0700
From: "Susumu Yoneda" <[email-masked]>
To: "John Drake" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Yangguang Xu'" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Cc: "Ayan Banerjee" <[email-masked]>, <[email-masked]>, "Giovanni Fiaschi" <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Wed, 27 Jun 2001 12:07:21 +0900

Hi

For a full optical network, as Mr. Drake mentioned, there are some issues to
be resolved, eg. optical 2R/3R, WC, and PMD, etc. However, by use of a
combination between lambda and fiber cable, we can provide a good solution
for a limited size of network. By use of GMPLS, we should only avoid the
case such that more than two defferent sources have the same lambda and are
"wdm"ed to the same fiber cable.

Thank you,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
John Drake
Sent: Wednesday, June 27, 2001 6:58 AM
To: 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling-
04

Announcing wavelength availability information in routing doesn't work
because of the flooding traffic it would generate, plus there are still race
conditions that would have to be handled by signalling anyway.  Label set
was intended to support wavelength continuity issues.

Also, in the short term, we're dealing with transponder based interfaces to
the DWDM systems so this is a non-issue.  In the longer term, this is just
another issue like PMD and OSNR that will need to be dealt with.

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 7:43 AM
To: 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Yangguang,

wavelength conversion is in my view an issue for path selection as you
cannot select a certain path if the wavelength doesn't fit and you have no
wavelength conversion.

Regards

Juergen

> -----Original Message-----
> From:	Yangguang Xu [SMTP:[email-masked]]
> Sent:	Tuesday, June 26, 2001 3:13 PM
> To:	Diego Caviglia
> Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:	Re: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
>
>
> Diego,
>
> As indicated by the document that Ayan pointed to you, there are many
constrains
> for the optical networking. These constrains can be considered at network
> planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
connection
> setup time(GMPLS signaling). When a constrain is considered is an
engineering
> issue. We just have to figure out when and where is the best and cheapest
to
> consider a constrain. To wavelength conversion, GMPLS signaling is a good
place
> to handle.
>
> Thanks,
>
> Yangguang
>
> Diego Caviglia wrote:
> >
> > Ayan,
> >
> >           Thanks for your answer but I don't understand why lambda
conversion is
> > a  signalling  problem and thus is covered in generalized signalling
draft while
> > others  optical  impairments  are  routing problem and are covered in a
separate
> > document.
> >
> > Moreover  even  if the document you quoted is a well written and very
useful one
> > it  is  an  informative  contribution  that  simply  points  out  the
physically
> > impairments  of  an  all  optical  network.  It doesn't propose any
extension to
> > OSPF/IS-IS in order to support optical routing.
> >
> > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
lots of new
> > information,  as  you  stated  in  your document, are we sure that OSPF,
in this
> > environment, scales?
> >
> > I  mean if it doesn't scale for wavelength availability information
distribution
> > why it has to scales for other optical impairment distribution?
> >
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> >
> > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> >
> >
> >
> >
> >
> >
> >
> >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> >           [email-masked], [email-masked]
> >
> >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> >
> >
> >
> >  Subject: RE: Optical impairments in
> >           draft-ietf-mpls-generalized-signaling-  04
> >
> >
> >
----------------------------------------------------------------------------
----
> >
> > Diego,
> >
> > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> >
> > Thanks,
> > Ayan
> >
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 6:19 AM
> > To: [email-masked]; [email-masked]
> > Cc: Giovanni Fiaschi
> > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> >
> > Peter ,all,
> >
> >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
In
> > the
> > draft  there is the label set object that is very useful in All optical
> > networks
> > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > problems
> > related  to  path  establishment  in  such networks.  I mean what about
OSNR
> > and
> > non-linear  impairments? What about gain variation and power
equalization?
> > Where
> > are covered these topic?
> >
> > If  I  can  find  a  path  feasible from the lambda continuity point of
view
> > who
> > assure me that I have the needed Q at the end of the all optical path?
> >
> > Best regards.
> >
> > ----------------------------------------------------------------
> > Diego Caviglia>
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 15:34:14 -0700
From: "Ewart Tempest" <[email-masked]>
To: [email-masked]
Cc: "Sandra Ballarte" <[email-masked]>, "Ewart Tempest" <[email-masked]>, Fong Liaw <[email-masked]>
Subject: Question on Acceptable Label Set Object class number
Date: Tue, 26 Jun 2001 18:32:02 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FE8F.D210AAE0
Content-Type: text/plain;
	charset="iso-8859-1"

> Can anyone enlighten me as to why the Acceptable Label Set Object
> specified in draft-ietf-mpls-generalized-rsvp-te-03 has a class number of
> the form 11bbbbbb as opposed to 10bbbbbb. Specifically, the Acceptable
> Label Set only has relevance between two GMPLS compliant neighbouring
> parties, so what value does propagating this information beyond its local
> significance have, especially given that:
> 
> *	The generator of the ResvErr or PathErr is under no obligation to
> reveal its IP address in the ERROR_SPEC object?
> *	The Acceptable Label Set object does not specify the local
> interfaces to which the labels apply?
> 
> Thanks.
> 
> Ewart
> 
> Ewart Tempest,
> Nortel Networks,
> 1341 Baseline Rd.,
> MS 045/22/E11,
> Ottawa, Ontario, Canada, K2C 0A7
> 
> Tel. 613-768-0610 (ESN 398-0610)
> Fax: 613-765-7610
> Pager: 613-760-5403
> 

------_=_NextPart_001_01C0FE8F.D210AAE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>Question on Acceptable Label Set Object class number</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anyone enlighten me as to why the =
Acceptable Label Set Object specified in =
draft-ietf-mpls-generalized-rsvp-te-03 has a class number of the form =
11bbbbbb as opposed to 10bbbbbb. Specifically, the Acceptable Label Set =
only has relevance between two GMPLS compliant neighbouring parties, so =
what value does propagating this information beyond its local =
significance have, especially given that:</FONT></P>

<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">The generator of the ResvErr or =
PathErr is under no obligation to reveal its IP address in the =
ERROR_SPEC object?</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">The Acceptable Label Set object does =
not specify the local interfaces to which the labels apply?</FONT></LI>
<BR>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ewart</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ewart Tempest,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1341 Baseline Rd.,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MS 045/22/E11,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ottawa, Ontario, Canada, K2C =
0A7</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tel. 613-768-0610 (ESN =
398-0610)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax: 613-765-7610</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Pager: 613-760-5403</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0FE8F.D210AAE0--

Delivery-date: Tue, 26 Jun 2001 15:01:28 -0700
From: John Drake <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, 'Yangguang Xu' <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Ayan Banerjee <[email-masked]>, [email-masked],  Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Tue, 26 Jun 2001 14:57:48 -0700

Announcing wavelength availability information in routing doesn't work
because of the flooding traffic it would generate, plus there are still race
conditions that would have to be handled by signalling anyway.  Label set
was intended to support wavelength continuity issues.  

Also, in the short term, we're dealing with transponder based interfaces to
the DWDM systems so this is a non-issue.  In the longer term, this is just
another issue like PMD and OSNR that will need to be dealt with.

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 7:43 AM
To: 'Yangguang Xu'; Diego Caviglia
Cc: Ayan Banerjee; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Yangguang,

wavelength conversion is in my view an issue for path selection as you
cannot select a certain path if the wavelength doesn't fit and you have no
wavelength conversion.

Regards

Juergen

> -----Original Message-----
> From:	Yangguang Xu [SMTP:[email-masked]]
> Sent:	Tuesday, June 26, 2001 3:13 PM
> To:	Diego Caviglia
> Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:	Re: Optical impairments in
draft-ietf-mpls-generalized-signaling-04
> 
> 
> Diego,
> 
> As indicated by the document that Ayan pointed to you, there are many
constrains
> for the optical networking. These constrains can be considered at network
> planning time, path selection time (routing using OSPF-TE/ISIS-TE) or
connection
> setup time(GMPLS signaling). When a constrain is considered is an
engineering
> issue. We just have to figure out when and where is the best and cheapest
to
> consider a constrain. To wavelength conversion, GMPLS signaling is a good
place
> to handle.
> 
> Thanks,
> 
> Yangguang
> 
> Diego Caviglia wrote:
> > 
> > Ayan,
> > 
> >           Thanks for your answer but I don't understand why lambda
conversion is
> > a  signalling  problem and thus is covered in generalized signalling
draft while
> > others  optical  impairments  are  routing problem and are covered in a
separate
> > document.
> > 
> > Moreover  even  if the document you quoted is a well written and very
useful one
> > it  is  an  informative  contribution  that  simply  points  out  the
physically
> > impairments  of  an  all  optical  network.  It doesn't propose any
extension to
> > OSPF/IS-IS in order to support optical routing.
> > 
> > Given  that  in  an  All  Optical  Network  we  have  to  cope  with
lots of new
> > information,  as  you  stated  in  your document, are we sure that OSPF,
in this
> > environment, scales?
> > 
> > I  mean if it doesn't scale for wavelength availability information
distribution
> > why it has to scales for other optical impairment distribution?
> > 
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> > 
> > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> >           [email-masked], [email-masked]
> > 
> >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > 
> > 
> > 
> >  Subject: RE: Optical impairments in
> >           draft-ietf-mpls-generalized-signaling-  04
> > 
> > 
> >
----------------------------------------------------------------------------
----
> > 
> > Diego,
> > 
> > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > 
> > Thanks,
> > Ayan
> > 
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 6:19 AM
> > To: [email-masked]; [email-masked]
> > Cc: Giovanni Fiaschi
> > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> > 
> > Peter ,all,
> > 
> >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.
In
> > the
> > draft  there is the label set object that is very useful in All optical
> > networks
> > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > problems
> > related  to  path  establishment  in  such networks.  I mean what about
OSNR
> > and
> > non-linear  impairments? What about gain variation and power
equalization?
> > Where
> > are covered these topic?
> > 
> > If  I  can  find  a  path  feasible from the lambda continuity point of
view
> > who
> > assure me that I have the needed Q at the end of the all optical path?
> > 
> > Best regards.
> > 
> > ----------------------------------------------------------------
> > Diego Caviglia> 
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 10:37:33 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt
Date: Tue, 26 Jun 2001 07:02:32 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: New TE LSAs to extend OSPF for Traffic Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-00.txt
	Pages		: 36
	Date		: 25-Jun-01
	
OSPF is a well established link state routing protocol used for 
topology discovery and computing forwarding table based on
shortest-Path criteria. Traffic Engineering extensions (OSPF-TE)
will use criteria different from shortest-path so as to route
traffic around congestion paths and meet varying Service Level
agreements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-srisuresh-ospf-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-srisuresh-ospf-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Delivery-date: Tue, 26 Jun 2001 08:50:36 -0700
From: "Diego Caviglia" <[email-masked]>
To: Yangguang Xu <[email-masked]>
cc: Ayan Banerjee <[email-masked]>, [email-masked], "Giovanni Fiaschi" <[email-masked]>
Date: Tue, 26 Jun 2001 17:01:55 +0200
Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling -04

Yangguang,
                    I  understand  your  point and may be I haven't express well
mine.
I'm thinking about an All Optical network with limited lambda conversion (in the
sense  that not all the PXC are lambda conversion capable) which is too large to
ensure that all potential routes have adequate Q at the end node.
In  this  scenario I must know, in order to plan a route that assures sufficient
Q,  not  only  if  a  node is lambda conversion capable but also in which way it
performs lambda conversion.
I mean if conversion is done by OEO operated by classical transponder I have not
to  worry  about  performance  penalties  (in fact I have 3R regeneration of the
signal) but if it is done in the optical domain (e.g. with Semiconductor Optical
Amplifier) I have to consider the loss introduced by this kind of conversion.

Suppose I have the following network scenario:

A----------B-----//-----C--------D---------E

A  and  E  are source and destination node for a lightpath.  Suppose that due to
optical  impairments I have to regenerate electrically the signal between node C
and  D I choose node C in order to have better Q at the receiver, then at node D
due  to  lambda unavailability I have to do WC but node D is able to do only OEO
conversion so I have two consecutive OEO conversion while just one is necessary.

On  the  other  hand if I have sufficient budget to cover the whole path without
taking  into  account the penalties due to SOA lambda conversion if I do WC with
SOA I risk to degrade too much the signal.

Summarizing  what  I  would  like  to  say  about  WC  is  that  it implies some
considerations on routing:
If I do OEO WC I restart the penalties counting
If I do optical WC I have to add penalties to the routing calculation.

This from my point of view impacts the way I calculate a route.

Thus  lambda  availability and signal degradation calculation must be taken into
account together, either during the routing or the signaling or both.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modeling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Yangguang Xu <[email-masked]> on 26/06/2001 15.13.16

                                                                                

                                                              

 To:      Diego Caviglia/MAIN/MC1@MCMAIN                      
                                                              
 cc:      Ayan Banerjee <[email-masked]>,              
          [email-masked], Giovanni                        
          Fiaschi/MAIN/MC1@MCMAIN                             

                                                              
 Subject: Re: Optical impairments in                          
          draft-ietf-mpls-generalized-signaling-04            

Diego,

As indicated by the document that Ayan pointed to you, there are many constrains
for the optical networking. These constrains can be considered at network
planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection
setup time(GMPLS signaling). When a constrain is considered is an engineering
issue. We just have to figure out when and where is the best and cheapest to
consider a constrain. To wavelength conversion, GMPLS signaling is a good place
to handle.

Thanks,

Yangguang

Diego Caviglia wrote:
>
> Ayan,
>
>           Thanks for your answer but I don't understand why lambda conversion
is
> a  signalling  problem and thus is covered in generalized signalling draft
while
> others  optical  impairments  are  routing problem and are covered in a
separate
> document.
>
> Moreover  even  if the document you quoted is a well written and very useful
one
> it  is  an  informative  contribution  that  simply  points  out  the
physically
> impairments  of  an  all  optical  network.  It doesn't propose any extension
to
> OSPF/IS-IS in order to support optical routing.
>
> Given  that  in  an  All  Optical  Network  we  have  to  cope  with lots of
new
> information,  as  you  stated  in  your document, are we sure that OSPF, in
this
> environment, scales?
>
> I  mean if it doesn't scale for wavelength availability information
distribution
> why it has to scales for other optical impairment distribution?
>
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modelling
> E-mail: [email-masked]
> Tel: +39 (0) 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
>
> Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
>
>
>
>
>
>
>
>  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
>           [email-masked], [email-masked]
>
>  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
>
>
>
>  Subject: RE: Optical impairments in
>           draft-ietf-mpls-generalized-signaling-  04
>
>
>
--------------------------------------------------------------------------------
>
> Diego,
>
> Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
>
> Thanks,
> Ayan
>
> -----Original Message-----
> From: Diego Caviglia [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 6:19 AM
> To: [email-masked]; [email-masked]
> Cc: Giovanni Fiaschi
> Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
>
> Peter ,all,
>
>            a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
> the
> draft  there is the label set object that is very useful in All optical
> networks
> with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> problems
> related  to  path  establishment  in  such networks.  I mean what about OSNR
> and
> non-linear  impairments? What about gain variation and power equalization?
> Where
> are covered these topic?
>
> If  I  can  find  a  path  feasible from the lambda continuity point of view
> who
> assure me that I have the needed Q at the end of the all optical path?
>
> Best regards.
>
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modelling
> E-mail: [email-masked]
> Tel: +39 (0) 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 08:48:58 -0700
From: Ayan Banerjee <[email-masked]>
To: 'Diego Caviglia' <[email-masked]>
Cc: [email-masked], Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Tue, 26 Jun 2001 08:46:35 -0700

Diego,

At the last IETF we did present the following draft : 
draft-banerjee-routing-impairments-00.txt, which proposed 
minimal extensions to the OSPF/ISIS routing protocols. 

It was decided that the IPO group would enhance the draft: 
draft-chiu-strand-unique-olcp-02.txt with the requirements
for all optical routing and only then extensions to the 
routing protocols were to be submitted to the CCAMP WG. 

Thanks,
Ayan

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 2:27 AM
To: Ayan Banerjee
Cc: [email-masked]; [email-masked]; Giovanni Fiaschi
Subject: RE: Optical impairments in
draft-ietf-mpls-generalized-signaling- 04

Ayan,

          Thanks for your answer but I don't understand why lambda
conversion is
a  signalling  problem and thus is covered in generalized signalling draft
while
others  optical  impairments  are  routing problem and are covered in a
separate
document.

Moreover  even  if the document you quoted is a well written and very useful
one
it  is  an  informative  contribution  that  simply  points  out  the
physically
impairments  of  an  all  optical  network.  It doesn't propose any
extension to
OSPF/IS-IS in order to support optical routing.

Given  that  in  an  All  Optical  Network  we  have  to  cope  with lots of
new
information,  as  you  stated  in  your document, are we sure that OSPF, in
this
environment, scales?

I  mean if it doesn't scale for wavelength availability information
distribution
why it has to scales for other optical impairment distribution?

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modelling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02

 

                                                              

 To:      Diego Caviglia/MAIN/MC1@MCMAIN,                     
          [email-masked], [email-masked]       
                                                              
 cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN                    

                                                              
 Subject: RE: Optical impairments in                          
          draft-ietf-mpls-generalized-signaling-  04          

Delivery-date: Tue, 26 Jun 2001 07:57:12 -0700
Date: Tue, 26 Jun 2001 10:56:02 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Heiles Juergen <[email-masked]>
CC: [email-masked]
Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04

Juergen,

I agree with you. However, at the signaling time, "label set" can be a handy
tool if you don't have algorithms that is smart enough to consider the
wavelength conversion. It depends what you have now and what's the cost.

Thanks,

Yangguang

Heiles Juergen wrote:
> 
> Yangguang,
> 
> wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Yangguang Xu [SMTP:[email-masked]]
> > Sent: Tuesday, June 26, 2001 3:13 PM
> > To:   Diego Caviglia
> > Cc:   Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> > Subject:      Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> >
> >
> > Diego,
> >
> > As indicated by the document that Ayan pointed to you, there are many constrains
> > for the optical networking. These constrains can be considered at network
> > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection
> > setup time(GMPLS signaling). When a constrain is considered is an engineering
> > issue. We just have to figure out when and where is the best and cheapest to
> > consider a constrain. To wavelength conversion, GMPLS signaling is a good place
> > to handle.
> >
> > Thanks,
> >
> > Yangguang
> >
> > Diego Caviglia wrote:
> > >
> > > Ayan,
> > >
> > >           Thanks for your answer but I don't understand why lambda conversion is
> > > a  signalling  problem and thus is covered in generalized signalling draft while
> > > others  optical  impairments  are  routing problem and are covered in a separate
> > > document.
> > >
> > > Moreover  even  if the document you quoted is a well written and very useful one
> > > it  is  an  informative  contribution  that  simply  points  out  the physically
> > > impairments  of  an  all  optical  network.  It doesn't propose any extension to
> > > OSPF/IS-IS in order to support optical routing.
> > >
> > > Given  that  in  an  All  Optical  Network  we  have  to  cope  with lots of new
> > > information,  as  you  stated  in  your document, are we sure that OSPF, in this
> > > environment, scales?
> > >
> > > I  mean if it doesn't scale for wavelength availability information distribution
> > > why it has to scales for other optical impairment distribution?
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com
> > >
> > > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> > >           [email-masked], [email-masked]
> > >
> > >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > >
> > >
> > >
> > >  Subject: RE: Optical impairments in
> > >           draft-ietf-mpls-generalized-signaling-  04
> > >
> > >
> > >   --------------------------------------------------------------------------------
> > >
> > > Diego,
> > >
> > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > >
> > > Thanks,
> > > Ayan
> > >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Monday, June 25, 2001 6:19 AM
> > > To: [email-masked]; [email-masked]
> > > Cc: Giovanni Fiaschi
> > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> > >
> > > Peter ,all,
> > >
> > >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
> > > the
> > > draft  there is the label set object that is very useful in All optical
> > > networks
> > > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > > problems
> > > related  to  path  establishment  in  such networks.  I mean what about OSNR
> > > and
> > > non-linear  impairments? What about gain variation and power equalization?
> > > Where
> > > are covered these topic?
> > >
> > > If  I  can  find  a  path  feasible from the lambda continuity point of view
> > > who
> > > assure me that I have the needed Q at the end of the all optical path?
> > >
> > > Best regards.
> > >
> > > ----------------------------------------------------------------
> > > Diego Caviglia>
> > > Photonic Networks Design and Modelling
> > > E-mail: [email-masked]
> > > Tel: +39 (0) 10 6003 808
> > > Via A. Negrone 1A 16153 Genoa (Italy)
> > > http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 07:44:44 -0700
From: Heiles Juergen <[email-masked]>
To: "'Yangguang Xu'" <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Ayan Banerjee <[email-masked]>, [email-masked], Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Tue, 26 Jun 2001 16:43:17 +0200

Yangguang,

wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion.

Regards

Juergen

> -----Original Message-----
> From:	Yangguang Xu [SMTP:[email-masked]]
> Sent:	Tuesday, June 26, 2001 3:13 PM
> To:	Diego Caviglia
> Cc:	Ayan Banerjee; [email-masked]; Giovanni Fiaschi
> Subject:	Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> 
> 
> Diego,
> 
> As indicated by the document that Ayan pointed to you, there are many constrains
> for the optical networking. These constrains can be considered at network
> planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection
> setup time(GMPLS signaling). When a constrain is considered is an engineering
> issue. We just have to figure out when and where is the best and cheapest to
> consider a constrain. To wavelength conversion, GMPLS signaling is a good place
> to handle.
> 
> Thanks,
> 
> Yangguang
> 
> Diego Caviglia wrote:
> > 
> > Ayan,
> > 
> >           Thanks for your answer but I don't understand why lambda conversion is
> > a  signalling  problem and thus is covered in generalized signalling draft while
> > others  optical  impairments  are  routing problem and are covered in a separate
> > document.
> > 
> > Moreover  even  if the document you quoted is a well written and very useful one
> > it  is  an  informative  contribution  that  simply  points  out  the physically
> > impairments  of  an  all  optical  network.  It doesn't propose any extension to
> > OSPF/IS-IS in order to support optical routing.
> > 
> > Given  that  in  an  All  Optical  Network  we  have  to  cope  with lots of new
> > information,  as  you  stated  in  your document, are we sure that OSPF, in this
> > environment, scales?
> > 
> > I  mean if it doesn't scale for wavelength availability information distribution
> > why it has to scales for other optical impairment distribution?
> > 
> > ----------------------------------------------------------------
> > Diego Caviglia
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com
> > 
> > Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
> >           [email-masked], [email-masked]
> > 
> >  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> > 
> > 
> > 
> >  Subject: RE: Optical impairments in
> >           draft-ietf-mpls-generalized-signaling-  04
> > 
> > 
> >   --------------------------------------------------------------------------------
> > 
> > Diego,
> > 
> > Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> > 
> > Thanks,
> > Ayan
> > 
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Monday, June 25, 2001 6:19 AM
> > To: [email-masked]; [email-masked]
> > Cc: Giovanni Fiaschi
> > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> > 
> > Peter ,all,
> > 
> >            a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
> > the
> > draft  there is the label set object that is very useful in All optical
> > networks
> > with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> > problems
> > related  to  path  establishment  in  such networks.  I mean what about OSNR
> > and
> > non-linear  impairments? What about gain variation and power equalization?
> > Where
> > are covered these topic?
> > 
> > If  I  can  find  a  path  feasible from the lambda continuity point of view
> > who
> > assure me that I have the needed Q at the end of the all optical path?
> > 
> > Best regards.
> > 
> > ----------------------------------------------------------------
> > Diego Caviglia> 
> > Photonic Networks Design and Modelling
> > E-mail: [email-masked]
> > Tel: +39 (0) 10 6003 808
> > Via A. Negrone 1A 16153 Genoa (Italy)
> > http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 06:17:24 -0700
Date: Tue, 26 Jun 2001 09:13:16 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Diego Caviglia <[email-masked]>
CC: Ayan Banerjee <[email-masked]>, [email-masked], Giovanni Fiaschi <[email-masked]>
Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04

Diego,

As indicated by the document that Ayan pointed to you, there are many constrains
for the optical networking. These constrains can be considered at network
planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection
setup time(GMPLS signaling). When a constrain is considered is an engineering
issue. We just have to figure out when and where is the best and cheapest to
consider a constrain. To wavelength conversion, GMPLS signaling is a good place
to handle.

Thanks,

Yangguang

Diego Caviglia wrote:
> 
> Ayan,
> 
>           Thanks for your answer but I don't understand why lambda conversion is
> a  signalling  problem and thus is covered in generalized signalling draft while
> others  optical  impairments  are  routing problem and are covered in a separate
> document.
> 
> Moreover  even  if the document you quoted is a well written and very useful one
> it  is  an  informative  contribution  that  simply  points  out  the physically
> impairments  of  an  all  optical  network.  It doesn't propose any extension to
> OSPF/IS-IS in order to support optical routing.
> 
> Given  that  in  an  All  Optical  Network  we  have  to  cope  with lots of new
> information,  as  you  stated  in  your document, are we sure that OSPF, in this
> environment, scales?
> 
> I  mean if it doesn't scale for wavelength availability information distribution
> why it has to scales for other optical impairment distribution?
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modelling
> E-mail: [email-masked]
> Tel: +39 (0) 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com
> 
> Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
> 
> 
> 
> 
> 
> 
> 
>  To:      Diego Caviglia/MAIN/MC1@MCMAIN,
>           [email-masked], [email-masked]
> 
>  cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN
> 
> 
> 
>  Subject: RE: Optical impairments in
>           draft-ietf-mpls-generalized-signaling-  04
> 
> 
>   --------------------------------------------------------------------------------
> 
> Diego,
> 
> Please see draft-ietf-ipo-impairments-00.txt for optical constraints.
> 
> Thanks,
> Ayan
> 
> -----Original Message-----
> From: Diego Caviglia [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 6:19 AM
> To: [email-masked]; [email-masked]
> Cc: Giovanni Fiaschi
> Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04
> 
> Peter ,all,
> 
>            a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
> the
> draft  there is the label set object that is very useful in All optical
> networks
> with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
> problems
> related  to  path  establishment  in  such networks.  I mean what about OSNR
> and
> non-linear  impairments? What about gain variation and power equalization?
> Where
> are covered these topic?
> 
> If  I  can  find  a  path  feasible from the lambda continuity point of view
> who
> assure me that I have the needed Q at the end of the all optical path?
> 
> Best regards.
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Photonic Networks Design and Modelling
> E-mail: [email-masked]
> Tel: +39 (0) 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> http://www.marconi.com

Delivery-date: Tue, 26 Jun 2001 04:10:49 -0700
Date: Tue, 26 Jun 2001 04:08:09 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Subject: RE: Control Channel Doubt
To: "[email-masked]" <[email-masked]>
Cc: [email-masked]

Hi Vishal,

--- Vishal Sharma <[email-masked]> wrote:
> Bert,
> 
> While I understand your concern, I have a question.
> Since both MPLS and CCAMP WGs had issued a joint
> last call on the
> GMPLS drafts, aren't at least the GMPLS-related
> drafts are the subject of both 
> WGs.

Yes, indeed.  Does that justify filling many many
mailboxes with duplicate mails?  I suspect the overlap
between the ccamp and mpls mailing lists is very high
-- more relevantly, I suspect that the number of folks
interested in GMPLS who are *not* subscribed to CCAMP
AND are subscribed to MPLS is close to zero.
Especially after Bert's mail asking to minimize
cross-postings.

Kireeti.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Delivery-date: Tue, 26 Jun 2001 04:03:41 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt
Date: Tue, 26 Jun 2001 07:02:32 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: New TE LSAs to extend OSPF for Traffic Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-00.txt
	Pages		: 36
	Date		: 25-Jun-01
	
OSPF is a well established link state routing protocol used for 
topology discovery and computing forwarding table based on
shortest-Path criteria. Traffic Engineering extensions (OSPF-TE)
will use criteria different from shortest-path so as to route
traffic around congestion paths and meet varying Service Level
agreements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-srisuresh-ospf-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-srisuresh-ospf-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Jun 2001 02:30:10 -0700
From: "Diego Caviglia" <[email-masked]>
To: Ayan Banerjee <[email-masked]>
cc: [email-masked], [email-masked], "Giovanni Fiaschi" <[email-masked]>
Date: Tue, 26 Jun 2001 11:27:16 +0200
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04

--0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Ayan,

          Thanks for your answer but I don't understand why lambda conv=
ersion is
a  signalling  problem and thus is covered in generalized signalling dr=
aft while
others  optical  impairments  are  routing problem and are covered in a=
 separate
document.

Moreover  even  if the document you quoted is a well written and very u=
seful one
it  is  an  informative  contribution  that  simply  points  out  the p=
hysically
impairments  of  an  all  optical  network.  It doesn't propose any ext=
ension to
OSPF/IS-IS in order to support optical routing.

Given  that  in  an  All  Optical  Network  we  have  to  cope  with lo=
ts of new
information,  as  you  stated  in  your document, are we sure that OSPF=
, in this
environment, scales?

I  mean if it doesn't scale for wavelength availability information dis=
tribution
why it has to scales for other optical impairment distribution?

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modelling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Ayan Banerjee <[email-masked]> on 25/06/2001 22.26.02
                                                                       =
        =20
                                                                       =
        =20
                                                                       =
        =20

                                                             =20
                                                             =20
                                                             =20
 To:      Diego Caviglia/MAIN/MC1@MCMAIN,                    =20
          [email-masked], [email-masked]      =20
                                                             =20
 cc:      Giovanni Fiaschi/MAIN/MC1@MCMAIN                   =20
                                                             =20
                                                             =20
                                                             =20
 Subject: RE: Optical impairments in                         =20
          draft-ietf-mpls-generalized-signaling-  04         =20
                                                             =20

=

--0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Diego,

Please see draft-ietf-ipo-impairments-00.txt for optical constraints.

Thanks,
Ayan

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: Monday, June 25, 2001 6:19 AM
To: [email-masked]; [email-masked]
Cc: Giovanni Fiaschi
Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04

Peter ,all,

           a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
the
draft  there is the label set object that is very useful in All optical
networks
with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
problems
related  to  path  establishment  in  such networks.  I mean what about OSNR
and
non-linear  impairments? What about gain variation and power equalization?
Where
are covered these topic?

If  I  can  find  a  path  feasible from the lambda continuity point of view
who
assure me that I have the needed Q at the end of the all optical path?

Best regards.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modelling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

--0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f--

Delivery-date: Mon, 25 Jun 2001 13:30:00 -0700
From: Ayan Banerjee <[email-masked]>
To: 'Diego Caviglia' <[email-masked]>,  [email-masked], [email-masked]
Cc: Giovanni Fiaschi <[email-masked]>
Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04
Date: Mon, 25 Jun 2001 13:26:02 -0700

Diego,

Please see draft-ietf-ipo-impairments-00.txt for optical constraints. 

Thanks,
Ayan

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: Monday, June 25, 2001 6:19 AM
To: [email-masked]; [email-masked]
Cc: Giovanni Fiaschi
Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04

Peter ,all,

           a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In
the
draft  there is the label set object that is very useful in All optical
networks
with  CI-incapable  nodes  but  lambda  conversion  is  only one of the
problems
related  to  path  establishment  in  such networks.  I mean what about OSNR
and
non-linear  impairments? What about gain variation and power equalization?
Where
are covered these topic?

If  I  can  find  a  path  feasible from the lambda continuity point of view
who
assure me that I have the needed Q at the end of the all optical path?

Best regards.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modelling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Delivery-date: Mon, 25 Jun 2001 11:57:26 -0700
To: "Yangguang Xu" <[email-masked]>, "Suresh Katukam" <[email-masked]>
Date: Mon, 25 Jun 2001 11:56:30 -0700
From: "Lyndon Ong" <[email-masked]>
Cc: "Eric Gray" <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Suggested Label Doubt
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Length: 681

Isn't it Label Set that is used rather than Suggested Label
when you want a bidirectional use of the same label value?

At least in the UNI...

Cheers,

L. Ong 
--

On Mon, 25 Jun 2001 11:20:57   Suresh Katukam wrote:
>
>It is completely waste for bidirectional LSPs in TDM networks. In TDM networks,
>the label must be same and current draft (OIF) specifies that the upstream
>lable should be same as Suggested label. It should be really made optional
>so that if an upstream node wants to suggest, then it has freedom to do so.
>
>Thanks,
>Suresh
>
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Delivery-date: Mon, 25 Jun 2001 11:53:05 -0700
Date: Mon, 25 Jun 2001 14:52:37 -0400
From: Eric Gray <[email-masked]>
To: Suresh Katukam <[email-masked]>
Cc: Yangguang Xu <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Suresh,

    I suspect that you're hitting close to the heart of the issue.
It is arguable that suggested label is redundant in the TDM case -
simply because it is intended to be the same.  Clearly this is not
going to be the case in other technologies within the GMPLS scope.
A major objective of GMPLS is to develop common signaling for a
number of technologies.  There is no reason not to include a
suggested label in a label request, even if it is redundant and it
may be needed when it is not redundant.

    The suggested label is optional in all cases.

--
Eric Gray

You wrote:

> Please see my response in line.
> >
> > > > In my understanding, the purpose of "suggested label" is to speed up circuit
> > > > connection procedure by letting the upstream node to specify a label rather than
> > > > following the conventional MPLS signaling procedure that receiving the label in
> > > > the response.
> > > >
> > > > My questions are:
> > > >
> > > > (1) From a protocol design perspective, what's the benefit to suggest something
> > > > that could be declined?
> > >
> > > The benefit is in optimizing the likely.  As you point out below, it is likely
> > > that the suggestion will be accepted, therefore - for the optimization reason
> > > that you mention above (connection speedup) - it makes sense to allow the
> > > 'suggestion'.
> > >
> >
> > The key is that the likely is not likely in optical network.
> >
> > Basically, "suggested label" adds the local negotiation capability.
> > Therotically, it's a good idea. But it's not necessary in the optical network.
>
> It is completely waste for bidirectional LSPs in TDM networks. In TDM networks,
> the label must be same and current draft (OIF) specifies that the upstream
> lable should be same as Suggested label. It should be really made optional
> so that if an upstream node wants to suggest, then it has freedom to do so.
>
> Thanks,
> Suresh

Delivery-date: Mon, 25 Jun 2001 11:23:43 -0700
Date: Mon, 25 Jun 2001 11:20:57 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: Yangguang Xu <[email-masked]>
CC: Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Please see my response in line.
> 
> > > In my understanding, the purpose of "suggested label" is to speed up circuit
> > > connection procedure by letting the upstream node to specify a label rather than
> > > following the conventional MPLS signaling procedure that receiving the label in
> > > the response.
> > >
> > > My questions are:
> > >
> > > (1) From a protocol design perspective, what's the benefit to suggest something
> > > that could be declined?
> >
> > The benefit is in optimizing the likely.  As you point out below, it is likely
> > that the suggestion will be accepted, therefore - for the optimization reason
> > that you mention above (connection speedup) - it makes sense to allow the
> > 'suggestion'.
> >
> 
> The key is that the likely is not likely in optical network.
> 
> Basically, "suggested label" adds the local negotiation capability.
> Therotically, it's a good idea. But it's not necessary in the optical network.

It is completely waste for bidirectional LSPs in TDM networks. In TDM networks,
the label must be same and current draft (OIF) specifies that the upstream
lable should be same as Suggested label. It should be really made optional
so that if an upstream node wants to suggest, then it has freedom to do so.

Thanks,
Suresh

Delivery-date: Mon, 25 Jun 2001 11:23:40 -0700
Date: Mon, 25 Jun 2001 14:20:53 -0400
From: Eric Gray <[email-masked]>
To: Yangguang Xu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Yangguang,

    So, I was sure that this sort of discussion had occurred previously.  It
has.  For example, you and I had an exchange on almost the exact same subject
in March.  See "Question regarding bi-directional connection set up" and later
"Question regarding bi-directional connection set up - And Port-ID in Label
object" threads for details.  Both threads were discussed on both ccamp and
mpls mailing lists, but not all postings appear in both archives.  We SHOULD
strive to avoid repeating arguments.

    Please see responses recursively embedded below.

You wrote:

> Eric,
>
> Please see my response in line.
>
> > > In my understanding, the purpose of "suggested label" is to speed up circuit
> > > connection procedure by letting the upstream node to specify a label rather than
> > > following the conventional MPLS signaling procedure that receiving the label in
> > > the response.
> > >
> > > My questions are:
> > >
> > > (1) From a protocol design perspective, what's the benefit to suggest something
> > > that could be declined?
> >
> > The benefit is in optimizing the likely.  As you point out below, it is likely
> > that the suggestion will be accepted, therefore - for the optimization reason
> > that you mention above (connection speedup) - it makes sense to allow the
> > 'suggestion'.
> >
>
> The key is that the likely is not likely in optical network.

By what definition of optical network?  It is certainly likely in lambda
switching.  Also, the 'G' in "GMPLS" does not stand for "optical".

>
>
> Basically, "suggested label" adds the local negotiation capability.
> (Theoretically), it's a good idea. But it's not necessary in the optical network.

Apparently, some people feel it is a good idea in practice, as  well.

This discussion has been hashed out multiple times before.

>
>
> > >
> > >
> > > (2) Label is of local significance. In optical network, labels are physically
> > > bound, not logically bound. This is different from conventional IP network. This
> > > is also why there is no difference of which node (upstream or downstream) to
> > > choose the label in optical network. (Normally upstream and downstream node
> > > share almost the same knowledge of links that connect them.)
> >
> > This is a presumption, not necessarily guaranteed.
> >
>
> Would you please give me an example that what I said is not true?

Okay.

Local significance - not every switch in an optical domain is necessarily
capable of performing the same kind of "optical switching".  This does not
mean that they cannot interoperate - but it does mean that they may not
interoperate in the way that you expect.  Under these circumstances, the
choice of "label" may have greater than local significance.  Moreover, you
cannot end up lambda switching two light beams of the same color into
a single piece of glass.

Upstream/Downstream indifference of choice - true in optical networks (at
least "Normally"), but not particularly relevant.  One or the other MUST
have the final say and the model to-date has been that the final word is
given by the downstream.  Given that there MAY BE a scenario in which one
or the other has less than complete knowledge, it is necessary to have a
negotiation/arbitration mechanism.

>
>
> Comparing to conventional IP MPLS, many "logical" value become "physical". This
> has many implications to GMPLS.

"All" logical values becoming physical MIGHT have implications on GMPLS.
"Many" absolutely DOES NOT have such implications, since protocols need
to support all interesting cases, not just many.

>
>
> > >
> > >
> > > (3) In optical transport network, a upstream node may decline a label from a
> > > downstream node as a downstream node may decline a "suggested label" from a
> > > upstream node. The rejections are of the same reasons and frequency.
> >
> > True.
> >
> > >
> > >
> > >     Why do we need to make the suggested label's operation so special? and not
> > > necessary.
> >
> > As you have just described, the semantics - as they are now specified
> > - make use of suggested label (from upstream) and distributed label
> > (from downstream) equally in the form of a suggestion.  But, look at how
> > this true: if the upstream peer does not like a label distributed to it, it is
> > required to request a new one (while holding onto the current one) and
> > then release the one it does not want to use.  The analog behavior for
> > a more forceful 'suggested' label woud be for the downstream to issue
> > a new label and then withdraw the requested label.  This behavior is
> > either explicitly disallowed or very much not supported in signaling.
> >
> > Therefore, I would tend to look at the current approach as making the
> > suggested label NOT special.
> >
>
> I don't disagree with your point.
>
> Indeed, you make me believe that "suggested label" may be a good idea for
> conventional MPLS. Although it may add some complications.

Assume that it adds just a jot of complexity, and next to no benefit at all,
and it would not have been worth doing even when doing so would not also
have meant joggling specifications in mature stages.

>
>
> However, for optical network, I just don't see any application that can benefit
> from the current semantics of the "suggested label". Can you give me an example?

Examples have been given before.  I'll not repeat them.

>
>
> > >
> > >
> > > So I propose to change the semantic of the suggested label as such: (1) The
> > > suggested label object/TLV is optional (2) However, if it is presented, it is
> > > treated as the final decision. That is if the downstream node couldn't accept
> > > the "suggested label", a connection rejection is responded.
> > >
> > > I am looking forward to hearing your opinions.
> >
> > I disagree.  For one thing, given the current signaling specifications, what
> > is likely to prevent the upstream from suggesting the exact same label
> > again?
> >
>
> Then, what is likely to prevent the downstream node from distributing the exact
> same label again?

If you read the above carefully, you will note that the upstream requests
a new label while still retaining the old one.  In this case, the downstream
is required to give a different label.

>
>
> Again, because of the change of many concepts from "logical" to "physical", the
> role of upstream and downstream nodes are not different anymore in optical
> network. In this case, it's not a "suggested" label anymore. It's just a
> "distributed" label from upstream.

It sounds to me like you are making observations based on assumptions about
symmetry that are not necessarily true in all forms of "label" switching
that might be supported by GMPLS.  Is this the case?  If so, then these are
not particularly relevant observations.

>
>
> Thanks,
>
> Yangguang

To summarize, one objection raised in earlier discussions on the subject
of merging upstream label and suggested label was that one was a request
while the other was an assertion.  You would now like to address this by
making both assertions.  It seems to me that there are other objections.
It also seems to me that there is very little support to change the status
quo.

I suggest letting the issue drop.

--
Eric Gray

Delivery-date: Mon, 25 Jun 2001 07:36:22 -0700
Date: Mon, 25 Jun 2001 10:35:08 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Eric Gray <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Eric,

Please see my response in line.

> > In my understanding, the purpose of "suggested label" is to speed up circuit
> > connection procedure by letting the upstream node to specify a label rather than
> > following the conventional MPLS signaling procedure that receiving the label in
> > the response.
> >
> > My questions are:
> >
> > (1) From a protocol design perspective, what's the benefit to suggest something
> > that could be declined?
> 
> The benefit is in optimizing the likely.  As you point out below, it is likely
> that the suggestion will be accepted, therefore - for the optimization reason
> that you mention above (connection speedup) - it makes sense to allow the
> 'suggestion'.
> 

The key is that the likely is not likely in optical network. 

Basically, "suggested label" adds the local negotiation capability.
Therotically, it's a good idea. But it's not necessary in the optical network.

> >
> >
> > (2) Label is of local significance. In optical network, labels are physically
> > bound, not logically bound. This is different from conventional IP network. This
> > is also why there is no difference of which node (upstream or downstream) to
> > choose the label in optical network. (Normally upstream and downstream node
> > share almost the same knowledge of links that connect them.)
> 
> This is a presumption, not necessarily guaranteed.
> 

Would you please give me an example that what I said is not true?

Comparing to conventional IP MPLS, many "logical" value become "physical". This
has many implications to GMPLS.

> >
> >
> > (3) In optical transport network, a upstream node may decline a label from a
> > downstream node as a downstream node may decline a "suggested label" from a
> > upstream node. The rejections are of the same reasons and frequency.
> 
> True.
> 
> >
> >
> >     Why do we need to make the suggested label's operation so special? and not
> > necessary.
> 
> As you have just described, the semantics - as they are now specified
> - make use of suggested label (from upstream) and distributed label
> (from downstream) equally in the form of a suggestion.  But, look at how
> this true: if the upstream peer does not like a label distributed to it, it is
> required to request a new one (while holding onto the current one) and
> then release the one it does not want to use.  The analog behavior for
> a more forceful 'suggested' label woud be for the downstream to issue
> a new label and then withdraw the requested label.  This behavior is
> either explicitly disallowed or very much not supported in signaling.
> 
> Therefore, I would tend to look at the current approach as making the
> suggested label NOT special.
> 

I don't disagree with your point.

Indeed, you make me believe that "suggested label" may be a good idea for
conventional MPLS. Although it may add some complications.

However, for optical network, I just don't see any application that can benefit
from the current semantics of the "suggested label". Can you give me an example?

> >
> >
> > So I propose to change the semantic of the suggested label as such: (1) The
> > suggested label object/TLV is optional (2) However, if it is presented, it is
> > treated as the final decision. That is if the downstream node couldn't accept
> > the "suggested label", a connection rejection is responded.
> >
> > I am looking forward to hearing your opinions.
> 
> I disagree.  For one thing, given the current signaling specifications, what
> is likely to prevent the upstream from suggesting the exact same label
> again?
> 

Then, what is likely to prevent the downstream node from distributing the exact
same label again?

Again, because of the change of many concepts from "logical" to "physical", the
role of upstream and downstream nodes are not different anymore in optical
network. In this case, it's not a "suggested" label anymore. It's just a
"distributed" label from upstream.

Thanks,

Yangguang

Delivery-date: Mon, 25 Jun 2001 06:52:23 -0700
Date: Mon, 25 Jun 2001 09:50:47 -0400
From: Eric Gray <[email-masked]>
To: Yangguang Xu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Yangguang,

    Please see comments in line.

You wrote:

> Hello All,
>
> Just want to use this thread to clarify one of my confusions of current GMPLS
> signaling - "suggested label".
>
> In my understanding, the purpose of "suggested label" is to speed up circuit
> connection procedure by letting the upstream node to specify a label rather than
> following the conventional MPLS signaling procedure that receiving the label in
> the response.
>
> My questions are:
>
> (1) From a protocol design perspective, what's the benefit to suggest something
> that could be declined?

The benefit is in optimizing the likely.  As you point out below, it is likely
that the suggestion will be accepted, therefore - for the optimization reason
that you mention above (connection speedup) - it makes sense to allow the
'suggestion'.

>
>
> (2) Label is of local significance. In optical network, labels are physically
> bound, not logically bound. This is different from conventional IP network. This
> is also why there is no difference of which node (upstream or downstream) to
> choose the label in optical network. (Normally upstream and downstream node
> share almost the same knowledge of links that connect them.)

This is a presumption, not necessarily guaranteed.

>
>
> (3) In optical transport network, a upstream node may decline a label from a
> downstream node as a downstream node may decline a "suggested label" from a
> upstream node. The rejections are of the same reasons and frequency.

True.

>
>
>     Why do we need to make the suggested label's operation so special? and not
> necessary.

As you have just described, the semantics - as they are now specified
- make use of suggested label (from upstream) and distributed label
(from downstream) equally in the form of a suggestion.  But, look at how
this true: if the upstream peer does not like a label distributed to it, it is
required to request a new one (while holding onto the current one) and
then release the one it does not want to use.  The analog behavior for
a more forceful 'suggested' label woud be for the downstream to issue
a new label and then withdraw the requested label.  This behavior is
either explicitly disallowed or very much not supported in signaling.

Therefore, I would tend to look at the current approach as making the
suggested label NOT special.

>
>
> So I propose to change the semantic of the suggested label as such: (1) The
> suggested label object/TLV is optional (2) However, if it is presented, it is
> treated as the final decision. That is if the downstream node couldn't accept
> the "suggested label", a connection rejection is responded.
>
> I am looking forward to hearing your opinions.

I disagree.  For one thing, given the current signaling specifications, what
is likely to prevent the upstream from suggesting the exact same label
again?

>
>
> Regards,
>
> Yangguang

--
Eric Gray

Delivery-date: Mon, 25 Jun 2001 06:24:14 -0700
From: "Yuri Landry" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: How about other extensions to GMPLS?
Date: Mon, 25 Jun 2001 13:23:16 -0000

Hi,

Some recent emails mentioned the OIF UNI document. I went through it and saw 
some new objects defined.

I am not going to discuss OIF works here. But I have questions to ADs and WG 
Chairs about IETF GMPLS drafts. Should IETF GMPLS be the umbrella for all 
such related work? Current GMPLS signaling covers objects extensions. I am 
sure there will be more and more objects defined later when new applications 
being identified. These objects may be generalized and not technology 
specific as SONET/SDH and OTN. So shall we add them to the current GMPLS 
drafts?

Regards,

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

Delivery-date: Mon, 25 Jun 2001 06:23:12 -0700
From: "Diego Caviglia" <[email-masked]>
To: [email-masked], [email-masked]
cc: "Giovanni Fiaschi" <[email-masked]>
Date: Mon, 25 Jun 2001 15:18:30 +0200
Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04

Peter ,all,

           a  comment  about  draft-ietf-mpls-generalized-signaling-04.  In  the
draft  there is the label set object that is very useful in All optical networks
with  CI-incapable  nodes  but  lambda  conversion  is  only one of the problems
related  to  path  establishment  in  such networks.  I mean what about OSNR and
non-linear  impairments? What about gain variation and power equalization? Where
are covered these topic?

If  I  can  find  a  path  feasible from the lambda continuity point of view who
assure me that I have the needed Q at the end of the all optical path?

Best regards.

----------------------------------------------------------------
Diego Caviglia
Photonic Networks Design and Modelling
E-mail: [email-masked]
Tel: +39 (0) 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
http://www.marconi.com

Delivery-date: Sun, 24 Jun 2001 12:54:08 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]" <[email-masked]>, manoj juneja <[email-masked]>
Subject: RE: Control Channel Doubt
Date: Sun, 24 Jun 2001 12:54:32 -0700

Bert,

While I understand your concern, I have a question.
Since both MPLS and CCAMP WGs had issued a joint last call on the
GMPLS drafts, aren't at least the GMPLS-related drafts are the subject of both 
WGs.

Thanks,
-Vishal
On Friday, June 22, 2001 3:05 PM, Wijnen, Bert (Bert) [SMTP:[email-masked]] 
wrote:
> GMPLS related discussion is CCAMP
>
> Bert
>
> > ----------
> > From: 	manoj juneja[SMTP:[email-masked]]
> > Sent: 	Friday, June 22, 2001 11:36 PM
> > To: 	[email-masked]; [email-masked]; [email-masked]
> > Subject: 	Re: Control Channel Doubt
> >
> > Eric,
> >        U are absolutely on track. This is what I was about to post. In
> > response to my query, some people are copying the response on ccamp and
> > some on mpls mailing list. Please clarify the procedure. I think we
> > should have one mailing list. By keeping more mailing lists, we
> > are confusing the people. Also, there is no clear demarcation of
> > activities in WGs. Either we should shift whole GMPLS related stuff on
> > ccamp mailing list otherwise we have to suffer these minor things.
> >
> > Regards,
> > manoj.
> >
> >
> >
> >
> > >From: Eric Gray <[email-masked]>
> > >To: "Wijnen, Bert (Bert)" <[email-masked]>
> > >CC: ccamp-wg <[email-masked]>, manoj juneja
> > ><[email-masked]>
> > >Subject: Re: Control Channel Doubt
> > >Date: Fri, 22 Jun 2001 17:12:10 -0400
> > >
> > >Bert,
> > >
> > >     What would be the general procedure you would recommend for
> > >a person wishing to post a question that applies to multiple groups?
> > >What approach do you recommend they use to determine in advance
> > >whether or not there is a largely overlapping audience?
> > >
> > >--
> > >Eric Gray
> > >
> > >You wrote:
> > >
> > > > Please DO NOT cross post to multiple mailing lists with largely
> > > > overlapping audiences. Choose one list and discuss it there.
> > > >
> > > > Thanks, Bert
> > > >
> > > > > ---
> > >
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> > 

Delivery-date: Sun, 24 Jun 2001 08:56:42 -0700
Date: Sun, 24 Jun 2001 11:53:16 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: Suggested Label Doubt

Hello All,

Just want to use this thread to clarify one of my confusions of current GMPLS
signaling - "suggested label".

In my understanding, the purpose of "suggested label" is to speed up circuit
connection procedure by letting the upstream node to specify a label rather than
following the conventional MPLS signaling procedure that receiving the label in
the response.

My questions are:

(1) From a protocol design perspective, what's the benefit to suggest something
that could be declined?

(2) Label is of local significance. In optical network, labels are physically
bound, not logically bound. This is different from conventional IP network. This
is also why there is no difference of which node (upstream or downstream) to
choose the label in optical network. (Normally upstream and downstream node
share almost the same knowledge of links that connect them.)

(3) In optical transport network, a upstream node may decline a label from a
downstream node as a downstream node may decline a "suggested label" from a
upstream node. The rejections are of the same reasons and frequency.

    Why do we need to make the suggested label's operation so special? and not
necessary.

So I propose to change the semantic of the suggested label as such: (1) The
suggested label object/TLV is optional (2) However, if it is presented, it is
treated as the final decision. That is if the downstream node couldn't accept
the "suggested label", a connection rejection is responded.

I am looking forward to hearing your opinions.

Regards,

Yangguang

Delivery-date: Sun, 24 Jun 2001 02:42:12 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Diversity of Routes Doubt
Date: Sun, 24 Jun 2001 10:27:39 +0100

3 observations:

1	It difficult to understand the need for diversity and SVC-like
connections......diversity becomes an increasingly important factor as trail
holding time increases.  So diversity is something important for
permanent/semi-permanent trails set under the management-plane or, in a
management proxy-type mode, by the control-plane (S-PVC-like).

2	All client layers inherit their connectivity from the duct
network....so a knowledge of the topology of the duct network is essential
to ensure diversity in a client network.  However, no operator will own all
the layers 'to the duct' globally......so peering via exterior-NNIs will be
essential.  This means that there will be no visibility of the duct topology
(nor allowed control of L1 resources) outside of a single domain.  Hence,
the ability to calculate/force a strict source explicit route (or routes for
diversity) across inter-oprerator boundaries will in general not be
possible.

3	Item 2 above will impact other issues related to resilience.  For
example, even assuming one believes pre-emption will yield any
tangible/deterministic benefit within a single domain it is hard to see how
this concept could be extended across exterior-NNIs.
 
Neil

> -----Original Message-----
> From: Fong Liaw [mailto:[email-masked]]
> Sent: 23 June 2001 01:25
> To: 'manoj juneja'; [email-masked]
> Subject: RE: Diversity of Routes Doubt
> 
> 
> Manoj
> 
> I am not sure CCAMP is the right email list to discuss
> OIF UNI specific attributes/object. I will respond here, 
> but we can take it off-line or to [email-masked] 
> if needed.
> 
> >  -----Original Message-----
> >  From: manoj juneja [mailto:[email-masked]]
> >  Sent: Friday, June 22, 2001 4:43 PM
> >  To: [email-masked]
> >  Subject: Diversity of Routes Doubt
> >  
> >  
> >  Hi All,
> >            The OIF-UNI draft contains diversity sub-object (part of
> >  Generalized UNI Attribute object). There is no such object in GMPLS
> >  drafts. In a typical scenario, where one O-UNI request has to be
> >  converted/translated/mapped to one GMPLS (NNI) request, how to
> >  interpret/translate the diversity TLV/object ?
> 
> The UNI diversity subobject includes a connection identifier and
> the diversity requirement, e.g. node, link, etc.  The first
> switch (ONE) should use the connection identifier to find out 
> the path (links and nodes) of the identified connection and 
> then use it to compute ERO that would diverse from the nodes,
> links, or SRLG.
> 
> >  Is it the responsibility of network manager to offline 
> calculate the
> >  ERO (and pass in the path message from the edge/ingress ONE) which
> >  statisfies the diverstiy of the route desired by the client
> 
> I don't think this can be done offline, since it changes
> according to which connection you want to diversify from.
> But it can be done by either centralized or distributed 
> computation, and precomputation might be possible.
> 
> >  equipment ? Does this mean the usage of strict routes in ERO ?
> >  Should we be having the diversity object in GMPLS drafts also ?
> 
> Use of strict route in ERO is probably the simplest and common
> approach in single domain. Using loose route ERO is possible
> but could be more complicate. This may come into GMPLS/OIF NNI 
> if diversity across multiple domain becomes a requirement. 
> We don't have this requirement yet, so there is no need to introduce 
> it into GMPLS yet.
> 
> Regards,
> -Fong
> 
> >  
> >  Please clarify my doubt.
> >  
> >  Regards,
> >  manoj.
> >  
> >  
> >  _________________________________________________________________
> >  Get your FREE download of MSN Explorer at http://explorer.msn.com
> >  
> >  
> 

Delivery-date: Fri, 22 Jun 2001 19:44:30 -0700
Cc: [email-masked]
Date: Sat, 23 Jun 2001 04:43:35 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt

This is a multi-part message in MIME format.
--------------07B35EC38897359B71009661
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

manoj juneja wrote:
> 
> Marteen,
>          Agreed, As per G.707, STM-64 consist of 64 VC-4 signals. I
> have one doubt here.  I want to discuss two cases in where two signals
> viz. VC-4-3c (contiguously concatenated signals) and VC-4-3v (virtually
> concatenated signals) have to be allocated to satisfy the two Label
> Request/Path messages.

Let's use a defined contiguous concatenated signal instead of the
undefined VC-4-3c; i.e. let's make the example with VC-4-4c and VC-4-4v.

> In case of VC-4-3c, do I have to allocate the contiguous VC-4s (viz.
> say 4th, 5th and 6th and not 10th, 20th and 30th) ? 

Contiguous concatenation implies per G.707 the use of X contiguous
timeslots to transport a VC-4-Xc. For the case of VC-4 these timeslots
are really contiguous. Which timeslots to use for a VC-4-Xc
(X=4,16,64,256) is defined in section 7/G.707 (10/2000). Subsection
7.3.2.3/G.707 specifies explictly the columns to use for the case of a
VC-4-4c in a STM-64. E.g. for the case the VC-4-4c is transported via
address (1,2,0,0), columns 5, 6, 7 and 8 of the STM-64 are the first 4
columns in which the VC-4-4c (1,2,0,0) is transported. The rest of this
VC-4-4c (1,2,0,0) is transported in groups of 4 contiguous columns
interspaced by 60 columns.

Please be aware that for the case of a STS-Xc, groups of X/3 columns are
contiguous in time. E.g. for the case of a STS-3c at (1,2,4,0) the first
column is STM-64 column 8, the 2nd column is column 72 and the 3rd
column is column 136.

> If I allocate the
> contiguous signal, does this mean in this case I have to pass only one
> label corresponding to the multiplexing position of 4th VC-4 (Lowest
> one) and other VC-4s will be derived by the receiving end from the
> lowest signal.

You have to pass the position of the 1st time slot which is occupied by
the VC-4-4c signal. In the case of the example this is number 5.

> 
> In case of contiguous concatenation, Can the contiguous VC-4 signals
> span the AUG-Xc in STM-N [ like STM-64 consist of AUG-64. Say it
> consist of 4 VC-4-16c.

An AUG-Xc doesn't exist. A VC-4-Xc (X=4,16,64,256) fits exactly the
AUG-X. E.g. in a STM-64 there is one AUG-64. This AUG-64 can contain
either one AU-4-64c, or four AUG-16's. Each of the AUG-16's can contain
either one AU-4-16c, or four AUG-4's. Each AUG-4 can contain either one
AU-4-4c or four AUG-1's. Each AUG-1 can contain either one AU-4 or three
AU-3's.

A VC-4-16c is transported via a AU-4-16c. Within a STM-64, VC-4-16c
signals can be transported via addresses (1,0,0,0), (2,0,0,0), (3,0,0,0)
or (4,0,0,0). Refer to section 7.3.2.4/G.707.

> If I have to allocate 20 VC-4s in contiguous
> concatenation, can I span VC-4s allocation across the AU-4-16cs  ?

Contiguous concatenation defined in G.707 doesn't support VC-4-20c. This
would only be supported by the proprieraty arbitrary concatenation. In
this case the VC-4-20c will be transported in a AU-4-20c.

> 
> In case of virtual concatenation, Can I allocate non-contiguous signals
> (viz. 10th, 20th, 30th) ? 

Virtual concatenation (e.g. VC-4-4v) as defined by G.707 allows you to
transport the four VC-4 signals via either one STM-N signal, or via two
STM-N signals, or via three STM-N singals or via four STM-N signals. 

For the case more than one (e.g. Y) of the X VC-4 signals in the VC-4-Xv
signal is transported via the same STM-N signal, Y arbitrary selected
AU-4 timeslots can be used; i.e. those timeslots may be contiguous or
non-contiguous.

GMPLS doesn't support this G.707 feature completely. GMPLS adds the
restriction that all X VC-4 signals within the VC-4-Xv must be
transported via the same STM-N signal. :-(
Essentially, GMPLS is not suited to setup a VC-4-Xv; VC-4-Xv signals
have to be setup via the management plane due to this restriction.

> In this case I have to pass 3 labels
> corresponding to each VC-4 position in the multiplexing hierarchy.

For a VC-4-3v you have to pass a generalised label including 3 labels in
the label field.

> Does this hold true for arbitrary concatenation also ?

Arbitrary contiguous concatenation is an extension of contiguous
concatenation, allowing X to be any value in the range 1 to N. It has
the same characteristics as contiguous concatenation, i.e. contiguous
timeslots are used. As such, only one label has to be transmitted in the
label field.

Regards,

Maarten

> 
> Please clarify.
> 
> Regards,
> manoj.
> 
> >From: Maarten Vissers <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked], [email-masked]
> >Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
> >Date: Wed, 20 Jun 2001 03:46:04 +0200
> >
> >Manoj,
> >
> >A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64
> >VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of
> >VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer
> >to G.707).
> >
> >A VC-4-16c signal can be transported in either one of the four AU-4-16c
> >tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to
> >7.2.3.4/G.707.
> >
> >Regards,
> >
> >Maarten
> >
> >manoj juneja wrote:
> > >
> > > Hi Eric,
> > >           Thanks for the reply. I have one more doubt :
> > >
> > > A STM-64 interface consist of 64 STM-1s that are byte interleaved. If
> > > I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT
> > > with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0,
> > > MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to
> > > allocate contiguous VC-4s in STM-64 link.
> > > Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link.
> > > Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal)
> > > i.e. only one label will be passed in RESV/Label Mapping message. The
> > > receiving node will drive the subsequent labels from this onwards.
> > >
> > > In case of arbitrary or virtual concatenation, Can I allocate non
> > > -contiguous signals from a link ? The label corresponding to each
> > > arbitrary or virtually concatenated signal will be passed in
> > > RESV/Mapping message.
> > >
> > > If I have a STM-64 interface configured, and no signal is allocated yet
> >from
> > > the link.
> > > If I have to allocate a signal STM-3c-7v (virtual concatenation of 7
> > > STM-3c), Can I allocate the whole signal from this link ?
> > >
> > > Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have
> >to
> > > pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0},
> > > {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ].
> > >
> > > Does this mean that each STS-3c in STM-3c-7v should be contiguous ?
> > >
> > > Please tell me if my understanding is correct.
> > >
> > > Regards,
> > > manoj.
> > >
> > > Regards,
> > > manoj.
> > >
> > > >From: "Mannie, Eric" <[email-masked]>
> > > >To: 'manoj juneja' <[email-masked]>, [email-masked]
> > > >Subject: RE: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
> > > >Date: Tue, 19 Jun 2001 10:02:56 +0200
> > > >
> > > >Hello Manoj,
> > > >
> > > >The virtual concatenation is indicated in a separate field (NVC). The
> > > >reason
> > > >is to allow to code the virtual concatenation of contiguously
> >concatenated
> > > >signals (like the virtual concatenation of several STS-3c's.
> > > >
> > > >Kind regards,
> > > >
> > > >Eric
> > > >
> > > >-----Original Message-----
> > > >From: manoj juneja [mailto:[email-masked]]
> > > >Sent: Tuesday, June 19, 2001 3:03 AM
> > > >To: [email-masked]
> > > >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
> > > >
> > > >
> > > >Hi,
> > > >
> > > >      I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :
> > > >
> > > >   The CCT field can have values no concatenation, standard
> > > >concatenation, arbitrary, vendor specific.
> > > >But why can't virtual concatenation ? It was there in original draft.
> > > >But in the exmaples section for SDH/SONET signals, it is shown that a
> > > >virtually concatenated signal can be built using NVC field with CCT
> > > >value as 0. Please clarify the reason in doing so.
> > > >
> > > >Regards,
> > > >manoj.
> > > >
> > > >_________________________________________________________________
> > > >Get your FREE download of MSN Explorer at http://explorer.msn.com
> > > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> ><< mvissers.vcf >>
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------07B35EC38897359B71009661
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------07B35EC38897359B71009661--

Delivery-date: Fri, 22 Jun 2001 18:26:36 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Suggested Label Doubt
Date: Fri, 22 Jun 2001 18:27:24 -0700

Manoj,

The answer to your question is "Yes."

The reason is, the the purpose of the label set is to request subsequent nodes 
to
pick wavlengths from the set specified in the label set (for example, nodes may 
have
a limited wavelength translation capability, restricting them to certain 
wavelengths), since
previous nodes would have done so.

If, however, the setup request crosses a fully wavelength translation capable 
node,
that node could drop the label set. (Note, however, that if the node 
immediately following
this one has restrictions, that node could again introduce a new/different 
label set.)

-Vishal
On Friday, June 22, 2001 6:02 PM, manoj juneja 
[SMTP:[email-masked]] wrote:
> Vishal,
>
>              As u mentioned, that label set may get restricted in
> transit, but can the label set be completely dropped out at some
> transit node ? I mean to say if u reach at a node (transit node) which
> is capable of wavelength conversion (say any LAMBDA m to LAMBDA n i.e.
> any to any capability), Can this node drop the label set ?
>
> Regards,
> manoj.
>
>
>
>
> >From: Vishal Sharma <[email-masked]>
> >Reply-To: "[email-masked]" <[email-masked]>
> >To: "'manoj juneja'" <[email-masked]>,
> >"[email-masked]"  <[email-masked]>
> >Subject: RE: Suggested Label Doubt
> >Date: Fri, 22 Jun 2001 17:35:23 -0700
> >
> >Manoj,
> >
> >You think correctly. A label, by definition, has local significance
> >(between
> >adjacent
> >MPLS nodes).
> >
> >That the suggested label and  label set may have significance beyond a
> >single
> >MPLS hop is simply because the nodes choose to assert the same value for
> >subsequent hops as well.
> >And yes, technically both the suggested label and the label set may change
> >at each hop.
> >(For example, consider an optical network with no wavelength conversion
> >capability.
> >  A label set that represents the wavelengths that can be allocated [say,
> >lambda1 through lamba6] may, for example,
> >become more restricted as the request advances, since subsequent nodes may
> >not
> >have all of these
> >wavelengths available [only lambda2 and lambda4 may be available beyond
> >some
> >node for instance]).
> >
> >-Vishal
> >
> >On Friday, June 22, 2001 5:13 PM, manoj juneja
> >[SMTP:[email-masked]] wrote:
> > > Hi All,
> > >           Can Suggested Label change hop-by-hop (or even dropped at
> > > some transit node) like Label set may change hop-by-hop (or even
> > > dropped at some transit node) ? I think both should have a link by link
> > > significance as in case of label.
> > >
> > > Please clarify.
> > >
> > > Regards,
> > > manoj.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 22 Jun 2001 18:03:21 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Suggested Label Doubt
Date: Fri, 22 Jun 2001 18:02:10 -0700

Vishal,

             As u mentioned, that label set may get restricted in
transit, but can the label set be completely dropped out at some
transit node ? I mean to say if u reach at a node (transit node) which
is capable of wavelength conversion (say any LAMBDA m to LAMBDA n i.e.
any to any capability), Can this node drop the label set ?

Regards,
manoj.

>From: Vishal Sharma <[email-masked]>
>Reply-To: "[email-masked]" <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>,        
>"[email-masked]"  <[email-masked]>
>Subject: RE: Suggested Label Doubt
>Date: Fri, 22 Jun 2001 17:35:23 -0700
>
>Manoj,
>
>You think correctly. A label, by definition, has local significance 
>(between
>adjacent
>MPLS nodes).
>
>That the suggested label and  label set may have significance beyond a 
>single
>MPLS hop is simply because the nodes choose to assert the same value for
>subsequent hops as well.
>And yes, technically both the suggested label and the label set may change
>at each hop.
>(For example, consider an optical network with no wavelength conversion
>capability.
>  A label set that represents the wavelengths that can be allocated [say,
>lambda1 through lamba6] may, for example,
>become more restricted as the request advances, since subsequent nodes may 
>not
>have all of these
>wavelengths available [only lambda2 and lambda4 may be available beyond 
>some
>node for instance]).
>
>-Vishal
>
>On Friday, June 22, 2001 5:13 PM, manoj juneja
>[SMTP:[email-masked]] wrote:
> > Hi All,
> >           Can Suggested Label change hop-by-hop (or even dropped at
> > some transit node) like Label set may change hop-by-hop (or even
> > dropped at some transit node) ? I think both should have a link by link
> > significance as in case of label.
> >
> > Please clarify.
> >
> > Regards,
> > manoj.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
>

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

Delivery-date: Fri, 22 Jun 2001 17:32:49 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Suggested Label Doubt
Date: Fri, 22 Jun 2001 17:35:23 -0700

Manoj,

You think correctly. A label, by definition, has local significance (between 
adjacent
MPLS nodes).

That the suggested label and  label set may have significance beyond a single
MPLS hop is simply because the nodes choose to assert the same value for
subsequent hops as well.
And yes, technically both the suggested label and the label set may change
at each hop.
(For example, consider an optical network with no wavelength conversion 
capability.
 A label set that represents the wavelengths that can be allocated [say, 
lambda1 through lamba6] may, for example,
become more restricted as the request advances, since subsequent nodes may not 
have all of these
wavelengths available [only lambda2 and lambda4 may be available beyond some 
node for instance]).

-Vishal

On Friday, June 22, 2001 5:13 PM, manoj juneja 
[SMTP:[email-masked]] wrote:
> Hi All,
>           Can Suggested Label change hop-by-hop (or even dropped at
> some transit node) like Label set may change hop-by-hop (or even
> dropped at some transit node) ? I think both should have a link by link
> significance as in case of label.
>
> Please clarify.
>
> Regards,
> manoj.
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 22 Jun 2001 17:25:15 -0700
From: Fong Liaw <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Diversity of Routes Doubt
Date: Fri, 22 Jun 2001 17:24:30 -0700

Manoj

I am not sure CCAMP is the right email list to discuss
OIF UNI specific attributes/object. I will respond here, 
but we can take it off-line or to [email-masked] 
if needed.

>  -----Original Message-----
>  From: manoj juneja [mailto:[email-masked]]
>  Sent: Friday, June 22, 2001 4:43 PM
>  To: [email-masked]
>  Subject: Diversity of Routes Doubt
>  
>  
>  Hi All,
>            The OIF-UNI draft contains diversity sub-object (part of
>  Generalized UNI Attribute object). There is no such object in GMPLS
>  drafts. In a typical scenario, where one O-UNI request has to be
>  converted/translated/mapped to one GMPLS (NNI) request, how to
>  interpret/translate the diversity TLV/object ?

The UNI diversity subobject includes a connection identifier and
the diversity requirement, e.g. node, link, etc.  The first
switch (ONE) should use the connection identifier to find out 
the path (links and nodes) of the identified connection and 
then use it to compute ERO that would diverse from the nodes,
links, or SRLG.

>  Is it the responsibility of network manager to offline calculate the
>  ERO (and pass in the path message from the edge/ingress ONE) which
>  statisfies the diverstiy of the route desired by the client

I don't think this can be done offline, since it changes
according to which connection you want to diversify from.
But it can be done by either centralized or distributed 
computation, and precomputation might be possible.

>  equipment ? Does this mean the usage of strict routes in ERO ?
>  Should we be having the diversity object in GMPLS drafts also ?

Use of strict route in ERO is probably the simplest and common
approach in single domain. Using loose route ERO is possible
but could be more complicate. This may come into GMPLS/OIF NNI 
if diversity across multiple domain becomes a requirement. 
We don't have this requirement yet, so there is no need to introduce 
it into GMPLS yet.

Regards,
-Fong

>  
>  Please clarify my doubt.
>  
>  Regards,
>  manoj.
>  
>  
>  _________________________________________________________________
>  Get your FREE download of MSN Explorer at http://explorer.msn.com
>  
>  

Delivery-date: Fri, 22 Jun 2001 17:13:23 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Suggested Label Doubt
Date: Fri, 22 Jun 2001 17:12:36 -0700

Hi All,
          Can Suggested Label change hop-by-hop (or even dropped at
some transit node) like Label set may change hop-by-hop (or even
dropped at some transit node) ? I think both should have a link by link
significance as in case of label.

Please clarify.

Regards,
manoj.

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

Delivery-date: Fri, 22 Jun 2001 17:03:24 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
Date: Fri, 22 Jun 2001 17:02:37 -0700

Marteen,
         Agreed, As per G.707, STM-64 consist of 64 VC-4 signals. I
have one doubt here.  I want to discuss two cases in where two signals
viz. VC-4-3c (contiguously concatenated signals) and VC-4-3v (virtually
concatenated signals) have to be allocated to satisfy the two Label
Request/Path messages.
In case of VC-4-3c, do I have to allocate the contiguous VC-4s (viz.
say 4th, 5th and 6th and not 10th, 20th and 30th) ? If I allocate the
contiguous signal, does this mean in this case I have to pass only one
label corresponding to the multiplexing position of 4th VC-4 (Lowest
one) and other VC-4s will be derived by the receiving end from the
lowest signal.

In case of contiguous concatenation, Can the contiguous VC-4 signals
span the AUG-Xc in STM-N [ like STM-64 consist of AUG-64. Say it
consist of 4 VC-4-16c. If I have to allocate 20 VC-4s in contiguous
concatenation, can I span VC-4s allocation across the AU-4-16cs  ?

In case of virtual concatenation, Can I allocate non-contiguous signals
(viz. 10th, 20th, 30th) ? In this case I have to pass 3 labels
corresponding to each VC-4 position in the multiplexing hierarchy.
Does this hold true for arbitrary concatenation also ?

Please clarify.

Regards,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
>Date: Wed, 20 Jun 2001 03:46:04 +0200
>
>Manoj,
>
>A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64
>VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of
>VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer
>to G.707).
>
>A VC-4-16c signal can be transported in either one of the four AU-4-16c
>tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to
>7.2.3.4/G.707.
>
>Regards,
>
>Maarten
>
>manoj juneja wrote:
> >
> > Hi Eric,
> >           Thanks for the reply. I have one more doubt :
> >
> > A STM-64 interface consist of 64 STM-1s that are byte interleaved. If
> > I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT
> > with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0,
> > MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to
> > allocate contiguous VC-4s in STM-64 link.
> > Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link.
> > Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal)
> > i.e. only one label will be passed in RESV/Label Mapping message. The
> > receiving node will drive the subsequent labels from this onwards.
> >
> > In case of arbitrary or virtual concatenation, Can I allocate non
> > -contiguous signals from a link ? The label corresponding to each
> > arbitrary or virtually concatenated signal will be passed in
> > RESV/Mapping message.
> >
> > If I have a STM-64 interface configured, and no signal is allocated yet 
>from
> > the link.
> > If I have to allocate a signal STM-3c-7v (virtual concatenation of 7
> > STM-3c), Can I allocate the whole signal from this link ?
> >
> > Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have 
>to
> > pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0},
> > {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ].
> >
> > Does this mean that each STS-3c in STM-3c-7v should be contiguous ?
> >
> > Please tell me if my understanding is correct.
> >
> > Regards,
> > manoj.
> >
> > Regards,
> > manoj.
> >
> > >From: "Mannie, Eric" <[email-masked]>
> > >To: 'manoj juneja' <[email-masked]>, [email-masked]
> > >Subject: RE: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
> > >Date: Tue, 19 Jun 2001 10:02:56 +0200
> > >
> > >Hello Manoj,
> > >
> > >The virtual concatenation is indicated in a separate field (NVC). The
> > >reason
> > >is to allow to code the virtual concatenation of contiguously 
>concatenated
> > >signals (like the virtual concatenation of several STS-3c's.
> > >
> > >Kind regards,
> > >
> > >Eric
> > >
> > >-----Original Message-----
> > >From: manoj juneja [mailto:[email-masked]]
> > >Sent: Tuesday, June 19, 2001 3:03 AM
> > >To: [email-masked]
> > >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
> > >
> > >
> > >Hi,
> > >
> > >      I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :
> > >
> > >   The CCT field can have values no concatenation, standard
> > >concatenation, arbitrary, vendor specific.
> > >But why can't virtual concatenation ? It was there in original draft.
> > >But in the exmaples section for SDH/SONET signals, it is shown that a
> > >virtually concatenated signal can be built using NVC field with CCT
> > >value as 0. Please clarify the reason in doing so.
> > >
> > >Regards,
> > >manoj.
> > >
> > >_________________________________________________________________
> > >Get your FREE download of MSN Explorer at http://explorer.msn.com
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
><< mvissers.vcf >>

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

Delivery-date: Fri, 22 Jun 2001 16:44:27 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Diversity of Routes Doubt
Date: Fri, 22 Jun 2001 16:42:48 -0700

Hi All,
          The OIF-UNI draft contains diversity sub-object (part of
Generalized UNI Attribute object). There is no such object in GMPLS
drafts. In a typical scenario, where one O-UNI request has to be
converted/translated/mapped to one GMPLS (NNI) request, how to
interpret/translate the diversity TLV/object ?
Is it the responsibility of network manager to offline calculate the
ERO (and pass in the path message from the edge/ingress ONE) which
statisfies the diverstiy of the route desired by the client
equipment ? Does this mean the usage of strict routes in ERO ?
Should we be having the diversity object in GMPLS drafts also ?

Please clarify my doubt.

Regards,
manoj.

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

Delivery-date: Fri, 22 Jun 2001 15:21:52 -0700
From: Fong Liaw <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 15:20:53 -0700

Hi, Manoj

>  -----Original Message-----
>  From: manoj juneja [mailto:[email-masked]]
>  Sent: Friday, June 22, 2001 2:53 PM
>  To: [email-masked]; [email-masked]; [email-masked];
>  [email-masked]; [email-masked]
>  Subject: RE: Control Channel Doubt
>  
>  
>  Hi,
>       I think the original purpose of LIH in classical RSVP 
>  was somewhat

You are correct here. That's why RSVP_HOP3 object is introduced
in oif2000.125.5.

>  different. The latest draft of O-UNI (oif2000.125.5) has new
>  RSVP object RSVP_HOP3. This draft reccomends usage of 
>  RSVP_HOP3 object
>  instead of traditional RSVP_HOP object. This new object has 
>  been added
>  for the intention of non-associated signalling. The struture of
>  RSVP_HOP3 is  :
>  
>                {
>                    IPCC's Next/previous Hop
>                    LIH (control channel's LIH)
>                    TLVs.
>                }
>  
>  The TLVs in the above structure specify the interface for the data
>  flow. The TLVs can include maxmum of 2 interface Ids (viz. one for
>  forward direction of data flow and another for reverse direction of
>  data flow).
>  But I don't know whether this object will be equally applicable to
>  GMPLS or not. Whether GMPLS drafts are also going to include the
>  RSVP_HOP3 object in next revision ?

It is the intension to align both OIF and IETF in this aspect. 
The object actually comes from GMPLS authors. The format is 
not final yet as noted by OIF2000.125.5. The reason that
HOP3 even showed up in OIF2000.125.5 is to address comments
on using LIH in SuperComm test/interim agreement. 

Regards,
-Fong

>  
>  Authors of OIF draft, Bala, Kireeti etc. : Please clarify whether the
>  RSVP_HOP3 object has been kept with this intention only or there is
>  some other reason too.
>       
>  Regards,
>  manoj.
>  
>  >From: "Saurabh Shrivastava" <[email-masked]>
>  >Reply-To: <[email-masked]>
>  >To: "'manoj juneja'" <[email-masked]>, "Mpls 
>  \(E-mail\)" 
>  ><[email-masked]>
>  >Subject: RE: Control Channel Doubt
>  >Date: Fri, 22 Jun 2001 13:00:03 -0700
>  >
>  >manoj,
>  >there is something called a LIH (logical interface
>  >handle) in the HOP Object in the PATH message - this
>  >shd be copied into the RESV, so that the receiver
>  >can know on which interface it shd make reservations
>  >even if it receives RESV on some other interface.
>  >-saurabh
>  >
>  >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
>  >Saurabh Shrivastava          [email-masked]
>  >
>  >TiMetra Networks, Inc.       408.245.8796 (residence)
>  >http://www.timetra.com/      650.237.5154 (office)
>  >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
>  >
>  >
>  ># -----Original Message-----
>  ># From: [email-masked] [mailto:[email-masked]]On 
>  Behalf Of manoj
>  ># juneja
>  ># Sent: Friday, June 22, 2001 12:37 PM
>  ># To: [email-masked]; [email-masked]
>  ># Subject: Control Channel Doubt
>  >#
>  >#
>  ># Hi All,
>  >#           Consider the following scenario :
>  >#
>  >#    If I have 2 nodes A and B connected by 3 links (viz. OC-3,
>  ># OC-192 and
>  ># OC-48). Furthermore, I have a out-of-fiber control 
>  channel running on
>  ># ethernet between these two nodes. Here, I am considering the
>  ># case of one
>  ># control channel for all the three data plane interfaces. When
>  ># an incoming
>  ># path message is received, how to identify for which incoming
>  ># data plane
>  ># interface this is for ? or Do I have to configure three
>  ># control channels
>  ># correspondng to each of the data plane interfaces ?
>  >#
>  ># Please clarify my doubt.
>  >#
>  ># Regards,
>  ># manoj.
>  >#
>  >#
>  >#
>  ># _________________________________________________________________
>  ># Get your FREE download of MSN Explorer at http://explorer.msn.com
>  >#
>  
>  _________________________________________________________________
>  Get your FREE download of MSN Explorer at http://explorer.msn.com
>  
>  

Delivery-date: Fri, 22 Jun 2001 15:05:40 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, [email-masked], manoj juneja <[email-masked]>
Subject: RE: Control Channel Doubt
Date: Sat, 23 Jun 2001 00:05:12 +0200

GMPLS related discussion is CCAMP

Bert

> ----------
> From: 	manoj juneja[SMTP:[email-masked]]
> Sent: 	Friday, June 22, 2001 11:36 PM
> To: 	[email-masked]; [email-masked]; [email-masked]
> Subject: 	Re: Control Channel Doubt
> 
> Eric,
>        U are absolutely on track. This is what I was about to post. In
> response to my query, some people are copying the response on ccamp and
> some on mpls mailing list. Please clarify the procedure. I think we
> should have one mailing list. By keeping more mailing lists, we
> are confusing the people. Also, there is no clear demarcation of
> activities in WGs. Either we should shift whole GMPLS related stuff on
> ccamp mailing list otherwise we have to suffer these minor things.
> 
> Regards,
> manoj.
> 
> 
> 
> 
> >From: Eric Gray <[email-masked]>
> >To: "Wijnen, Bert (Bert)" <[email-masked]>
> >CC: ccamp-wg <[email-masked]>, manoj juneja 
> ><[email-masked]>
> >Subject: Re: Control Channel Doubt
> >Date: Fri, 22 Jun 2001 17:12:10 -0400
> >
> >Bert,
> >
> >     What would be the general procedure you would recommend for
> >a person wishing to post a question that applies to multiple groups?
> >What approach do you recommend they use to determine in advance
> >whether or not there is a largely overlapping audience?
> >
> >--
> >Eric Gray
> >
> >You wrote:
> >
> > > Please DO NOT cross post to multiple mailing lists with largely
> > > overlapping audiences. Choose one list and discuss it there.
> > >
> > > Thanks, Bert
> > >
> > > > ---
> >
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 

Delivery-date: Fri, 22 Jun 2001 14:54:36 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 14:52:43 -0700

Hi,
     I think the original purpose of LIH in classical RSVP was somewhat
different. The latest draft of O-UNI (oif2000.125.5) has new
RSVP object RSVP_HOP3. This draft reccomends usage of RSVP_HOP3 object
instead of traditional RSVP_HOP object. This new object has been added
for the intention of non-associated signalling. The struture of
RSVP_HOP3 is  :

              {
                  IPCC's Next/previous Hop
                  LIH (control channel's LIH)
                  TLVs.
              }

The TLVs in the above structure specify the interface for the data
flow. The TLVs can include maxmum of 2 interface Ids (viz. one for
forward direction of data flow and another for reverse direction of
data flow).
But I don't know whether this object will be equally applicable to
GMPLS or not. Whether GMPLS drafts are also going to include the
RSVP_HOP3 object in next revision ?

Authors of OIF draft, Bala, Kireeti etc. : Please clarify whether the
RSVP_HOP3 object has been kept with this intention only or there is
some other reason too.

Regards,
manoj.

>From: "Saurabh Shrivastava" <[email-masked]>
>Reply-To: <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>, "Mpls \(E-mail\)" 
><[email-masked]>
>Subject: RE: Control Channel Doubt
>Date: Fri, 22 Jun 2001 13:00:03 -0700
>
>manoj,
>there is something called a LIH (logical interface
>handle) in the HOP Object in the PATH message - this
>shd be copied into the RESV, so that the receiver
>can know on which interface it shd make reservations
>even if it receives RESV on some other interface.
>-saurabh
>
>~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
>Saurabh Shrivastava          [email-masked]
>
>TiMetra Networks, Inc.       408.245.8796 (residence)
>http://www.timetra.com/      650.237.5154 (office)
>~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
>
>
># -----Original Message-----
># From: [email-masked] [mailto:[email-masked]]On Behalf Of manoj
># juneja
># Sent: Friday, June 22, 2001 12:37 PM
># To: [email-masked]; [email-masked]
># Subject: Control Channel Doubt
>#
>#
># Hi All,
>#           Consider the following scenario :
>#
>#    If I have 2 nodes A and B connected by 3 links (viz. OC-3,
># OC-192 and
># OC-48). Furthermore, I have a out-of-fiber control channel running on
># ethernet between these two nodes. Here, I am considering the
># case of one
># control channel for all the three data plane interfaces. When
># an incoming
># path message is received, how to identify for which incoming
># data plane
># interface this is for ? or Do I have to configure three
># control channels
># correspondng to each of the data plane interfaces ?
>#
># Please clarify my doubt.
>#
># Regards,
># manoj.
>#
>#
>#
># _________________________________________________________________
># Get your FREE download of MSN Explorer at http://explorer.msn.com
>#

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

Delivery-date: Fri, 22 Jun 2001 14:49:24 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: ccamp-wg <[email-masked]>, manoj juneja <[email-masked]>
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 23:49:00 +0200

I would say that if you have a topic, you choose one mailing list to discuss
(and the topic of course should be relevant to the WG itself). That is where 
you post it and where you do discussion.
If you feel that another WG has a different set of people whom you want
to be involved, then you do a separate posting to that list and invite the
people to join on the first list for discussion.

Sorry... but in the CCAMP,. IPO, MPLS set of WG lists, I seem to be
getting FAR TOO MANY duplicate postings because of all that cross posting.
And it seems to me that MANY people suffer from the same.

Bert
> ----------
> From: 	Eric Gray[SMTP:[email-masked]]
> Sent: 	Friday, June 22, 2001 11:12 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	ccamp-wg; manoj juneja
> Subject: 	Re: Control Channel Doubt
> 
> Bert,
> 
>     What would be the general procedure you would recommend for
> a person wishing to post a question that applies to multiple groups?
> What approach do you recommend they use to determine in advance
> whether or not there is a largely overlapping audience?
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Please DO NOT cross post to multiple mailing lists with largely
> > overlapping audiences. Choose one list and discuss it there.
> >
> > Thanks, Bert
> >
> > > ---
> 
> 

Delivery-date: Fri, 22 Jun 2001 14:47:09 -0700
Date: Fri, 22 Jun 2001 17:46:54 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Control Channel Doubt

Manoj,

The question you ask is clearly in the scope of CCAMP only.

Regards,

Yangguang

manoj juneja wrote:
> 
> Eric,
>        U are absolutely on track. This is what I was about to post. In
> response to my query, some people are copying the response on ccamp and
> some on mpls mailing list. Please clarify the procedure. I think we
> should have one mailing list. By keeping more mailing lists, we
> are confusing the people. Also, there is no clear demarcation of
> activities in WGs. Either we should shift whole GMPLS related stuff on
> ccamp mailing list otherwise we have to suffer these minor things.
> 
> Regards,
> manoj.
> 
> >From: Eric Gray <[email-masked]>
> >To: "Wijnen, Bert (Bert)" <[email-masked]>
> >CC: ccamp-wg <[email-masked]>, manoj juneja
> ><[email-masked]>
> >Subject: Re: Control Channel Doubt
> >Date: Fri, 22 Jun 2001 17:12:10 -0400
> >
> >Bert,
> >
> >     What would be the general procedure you would recommend for
> >a person wishing to post a question that applies to multiple groups?
> >What approach do you recommend they use to determine in advance
> >whether or not there is a largely overlapping audience?
> >
> >--
> >Eric Gray
> >
> >You wrote:
> >
> > > Please DO NOT cross post to multiple mailing lists with largely
> > > overlapping audiences. Choose one list and discuss it there.
> > >
> > > Thanks, Bert
> > >
> > > > ---
> >
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 22 Jun 2001 14:37:25 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Control Channel Doubt
Date: Fri, 22 Jun 2001 14:36:39 -0700

Eric,
       U are absolutely on track. This is what I was about to post. In
response to my query, some people are copying the response on ccamp and
some on mpls mailing list. Please clarify the procedure. I think we
should have one mailing list. By keeping more mailing lists, we
are confusing the people. Also, there is no clear demarcation of
activities in WGs. Either we should shift whole GMPLS related stuff on
ccamp mailing list otherwise we have to suffer these minor things.

Regards,
manoj.

>From: Eric Gray <[email-masked]>
>To: "Wijnen, Bert (Bert)" <[email-masked]>
>CC: ccamp-wg <[email-masked]>, manoj juneja 
><[email-masked]>
>Subject: Re: Control Channel Doubt
>Date: Fri, 22 Jun 2001 17:12:10 -0400
>
>Bert,
>
>     What would be the general procedure you would recommend for
>a person wishing to post a question that applies to multiple groups?
>What approach do you recommend they use to determine in advance
>whether or not there is a largely overlapping audience?
>
>--
>Eric Gray
>
>You wrote:
>
> > Please DO NOT cross post to multiple mailing lists with largely
> > overlapping audiences. Choose one list and discuss it there.
> >
> > Thanks, Bert
> >
> > > ---
>
>

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

Delivery-date: Fri, 22 Jun 2001 14:14:36 -0700
Date: Fri, 22 Jun 2001 17:12:10 -0400
From: Eric Gray <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>, manoj juneja <[email-masked]>
Subject: Re: Control Channel Doubt

Bert,

    What would be the general procedure you would recommend for
a person wishing to post a question that applies to multiple groups?
What approach do you recommend they use to determine in advance
whether or not there is a largely overlapping audience?

--
Eric Gray

You wrote:

> Please DO NOT cross post to multiple mailing lists with largely
> overlapping audiences. Choose one list and discuss it there.
>
> Thanks, Bert
>
> > ---

Delivery-date: Fri, 22 Jun 2001 13:40:21 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, manoj juneja <[email-masked]>
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 22:35:55 +0200

Please DO NOT cross post to multiple mailing lists with largely
overlapping audiences. Choose one list and discuss it there.

Thanks, Bert

> ----------
> From: 	manoj juneja[SMTP:[email-masked]]
> Sent: 	Friday, June 22, 2001 9:37 PM
> To: 	[email-masked]; [email-masked]
> Subject: 	Control Channel Doubt
> 
> Hi All,
>           Consider the following scenario :
> 
>    If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and 
> OC-48). Furthermore, I have a out-of-fiber control channel running on 
> ethernet between these two nodes. Here, I am considering the case of one 
> control channel for all the three data plane interfaces. When an incoming 
> path message is received, how to identify for which incoming data plane 
> interface this is for ? or Do I have to configure three control channels 
> correspondng to each of the data plane interfaces ?
> 
> Please clarify my doubt.
> 
> Regards,
> manoj.
> 
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 

Delivery-date: Fri, 22 Jun 2001 12:42:04 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Control Channel Doubt
Date: Fri, 22 Jun 2001 12:37:22 -0700

Hi All,
          Consider the following scenario :

   If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and 
OC-48). Furthermore, I have a out-of-fiber control channel running on 
ethernet between these two nodes. Here, I am considering the case of one 
control channel for all the three data plane interfaces. When an incoming 
path message is received, how to identify for which incoming data plane 
interface this is for ? or Do I have to configure three control channels 
correspondng to each of the data plane interfaces ?

Please clarify my doubt.

Regards,
manoj.

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

Delivery-date: Fri, 22 Jun 2001 10:57:14 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: GMPLS Doubt
Date: Fri, 22 Jun 2001 10:49:37 -0700

Hi All,
        In the draft draft-ietf-mpls-generalized-signalling-04.txt,
different values of LSP encoding type are defined. What all values of
LSP encoding type are currently supported by GMPLS ?

The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH
etc.

I think the only supported values of LSP encoding type are :

SDH ITU-T G.707 1996
SONET ANSI T1.105-1995
SDH ITU-T G.707 2000
SONET ANSI T1.105-2000
Fiber
Lambda
Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ]

Please comment.

Regards,
manoj.

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

Delivery-date: Thu, 21 Jun 2001 21:47:26 -0700
To: [email-masked]
From: [email-masked]
Subject: BOUNCE [email-masked]: Header line too long (>128)
Date: Thu, 21 Jun 2001 17:03:55 -0700

>From [email-masked] Thu Jun 21 17:03:54 2001
Message-ID: <46f301c0faae$bebd1490$0e03ca0a@cp98suwbm02>
Date: Thu, 21 Jun 2001 17:03:19 -0700
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
MIME-Version: 1.0
To: <[email-masked]>
Cc: <[email-masked]>,	<[email-masked]>,	<[email-masked]>,	<[email-masked]>,	<[email-masked]>,	<[email-masked]>
Sender: <[email-masked]>
Precedence: bulk

Bala,
Thanks for your reply.  Sorry it took so long to reply back. Please see
in-line.

Thanks,
Ananth

bala>> > 1) Type of legacy equipment needing NSAP addresses
bala>> > (also, is
bala>> > this optical network element or client equipment?)
bala>> > 2) Rough estimate of number of UNI ports needing NSAP address
bala>> > (2002, 2005, and 2010)
bala>> > 3) Description of application in which this legacy equipment
bala>> > will use UNI
bala>> > signaling
bala>I don't recall seeing any response. furthermore, the NSAP
bala>requirement was not unanimously endorsed by all carriers (at
bala>the OIF).

>From our OIF representatives, although it was not unanimously endorsed,
there was a significant demand for NSAP support. Well, NSAP is the main
non-IP type of addressing that is required. The general requirement is
to be able to support non-IP addresses (probably have an address
translation from non-IP addresses to routable addresses).

bala>It would also be nice if you can give some insight on
bala>the timeline in which you need various features, and whether
bala>the current GMPLS developments are inadequate within
bala>that timeline. (We can always have a progression of features).

NSAP support will be needed always (e.g. support for legacy DCC that
uses NSAP).  So the timeframe requirement is now.

Ananth>2) GMPLS is being defined based on assumptions about proprietary
Ananth>transmission planes without those assumptions being specified.
How can
Ananth>we be sure that the control plane support is correct? How can we
be
Ananth>sure that it can be combined with other features?  Assumptions
Ananth>regarding the transmission plane that can affect the control
plane must
Ananth>be clearly documented. This creates the additional related
problem that
Ananth>there is not a clear inter-working defined for interaction
between
Ananth>standard/proprietary control planes/transmission planes.

bala>BR: I get the feeling you're referring to the
concatenation/transperency
bala>issues discussed recently. While the debate has been hot, there's
bala>no show stopper here. Several suggestions are being considered for
bala>clarifying standard/non-standard features supported.

The concatenation/transparency issues are a concern.  In addition,
management features such as manual protection switching, protection
switching configuration, billing support (e.g. usage collection) etc
need to be supported too.

Ananth>3) Assuring separation of the control plane from the data plane
Ananth>continues to arise.. When the control plane fails it should not
affect
Ananth> existing connections.  Also if connections in progress are
affected
Ananth>then they should not leave partially setup connections - they
should
Ananth>fail gracefully informing the initiator. The GMPLS architecture
Ananth>document mentions this separation, but it's not clear how the
GMPLS
Ananth>signaling specifications reflect the implications of this
decoupling.

bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS
bala>based, as you know), and solutions in the RSVP/LDP space have been
bala>proposed (some drafts may be written).
bala>This is also not a show stopper by any means.

Don't understand how the OIF UNI addresses this. Our concerns are more
with respect to the NNI (internal separation of control and data). If
this is not addressed, it is definitely a showstopper.  According to
our OIF representatives, the OIF is looking at the IETF to specify
these protocols.

To be specific, existing connections shouldn't be impacted when the
control plane fails.

Ananth>4) Support for NSAP addresses and in general support such that
control
Ananth>plane addressing is independent of clients and vice versa.  Also
Ananth>scalable naming/addressing scheme such as proposed in OIF.

bala>BR: NSAP, see my initial comments. The OIF is not dealing with
bala>names/resolution, etc. This has been decided to be out of the
bala>scope of UNI signaling, and considered as a separate function.

Address translation of some form (for e.g. NSAP address translation)
should be supported. See comment at the beginning of the email.

Ananth>5) Since the control plane may be supported via multiple
protocols,
Ananth>clear statement of what is - and  isn't - covered in the GMPLS
Signaling
Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed.

bala>BR: Don't understand this, but doesn't look like a major issue from
bala>your phrasing.

Recommend the development of applicability statements to cover this
(otherwise, it is difficult to understand how the different pieces join
together to form a coherent picture).

Ananth>6) Terminology is an issue (e.g., waveband switching, link)

bala>BR: Any inconsistencies can be taken care of easily.

Like your comment. Hope it is as easy as it sounds :-) Mapping of
terminology between standards bodies and also between different drafts
in the IETF can be painful. Agreed however, that this is not a
show-stopper.

Ananth>7) Transaction support for connection set-up and release is
needed for
Ananth>connection oriented networks (e.g. crankback capability).

bala>BR: Internet drafts have already been written on crankback. I
suggest
bala>that you please consider writing some drafts if there is something
bala>missing.

Aware of the "iwata-draft". Are there others?

Ananth>8) Reliable message transfer

bala>BR: Very much a part of signaling. the OIF work has considered this
bala>aspect also.

'soft-state' signaling protocols may not be acceptable for the optical
control plane.  Live channels must not be dropped as a result of
signaling message delivery failures (e.g. timer refresh failures)

Ananth>9) Security concerns have not been fully addressed, particularly
at the
Ananth> architectural level.  The use of separate control network may
Ananth>necessitate the need for 24 hour staff to protect against
'Denial of
Ananth>Service' attacks as currently happens for IP router networks. In
Ananth>general, admission control issues need to be addressed.

bala>BR: Please elaborate on these, specifically, what's new in the
bala>context of GMPLS.

e.g. in the case of ATM UNI, if a user or users attempt too many call
setups
simultaneously the switch control processor can become overloaded.  So,
some form of call pacing/overload handling is needed.  Is there
something similar in the GMPLS context for optical devices?

Ananth>10) The definition of transparency may be overly simplified.
See
Ananth>comments by Ben Mack-Crane:
Ananth>I think the debate on transparency indicates that the issue is
not as
Ananth>clear
Ananth>as we might think.  The OIF document you cite defines forms of
Ananth>transparency
Ananth>that are very straightforward (flags 1,2) not the more complex
forms in
Ananth>the current GMPLS drafts (flags 3..10).  Also, these are easily
Ananth>provided in
Ananth>O-E-O or O-O-O networks operating at the lambda level, but there
is no
Ananth>standard for providing these over TDM multiplexed SONET/SDH
links.

bala>BR: This is an ongoing topic of discussion. Doesn't break down
bala>the rest of the proposal.

Agreed.

Ananth>If two vendors implement the same signaling but different TDM
Ananth>multiplexing, that
Ananth>doesn't achieve interoperability.  Is there any way in the
drafts to
Ananth>determine the scope
Ananth>of application of the various signaling elements (that is,
whether they
Ananth>apply to UNI or NNI, whether they apply to specific network
Ananth>layers/technologies)?

Ananth>11) One summary of additional items with issues includes:
Ananth>- SDH/SONET transparency.
Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation.
Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities.
Ananth>- All kinds of end-to-end protection/restoration for any layer,
except
Ananth>the IP layer.

bala>BR: Restoration is not actually covered in the current set of
drafts.
bala>An earlier thread discussed this, and my suggestion is that this
bala>feature be dealt with separately.

Potential show-stopper for deployment if restoration is not covered.
Would agree that it could be addressed separately, though.

Ananth>- The label set object (only used for lambda issues).
Ananth>- LSP encoding type, bandwidth encoding and GPID have to be
simplified
Ananth>accordingly.
Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is
not yet
Ananth>defined).

bala>BR: A draft is forthcoming on this.

Have been made aware of this. Thanks.

Ananth>12) Support for paths across SONET/SDH gateways

bala>BR: Please clarify the issues/write drafts.

Quoting from Siegfried Giebl's email regarding
<draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
"If I understand this document correctly, then you are completely
separating SONET and SDH signal types from each other,  thus making it
difficult to deal with paths across SONET/SDH gateways. As an
alternative, I
suggest you work only with entities of level STS-1 (STM-0) and higher.
On the other hand why don't you go the full way and also add 64 kb/s
channels ?"

Ananth> 13) Compatibility is required/desired with legacy SDH/SONET
equipment
Ananth>[and also legacy DWDM]

bala>BR: Same as above.

NSAP issue identified above. Elements within a link may not communicate
using the signaling, i.e., legacy SDH/SONET equipment that does not
participate in signaling (participate only in connectivity)

Thanks,
Ananth

Delivery-date: Thu, 21 Jun 2001 13:50:26 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: LSP Encoding Type Doubt
Date: Thu, 21 Jun 2001 13:48:21 -0700

Hi,
    On a Sonet/SDH link, Can I support LSP encoding type as
ANSI/ETSI PDH by
mapping the E1/E3 or DS1/DS3 to SDH/SONET signals ?

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

Delivery-date: Thu, 21 Jun 2001 13:50:12 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bandwidth Encoding Type Doubt .....
Date: Thu, 21 Jun 2001 13:47:43 -0700

Hi,
    Can someone please tell me the reason for bandwidth encoding
parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
will be drived from the signal type field. How the bandwidth
encoding
type will be interpreted in case of other LSP encoding types ?

Regards,
manoj.

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

Delivery-date: Wed, 20 Jun 2001 18:12:41 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bandwidth Encoding Type Doubt .....
Date: Wed, 20 Jun 2001 18:11:00 -0700

Hi,
    Can someone please tell me the reason for bandwidth encoding
parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated
will be drived from the signal type field. How the bandwidth encoding
type will be interpreted in case of other LSP encoding types ?

Regards,
manoj.

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

Delivery-date: Wed, 20 Jun 2001 15:06:14 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: LSP Encoding Type Doubt
Date: Wed, 20 Jun 2001 15:02:45 -0700

Hi,
    On a Sonet/SDH link, Can I support LSP encoding type as ANSI/ETSI PDH by 
mapping the E1/E3 or DS1/DS3 to SDH/SONET signals ?

Regards,
manoj.

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

Delivery-date: Wed, 20 Jun 2001 12:29:51 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: [email-masked]
Subject: RE: OLI requirements
Date: Wed, 20 Jun 2001 15:27:55 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9BF.1B24CC00
Content-Type: text/plain;
	charset="iso-8859-1"

I obviously agree with the requirements (as yet another author). However, I
believe the OLI has more to do with transport. As a result, I am also
working with others in the ITU where there already exists a significant body
of knowledge in this area.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Kireeti Kompella [mailto:[email-masked]] 
Sent:	Monday, June 18, 2001 9:22 PM
To:	[email-masked]
Subject:	OLI requirements

Hi All,

A document on Optical Link Interface Requirements has been submitted
(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )

Please review the draft and comment (to _this_ list) on the following:
1) Are the requirements stated useful?
2) Are there useful requirements that are missing?
3) Do you think that this document should be a CCAMP WG document?
   a) as it stands today?
   b) only if it changed?
   c) no, no matter what surgery is done on it?
   d) yawn ...

Extra points for terse, technical and temperate comments.

We'd like to judge the sentiment towards this draft in a week or two,
so if you'd like your comments to be acted upon, send them soon.

Thanks,
Kireeti & Vijay.

------_=_NextPart_001_01C0F9BF.1B24CC00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: OLI requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I obviously agree with the requirements (as yet =
another author). However, I believe the OLI has more to do with =
transport. As a result, I am also working with others in the ITU where =
there already exists a significant body of knowledge in this =
area.</FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Monday, June 18, 2001 9:22 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OLI requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>A document on Optical Link Interface Requirements has =
been submitted</FONT>
<BR><FONT SIZE=3D2>(URL: <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.t=
xt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-many-oli-=
reqts-00.txt</A> )</FONT>
</P>

<P><FONT SIZE=3D2>Please review the draft and comment (to _this_ list) =
on the following:</FONT>
<BR><FONT SIZE=3D2>1) Are the requirements stated useful?</FONT>
<BR><FONT SIZE=3D2>2) Are there useful requirements that are =
missing?</FONT>
<BR><FONT SIZE=3D2>3) Do you think that this document should be a CCAMP =
WG document?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; a) as it stands today?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; b) only if it changed?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; c) no, no matter what surgery is done =
on it?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; d) yawn ...</FONT>
</P>

<P><FONT SIZE=3D2>Extra points for terse, technical and temperate =
comments.</FONT>
</P>

<P><FONT SIZE=3D2>We'd like to judge the sentiment towards this draft =
in a week or two,</FONT>
<BR><FONT SIZE=3D2>so if you'd like your comments to be acted upon, =
send them soon.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Kireeti &amp; Vijay.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F9BF.1B24CC00--

Delivery-date: Wed, 20 Jun 2001 09:09:31 -0700
From: [email-masked]
Reply-to: [email-masked]
To: IETF-Announce: ;
CC: [email-masked]
Subject: I-D ACTION:draft-cheng-gmpls-dynamic-trunking-00.txt
Date: Wed, 20 Jun 2001 09:08:59 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS Extensions for Dynamic Trunking
	Author(s)	: D. Cheng
	Filename	: draft-cheng-gmpls-dynamic-trunking-00.txt
	Pages		: 15
	Date		: 19-Jun-01
	
Currently the GMPLS signaling requires to include a 'LSP Encoding
Type' in the Generalized Label Request ([GMPLS-SIG]), which indicates
the encoding of the LSP being requested. Upon receiving a RSVP PATH
message or CR-LDP REQUEST message that contains a Generalized Label 
Request, a LSR must verify if the receiving and transmitting interface
can support the LSP. In particular on the transmitting side, the node
either finds an interface that has the same switching class, among 
other requirements, or it may use a FA-LSP, i.e., another class of
switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-cheng-gmpls-dynamic-trunking-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-cheng-gmpls-dynamic-trunking-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 20 Jun 2001 03:30:47 -0700
From: "Diego Caviglia" <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], "Giovanni Fiaschi" <[email-masked]>
Date: Wed, 20 Jun 2001 12:28:00 +0200
Subject: draft-many-optical-restoration-00

Hi Dimitri,
       a  comment on the draft in the subject, is not completely clear to me why
is  needed  to  know  if there are lambda converter in OXC. OXC as stated in the
previous  chapter  are  OEO  devices  and thus are always able to perform lambda
conversion.
The architecture I have in mind for OXC is:

|\                 /|--|------|--|\
| |               | |--|      |--| |
| |---------------| |--| OXC  |--| |------//--------
| |               | |--|      |--| |
|/                 \|--|------|--|/
A                  B       C      D

Here DWDM B performs:
Demultiplexing of the received channels
OEO conversion with transponder
At  this  point  usually  the  signal  is  grey the optical matrix perform cross
connection.
DWDM  D  receives  grey signal on its interfaces and then using transponder puts
the grey signal on the right lambda.
So  is  always  possible  to  convert  an  incoming let's say green lambda in an
outgoing blue lambda by the means of OEO performed by DWDM transponder.

Another  thing  that is not very clear to me is the use of tunable lasers. Could
you please clarify better this point?

Best regards.

Diego.

Delivery-date: Tue, 19 Jun 2001 23:07:47 -0700
Date: Wed, 20 Jun 2001 08:05:55 +0200
From: Loa Andersson <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: OLI requirements

Kireeti and Vijay,

in the capacity of a non-co-author :-)  and operator, please see 
comments inline.

Kireeti Kompella wrote:
> 
> A document on Optical Link Interface Requirements has been submitted
> (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )
> 
> Please review the draft and comment (to _this_ list) on the following:
> 1) Are the requirements stated useful?

yes

> 2) Are there useful requirements that are missing?

nothing that meets the eye or would stop progressing the document

> 3) Do you think that this document should be a CCAMP WG document?
>    a) as it stands today?
>    b) only if it changed?
>    c) no, no matter what surgery is done on it?
>    d) yawn ...

a

> 
> Extra points for terse, technical and temperate comments.
> 
> We'd like to judge the sentiment towards this draft in a week or two,
> so if you'd like your comments to be acted upon, send them soon.

Good, I think this is a typical case there it is extremely more useful 
to have  something (and possible improve later if necessary) than not 
have anything. Please progress this a fast as possible.

/Loa
> 
> Thanks,
> Kireeti & Vijay.

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Tue, 19 Jun 2001 19:15:58 -0700
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Date: Wed, 20 Jun 2001 04:14:13 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Yong Xue <[email-masked]>
Original-CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: OLI requirements

This is a multi-part message in MIME format.
--------------DA3B633851B655C4947A7F11
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The OLI work is in parallel to the work in ITU-T SG15 on OTM-LF
(Line-fabric) interface.

This OTM-LF interface is essentially a "virtual backplane" interface,
and has to support the applications that are typically supported on a
backplane in e.g. a SDH/SONET cross connect system, plus the specific
OTN applications (for the moment transport of OCh Overhead).

	"[from WD43, Q.14/15 meeting June 2001] The OTM-LF interface is a
multi-fiber parallel interface; it includes all fibers between OLS and
OXC used for traffic transport and the additional "funiculus" (umbilical
cord) or "Optical Supervisory Interface (OSI)"  interface (either on
fiber or copper). This funiculus/OSI carries all necessary information
as required by the applications between OLS and OXC; e.g. OAM, status
information and comms channels. It is a kind of supervisory channel, but
now between the trib interface side of the OLS and the OXC (instead of
between the line interface side of an OLS and the next OLS); see Figure
3."

Note - "OSI"/"funiculus" are alternative names for "OLI".

The OSI/funiculus has to interconnect one or more optical line systems
with one or more optical fabrics and/or with one or more client
equipment. I.e. a multi-point to multi-point configuration.

Up to so far, 10 applications are identified that may have to be
supported by a OTM-LF interface (text copied from WD43, Q.14/15 meeting
June 2001 http://ties.itu.int/u/tsg15/sg15/wp3/q14/0106/wd43-otmlf02.doc
):

4.1 Application 1: Connection Status

For the case OLS equipment contains ports with monitoring capabilities
(i.e. 3R points/transponders) it can detect the status of the individual
link connections while service is provided by the link connections. The
status of a link connection can be expressed by means of the signal fail
and signal degrade (SF, SD) condition determined by the appropriate
atomic function monitoring the link connection. The use of port models
based on ITU-T G.806, G.705, G.783 and draft G.798 most likely allows
re-using existing specifications. See section 11.

For the case of (link) connections not yet carrying service, the status
can be determined also using a scanner in optical fabrics which connects
cyclically a test generator and test monitor device/circuit to these
(link) connections. Coordination is of course required between the
optical fabric with the test generator and the one with the test
monitor.

4.2 Application 2: Port Management

Ports in an OLS may need to be managed as part of the connection
creation, release and modification actions (valid for both permanent
connections (setup by management plane) and for switched connections
(setup by control plane).

Port management is required for he case the port includes: =

- a monitoring or termination function (e.g. section termination, tandem
connection termination, path termination or non-intrusive monitor);
tandem connection monitor function may need to be activated/de-activated
and one or more MI_XXX (refer to G.806, G.705, G.783, G.798) signals of
termination and monitor functions may need a value to be assigned.

- a protection switch function; values may need to be assigned to
protection switching specific MI_XXX signals like bridge type
(broadcast/selective/permanent), protection architecture type (1+1, 1:1,
1:n, m:n, (1:1)n, with/without extra traffic), protection switching type
(uni-directional, bi-directional), protection operation type (revertive,
non-revertive), WTR timer, HO timer, SF and SD priority. [Note - this
functionality is most likely not part of initial OLS equipment.]

Although the equipment recommendations (ITU-T G.806, G.705, G.783, draft
G.798, ETSI EN 300 417-x-1 x=3D1..6) list all MI_XXX signals and the
equipment management function recommendations (ITU-T G.784, ETSI EN 300
417-7-1, ITU-T draft G.cemr, draft G.874) list the associated
pre-/post-processing for those MI_XXX signals, there is a need to tie
those signals to their applications and identify the subset of
applications that are to be controlled via the funiculus/OSI.

In addition, ports on the OLS needs management to suppress tributary
signal LOS alarms caused by an open matrix connection in the optical
fabric (and no light is output).

4.3 Application 3: OLS Discovery

The OLS equipment port (and its associated tributary slot (i.e.
wavelength) in the WDM line signal), which is physically adjacent to a
port on the optical fabric equipment should be automatically discovered
by the optical fabric equipment. As multiple OLS equipment will be
surrounding the optical fabric equipment, the discovery is about
relating the port X on the fabric to line port (i.e. OLS) Y and
tributary slot Z (Port X =F3 LinePort Y/TribSlot Z).

Note - not part of this application is the discovery of the adjacent
switch (optical fabric equipment) and link in between this switch and
the adjacent switch. This is part of the general control plane
functionality and addressed in that activity (ITU-T G.ason, G.disc).

4.4 Application 4: Status monitoring of funiculus/OSI interface and of
communications over it

The status of the funiculus/OSI interface and the communications over it
should be monitored. As this has similarities with EMS-NE communications
in management plane, most likely we can re-use existing requirements and
specifications from e.g. SDH/SONET networks. Q.14/15 experts may provide
further input here.

4.5 Application 5: Control Plane Communication

This application encompasses multiple control plane applications. Of
particular interest here are those applications which have their
application endpoints in the optical fabric equipment and the physically
adjacent OLSs.

Note - other control plane applications with application endpoints in
this and the next optical fabric equipment will be listed
(non-exhaustive) only, and will not be subject of this work item. It is
already part of control plane specifications (G.ason, G.dcm, G.disc, =85)=
=2E

The optical fabric equipment <=3D> physical adjacent OLS equipment contro=
l
plane applications are:
- to be added=85

4.6 Application 6: Management Plane Communication

The Management Plane is supported by a Data Communication Network (DCN).
This DCN may use in-band Data Communication Channels (DCC) to
interconnect network elements at the management level without the need
for external communication means. The funiculus/OSI should support such
DCC, to be able continue this DCN in-band from OTM-n.m OSC via OLS via
optical fabric equipment via OLS to OTM-n.m OSC.

4.7 Application 7: OCh Overhead

In an all optical OTN network application (i.e. for case of an OLS trib
port without 3R point (transponder)), non-associated OCh overhead
(currently: OCh-FDI, OCh-OCI) must be transported between OLS and
optical fabric equipment. The funiculus/OSI should support the transport
of these OCh non-associated overhead signals.

4.8 Application 8: Protection Switch Endpoint Coordination

For the case the optical fabric equipment includes protection switch
functions supporting bi-directional switching, the optical fabric
equipment with the bridge and with the selector functions must
coordinate their protection switching actions via the Automatic
Protection Switch (APS) co-ordination communication channel. The
funiculus/OSI should support the transport of these APS signals.

4.9 Application 9: Protection Switch Functional Model Emulation

For the case an OMS, OCh or ODUk protection implementation does not
comply with its protection switch functional model (see annex B, which
is copied from
http://ties.itu.int/u/tsg15/sg15/wp3/q9/0106/cd/gen-lin-prot-v07.doc ),
BDI and BEI information should be communicated to and from the optical
fabric equipment via the funiculus/OSI. The optical fabric equipment
will select the BDI/BEI information from the "active" interface port and
forward this to both upstream "working" and "protection" interface
ports. This implements BDI/BEI equivalent to the "RDI/REI X-coupling"
indicated in figures B-3 and B-4.

4.10 Application 10: Auxiliary Communication

Depending on the specific requirements for OrderWire (OW) and Operator
Specific (OpSp) signals, there may be a need to continue those signals
beyond a single line system (OLS - OLS). In such case, the OW and/or
OpSp information should be transported via the funiculus/OSI.

Q.12/15 indicated that the work on this OTM-LF interface requires
detailed models of the interface ports at each end of the interface to
be available. Without such models, it will not be possible to complete
the specification; applications will most likely be overlooked and/or
only partly supported otherwise.

This equally applies to the OLI work; without accurate descriptions of
the transport functionality at each end of the interface supported by
the OLI, an incomplete specification will be the result.

Up to so far...

Regards,

Maarten
--------------DA3B633851B655C4947A7F11
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DA3B633851B655C4947A7F11--

Delivery-date: Tue, 19 Jun 2001 18:50:36 -0700
Cc: [email-masked], [email-masked]
Date: Wed, 20 Jun 2001 03:46:04 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked], [email-masked]
Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt

This is a multi-part message in MIME format.
--------------5C8E7B2A46D33A8AF6DE1AEB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj,

A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64
VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of
VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer
to G.707).

A VC-4-16c signal can be transported in either one of the four AU-4-16c
tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to
7.2.3.4/G.707.

Regards,

Maarten

manoj juneja wrote:
> 
> Hi Eric,
>           Thanks for the reply. I have one more doubt :
> 
> A STM-64 interface consist of 64 STM-1s that are byte interleaved. If
> I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT
> with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0,
> MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to
> allocate contiguous VC-4s in STM-64 link.
> Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link.
> Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal)
> i.e. only one label will be passed in RESV/Label Mapping message. The
> receiving node will drive the subsequent labels from this onwards.
> 
> In case of arbitrary or virtual concatenation, Can I allocate non
> -contiguous signals from a link ? The label corresponding to each
> arbitrary or virtually concatenated signal will be passed in
> RESV/Mapping message.
> 
> If I have a STM-64 interface configured, and no signal is allocated yet from
> the link.
> If I have to allocate a signal STM-3c-7v (virtual concatenation of 7
> STM-3c), Can I allocate the whole signal from this link ?
> 
> Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have to
> pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0},
> {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ].
> 
> Does this mean that each STS-3c in STM-3c-7v should be contiguous ?
> 
> Please tell me if my understanding is correct.
> 
> Regards,
> manoj.
> 
> Regards,
> manoj.
> 
> >From: "Mannie, Eric" <[email-masked]>
> >To: 'manoj juneja' <[email-masked]>, [email-masked]
> >Subject: RE: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
> >Date: Tue, 19 Jun 2001 10:02:56 +0200
> >
> >Hello Manoj,
> >
> >The virtual concatenation is indicated in a separate field (NVC). The
> >reason
> >is to allow to code the virtual concatenation of contiguously concatenated
> >signals (like the virtual concatenation of several STS-3c's.
> >
> >Kind regards,
> >
> >Eric
> >
> >-----Original Message-----
> >From: manoj juneja [mailto:[email-masked]]
> >Sent: Tuesday, June 19, 2001 3:03 AM
> >To: [email-masked]
> >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
> >
> >
> >Hi,
> >
> >      I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :
> >
> >   The CCT field can have values no concatenation, standard
> >concatenation, arbitrary, vendor specific.
> >But why can't virtual concatenation ? It was there in original draft.
> >But in the exmaples section for SDH/SONET signals, it is shown that a
> >virtually concatenated signal can be built using NVC field with CCT
> >value as 0. Please clarify the reason in doing so.
> >
> >Regards,
> >manoj.
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------5C8E7B2A46D33A8AF6DE1AEB
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------5C8E7B2A46D33A8AF6DE1AEB--

Envelope-to: [email-masked]
Delivery-date: Tue, 19 Jun 2001 18:07:22 -0700
Date: Tue, 19 Jun 2001 21:05:19 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt

> Having said that, I'll leave it to the ADs to really answer your
> question :-)

it would be redundant - you already did

> Note that this is "rough consensus"; this is not a vote, nor is
> each response necessarily "yes" or "no".  Also, 3 "votes" for and
> none against might mean that we're wasting time on something of
> little interest.

a bit of expansion though - "rough consensus" does not mean 51% vs 49%
it means the WG (or at least the responders) generally agree - so the number
of responses is not an issue (unless its not many as Kireeti already pointedd
out) but the balance - 10 people saying "yes" and 8 saying "no" will not
cut it

Scott

Envelope-to: [email-masked]
Delivery-date: Tue, 19 Jun 2001 17:33:56 -0700
Date: Tue, 19 Jun 2001 17:33:01 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt

Irfan,

> How many response are required before it is deemed consensus?

Excellent question!

Note that this is "rough consensus"; this is not a vote, nor is
each response necessarily "yes" or "no".  Also, 3 "votes" for and
none against might mean that we're wasting time on something of
little interest.

Having said that, I'll leave it to the ADs to really answer your
question :-)

As for conserving bandwidth, that's very net-worthy, but I'd
prefer that people sent short messages rather than not sending
any, so that we can gauge interest level as well as sentiment.

Kireeti.

Delivery-date: Tue, 19 Jun 2001 17:18:05 -0700
From: "Irfan Lateef" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: draft-ietf-mpls-lmp-02.txt
Date: Tue, 19 Jun 2001 20:15:45 -0400

Kireeti,

How many response are required before it is deemed consensus?

Apologize if it is documented in some RFC. But I am asking because in
future if I see "N" responses I will not send mine if it is the
same and conserve some bandwidth.

Belated, but I also think it should be in CCAMP.

Irfan Lateef

>From: Kireeti Kompella <[email-masked]>
>To: [email-masked]
>Subject: draft-ietf-mpls-lmp-02.txt
>Date: Mon, 18 Jun 2001 19:04:12 -0700 (PDT)
>
>Hi All,
>
>Once upon a time, there was consensus to make the above document
>(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
>an MPLS WG document.
>
>It now falls under the purvey of CCAMP.  Question: do you think this
>document should be a CCAMP WG document?  (You know the drill ....)
>
>Kireeti & Vijay.
>

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

Delivery-date: Tue, 19 Jun 2001 14:29:03 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: WG Last Call on GMPLS documents
Date: Tue, 19 Jun 2001 23:28:06 +0200

When flooded with the many postings/comments, I sometimes hate
it when people are giving so much comments. But at the other hand,
it also shows that we do get feedback from the community.

The WG Last Call was a joint call between MPLS and CCAMP WGs.
This was done because the 4 documents were in transit from MPLS
to CCAMP WG. As a result we saw a lot of (too much!) cross posting.

> - from now on we want discussion on CCAMP mailing list. Pls do not
>   copy MPLS and IPO mailing lists... if you want to participate, pls
>   join CCAMP mailing list.
> - BUT... before you send more comments... pls hold off for a bit.
>   There are some 1000 or so postings to the WG Last Call.
>   I have asked the CCAMP WG chairs to try and make a summary of 
>   the issues. Once they have done that, they will post them and try to 
>   find out how many people agree/disagree with each issue.
>   I.e. they will try to find out if there is WG consensus on what the
>   issues are.
> - I believe there were some suggested "fixes" to address some issues
>   as well. The WG chairs will also try to summarize these and again
>   then try to find out how much WG support there is for these "fixes".
> - Then we will take it from there.
> 
Thanks,
Bert

Delivery-date: Tue, 19 Jun 2001 13:42:30 -0700
Date: Tue, 19 Jun 2001 16:35:09 -0400
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: Yong Xue <[email-masked]>
Subject: Re: OLI requirements

As a carrier and one of the co-author ..

At 06:21 PM 6/18/01 -0700, Kireeti Kompella wrote:
>Hi All,
>
>A document on Optical Link Interface Requirements has been submitted
>(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )
>
>Please review the draft and comment (to _this_ list) on the following:
>1) Are the requirements stated useful?

Yes.

>2) Are there useful requirements that are missing?

So far so good

>3) Do you think that this document should be a CCAMP WG document?
>    a) as it stands today?
>    b) only if it changed?
>    c) no, no matter what surgery is done on it?
>    d) yawn ...

a)

>Extra points for terse, technical and temperate comments.
>
>We'd like to judge the sentiment towards this draft in a week or two,
>so if you'd like your comments to be acted upon, send them soon.
>
>Thanks,
>Kireeti & Vijay.

Yong Xue, Distinguished Technical Member
NG IP Technology and Architecture
UUNET/WorldCom
Ashburn, Virginia
(703)-886-5358
[email-masked]

Delivery-date: Tue, 19 Jun 2001 12:14:30 -0700
Date: Tue, 19 Jun 2001 12:13:22 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: OLI requirements

At the capacity of one of the co-authors....

Kireeti Kompella wrote:

> Hi All,
>
> A document on Optical Link Interface Requirements has been submitted
> (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )
>
> Please review the draft and comment (to _this_ list) on the following:
> 1) Are the requirements stated useful?

Yes.

>
> 2) Are there useful requirements that are missing?

Will revise if we find any missing.

>
> 3) Do you think that this document should be a CCAMP WG document?
>    a) as it stands today?
>    b) only if it changed?
>    c) no, no matter what surgery is done on it?
>    d) yawn ...
>

a

>
> Extra points for terse, technical and temperate comments.
>
> We'd like to judge the sentiment towards this draft in a week or two,
> so if you'd like your comments to be acted upon, send them soon.
>
> Thanks,
> Kireeti & Vijay.

- sudheer

Delivery-date: Tue, 19 Jun 2001 12:08:50 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-mpls-lmp-02.txt
Date: Tue, 19 Jun 2001 21:07:31 +0200

Dear Kireeti,

Yes I think that this draft should become a CCAMP WG document, it is an
important part of the GMPLS architecture and it is a good document.

Kind regards,

Eric

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 4:04 AM
To: [email-masked]
Subject: draft-ietf-mpls-lmp-02.txt

Hi All,

Once upon a time, there was consensus to make the above document
(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
an MPLS WG document.

It now falls under the purvey of CCAMP.  Question: do you think this
document should be a CCAMP WG document?  (You know the drill ....)

Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 11:35:50 -0700
From: Ayan Banerjee <[email-masked]>
To: [email-masked]
Subject: RE: OLI requirements
Date: Tue, 19 Jun 2001 11:29:27 -0700

I beleive that this should be CCAMP WG document. 

Thanks,
Ayan

-----Original Message-----
From: Andre Fredette [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 10:47 AM
To: [email-masked]
Subject: Re: OLI requirements

I may be a bit biased given that I'm one of the authors, but here are my 
opinions:

At 06:21 PM 6/18/2001 -0700, Kireeti Kompella wrote:
>Hi All,
>
>A document on Optical Link Interface Requirements has been submitted
>(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )
>
>Please review the draft and comment (to _this_ list) on the following:
>1) Are the requirements stated useful?

Yes.

>2) Are there useful requirements that are missing?

Possibly.

>3) Do you think that this document should be a CCAMP WG document?
>    a) as it stands today?
>    b) only if it changed?
>    c) no, no matter what surgery is done on it?
>    d) yawn ...

a)

>Extra points for terse, technical and temperate comments.
>
>We'd like to judge the sentiment towards this draft in a week or two,
>so if you'd like your comments to be acted upon, send them soon.
>
>Thanks,
>Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 11:13:58 -0700
Date: Tue, 19 Jun 2001 20:12:43 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Fong Liaw <[email-masked]>
CC: [email-masked]
Subject: Re: draft-fontana-gmpls-control-g709-00.txt

This is a multi-part message in MIME format.
--------------5E3A5F798662A309F6C5EE5C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Fong,

To respond to your question about the TSpec: since
this version was published prior to the decision
made during the last Minneapolis meeting it doesn't 
comply to it. The next version to be presented 
during the London Meeting will be aligned with 
the "Technology Specific extensions".

Regards,
Dimitri.

Fong Liaw wrote:
> 
> Yes, this draft is useful and a good start.
> 
> One quick comment.
> 
> Why did this draft not use Sender-Tspec to encode the
> signal type, transparency, OOS field. I believe
> this is the agreed approach to do technology
> specific extensions.
> 
> I also think it would be good to change the
> code point of digital wrapper and lambda as
> suggested by this draft in the GMPLS-SIG.
> Or take the code point out of GMPLS-SIG
> LSP encoding type code point, and define it here.
> The latter is better, given that this draft just
> come out.
> 
> Regards,
> -Fong
--------------5E3A5F798662A309F6C5EE5C
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------5E3A5F798662A309F6C5EE5C--

Delivery-date: Tue, 19 Jun 2001 11:05:55 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 19 Jun 2001 11:00:18 -0700

Hi Eric,
          Thanks for the reply. I have one more doubt :

A STM-64 interface consist of 64 STM-1s that are byte interleaved. If
I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT
with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0,
MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to
allocate contiguous VC-4s in STM-64 link.
Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link.
Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal)
i.e. only one label will be passed in RESV/Label Mapping message. The
receiving node will drive the subsequent labels from this onwards.

In case of arbitrary or virtual concatenation, Can I allocate non
-contiguous signals from a link ? The label corresponding to each
arbitrary or virtually concatenated signal will be passed in
RESV/Mapping message.

If I have a STM-64 interface configured, and no signal is allocated yet from 
the link.
If I have to allocate a signal STM-3c-7v (virtual concatenation of 7 
STM-3c), Can I allocate the whole signal from this link ?

Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have to 
pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0}, 
{7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ].

Does this mean that each STS-3c in STM-3c-7v should be contiguous ?

Please tell me if my understanding is correct.

Regards,
manoj.

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, [email-masked]
>Subject: RE: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
>Date: Tue, 19 Jun 2001 10:02:56 +0200
>
>Hello Manoj,
>
>The virtual concatenation is indicated in a separate field (NVC). The 
>reason
>is to allow to code the virtual concatenation of contiguously concatenated
>signals (like the virtual concatenation of several STS-3c's.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 3:03 AM
>To: [email-masked]
>Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt
>
>
>Hi,
>
>      I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :
>
>   The CCT field can have values no concatenation, standard
>concatenation, arbitrary, vendor specific.
>But why can't virtual concatenation ? It was there in original draft.
>But in the exmaples section for SDH/SONET signals, it is shown that a
>virtually concatenated signal can be built using NVC field with CCT
>value as 0. Please clarify the reason in doing so.
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>

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

Delivery-date: Tue, 19 Jun 2001 11:05:54 -0700
From: Fong Liaw <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: draft-fontana-gmpls-control-g709-00.txt
Date: Tue, 19 Jun 2001 11:00:04 -0700

Yes, this draft is useful and a good start.

One quick comment.

Why did this draft not use Sender-Tspec to encode the 
signal type, transparency, OOS field. I believe
this is the agreed approach to do technology 
specific extensions.

I also think it would be good to change the
code point of digital wrapper and lambda as
suggested by this draft in the GMPLS-SIG.  
Or take the code point out of GMPLS-SIG
LSP encoding type code point, and define it here.
The latter is better, given that this draft just
come out.

Regards,
-Fong

Delivery-date: Tue, 19 Jun 2001 10:48:54 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Date: Tue, 19 Jun 2001 13:46:57 -0400
Subject: Re: OLI requirements

I may be a bit biased given that I'm one of the authors, but here are my 
opinions:

At 06:21 PM 6/18/2001 -0700, Kireeti Kompella wrote:
>Hi All,
>
>A document on Optical Link Interface Requirements has been submitted
>(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )
>
>Please review the draft and comment (to _this_ list) on the following:
>1) Are the requirements stated useful?

Yes.

>2) Are there useful requirements that are missing?

Possibly.

>3) Do you think that this document should be a CCAMP WG document?
>    a) as it stands today?
>    b) only if it changed?
>    c) no, no matter what surgery is done on it?
>    d) yawn ...

a)

>Extra points for terse, technical and temperate comments.
>
>We'd like to judge the sentiment towards this draft in a week or two,
>so if you'd like your comments to be acted upon, send them soon.
>
>Thanks,
>Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 10:48:21 -0700
Date: Tue, 19 Jun 2001 13:43:33 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: draft-fontana-gmpls-control-g709-00.txt

Hi,

This is definitely useful work. I would consider this parallel document
to the SONET/SDH document within the GMPLS umbrella.

Zhi

Kireeti Kompella wrote:
> 
> Hi All,
> 
> There is a draft on signaling for G.709 networks, URL:
> http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt
> 
> Please send comments to the CCAMP mailing list on whether you
> think that this draft should be made a CCAMP WG document or not,
> and why:
>    a) yes, this draft is pretty good as it stands;
>    b) yes, this draft needs some work, but is okay;
>    c) no,  this draft is all wrong, but signaling in G.709 networks
>       is something that the IETF should be working on;
>    d) no,  this is not a subject that the IETF should touch.
> 
> (Just to make it clear: this proposal is not an architecture, or even
>  a re-architecture of G.709 -- that work belongs in the ITU.)
> 
> Thanks,
> Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 10:44:56 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Date: Tue, 19 Jun 2001 13:42:43 -0400
Subject: Re: draft-ietf-mpls-lmp-02.txt

I agree that LMP should become a CCAMP WG document.

LMP performs some very useful functions for the "Common Control" protocols 
the working group is chartered to specify.

Andre

At 07:04 PM 6/18/2001 -0700, Kireeti Kompella wrote:
>Hi All,
>
>Once upon a time, there was consensus to make the above document
>(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
>an MPLS WG document.
>
>It now falls under the purvey of CCAMP.  Question: do you think this
>document should be a CCAMP WG document?  (You know the drill ....)
>
>Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 10:32:36 -0700
Date: Tue, 19 Jun 2001 19:31:36 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt

This is a multi-part message in MIME format.
--------------D248CC99160284176E859AB4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

Yes, it should be a CCAMP WG document.

- Dimitri.

Kireeti Kompella wrote:
> 
> Hi All,
> 
> Once upon a time, there was consensus to make the above document
> (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
> an MPLS WG document.
> 
> It now falls under the purvey of CCAMP.  Question: do you think this
> document should be a CCAMP WG document?  (You know the drill ....)
> 
> Kireeti & Vijay.
--------------D248CC99160284176E859AB4
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------D248CC99160284176E859AB4--

Delivery-date: Tue, 19 Jun 2001 10:11:26 -0700
From: Jimmy Gendron <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: OIF UNI - Link verification
Date: Tue, 19 Jun 2001 13:10:30 -0400

Hi,

When you're doing link verification (following the UNI 1.0 specs), you can
send Test messages over these transport mechanisms: J0 OH, Section/line DCC
OH or POS. How is the Test messages are sent over POS? 

Thank you,

Jimmy

Envelope-to: [email-masked]
Delivery-date: Tue, 19 Jun 2001 10:01:06 -0700
Message-Id: <[email-masked]>
To: Yong Xue <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt 
Date: Tue, 19 Jun 2001 12:58:49 -0400
From: George Swallow <[email-masked]>

Yes, clearly this document has some consensus behind it.  

,,,George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Tue, 19 Jun 2001 09:42:39 -0700
From: Martin Dubuc <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: draft-ietf-mpls-lmp-02.txt
Date:  Tue, 19 Jun 2001 12:39:33 -0400

I also agree that LMP should be a CCAMP document and would also like to see
it explicitly added to CCAMP charter.

Martin

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, June 18, 2001 10:04 PM
To: [email-masked]
Subject: draft-ietf-mpls-lmp-02.txt

Hi All,

Once upon a time, there was consensus to make the above document
(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
an MPLS WG document.

It now falls under the purvey of CCAMP.  Question: do you think this
document should be a CCAMP WG document?  (You know the drill ....)

Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 09:12:13 -0700
Date: Tue, 19 Jun 2001 12:09:59 -0400 (EDT)
From: Yong Xue <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt

I think lmp should be a ccamp wg document, at the same time second
Tom's suggestion to add lmp into the charter.

/Yong

On Tue, 19 Jun 2001, Thomas D. Nadeau wrote:

> 
> >Once upon a time, there was consensus to make the above document
> >(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
> >an MPLS WG document.
> >
> >It now falls under the purvey of CCAMP.  Question: do you think this
> >document should be a CCAMP WG document?  (You know the drill ....)
> 
>          Yes, I think that it should be a CCAMP wg document.
> However, in leu of the recent discussions regarding
> whether drafts are in or out of charter, I suggest that
> we explicitly add LMP to the charter to put to rest
> any doubts of its applicability to ccamp.
> 
>          --Tom
> 
> 
> 
> 
> 

Delivery-date: Tue, 19 Jun 2001 07:51:52 -0700
From: "Dawkins, Spencer" <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-mpls-lmp-02.txt
Date: Tue, 19 Jun 2001 09:45:33 -0500

I would say

yes, a workgroup document, and this draft looks pretty good as it stands.

Spencer

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, June 18, 2001 9:04 PM
To: [email-masked]
Subject: draft-ietf-mpls-lmp-02.txt

Hi All,

Once upon a time, there was consensus to make the above document
(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
an MPLS WG document.

It now falls under the purvey of CCAMP.  Question: do you think this
document should be a CCAMP WG document?  (You know the drill ....)

Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 07:46:59 -0700
From: [email-masked]
Date: Tue, 19 Jun 2001 09:41:59 -0500
Subject: RE: draft-ietf-mpls-lmp-02.txt
TO: [email-masked], [email-masked]

--openmail-part-42085a2b-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Tue, 19 Jun 2001 09:41:59 -0500"
Content-Transfer-Encoding: 7bit

Yes. this should be a WG document.

Ananth

-----Original Message-----
From: kireeti [mailto:[email-masked]]
Sent: Monday, June 18, 2001 9:04 PM
To: ccamp
Cc: kireeti
Subject: draft-ietf-mpls-lmp-02.txt

Hi All,

Once upon a time, there was consensus to make the above document
(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt 
)
an MPLS WG document.

It now falls under the purvey of CCAMP.  Question: do you think this
document should be a CCAMP WG document?  (You know the drill ....)

Kireeti & Vijay.

--openmail-part-42085a2b-00000001--

Delivery-date: Tue, 19 Jun 2001 07:31:59 -0700
From: [email-masked]
Date: Tue, 19 Jun 2001 09:23:37 -0500
Subject: RE: draft-fontana-gmpls-control-g709-00.txt
TO: [email-masked], [email-masked]

--openmail-part-42074c60-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Tue, 19 Jun 2001 09:23:37 -0500"
Content-Transfer-Encoding: 7bit

This is definitely useful work, and a good start. This should be made a 
WG document.

Thanks,
Ananth

-----Original Message-----
From: kireeti [mailto:[email-masked]]
Sent: Monday, June 18, 2001 9:00 PM
To: ccamp
Cc: kireeti
Subject: draft-fontana-gmpls-control-g709-00.txt

Hi All,

There is a draft on signaling for G.709 networks, URL:
http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt

Please 
send comments to the CCAMP mailing list on whether you
think that this draft should be made a CCAMP WG document or not,
and why:
   a) yes, this draft is pretty good as it stands;
   b) yes, this draft needs some work, but is okay;
   c) no,  this draft is all wrong, but signaling in G.709 networks
      is something that the IETF should be working on;
   d) no,  this is not a subject that the IETF should touch.

(Just to make it clear: this proposal is not an architecture, or even
 a re-architecture of G.709 -- that work belongs in the ITU.)

Thanks,
Kireeti & Vijay.

--openmail-part-42074c60-00000001--

Delivery-date: Tue, 19 Jun 2001 06:41:15 -0700
Date: Tue, 19 Jun 2001 09:39:04 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-mpls-lmp-02.txt

I think so,

Yangguang

Kireeti Kompella wrote:
> 
> Hi All,
> 
> Once upon a time, there was consensus to make the above document
> (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
> an MPLS WG document.
> 
> It now falls under the purvey of CCAMP.  Question: do you think this
> document should be a CCAMP WG document?  (You know the drill ....)
> 
> Kireeti & Vijay.

Delivery-date: Tue, 19 Jun 2001 05:27:46 -0700
Date: Tue, 19 Jun 2001 08:27:43 -0400
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: draft-ietf-mpls-lmp-02.txt

>Once upon a time, there was consensus to make the above document
>(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
>an MPLS WG document.
>
>It now falls under the purvey of CCAMP.  Question: do you think this
>document should be a CCAMP WG document?  (You know the drill ....)

         Yes, I think that it should be a CCAMP wg document.
However, in leu of the recent discussions regarding
whether drafts are in or out of charter, I suggest that
we explicitly add LMP to the charter to put to rest
any doubts of its applicability to ccamp.

         --Tom

Delivery-date: Tue, 19 Jun 2001 01:06:21 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 19 Jun 2001 10:02:56 +0200

Hello Manoj,

The virtual concatenation is indicated in a separate field (NVC). The reason
is to allow to code the virtual concatenation of contiguously concatenated
signals (like the virtual concatenation of several STS-3c's.

Kind regards,

Eric

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 3:03 AM
To: [email-masked]
Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt

Hi,

     I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :

  The CCT field can have values no concatenation, standard
concatenation, arbitrary, vendor specific.
But why can't virtual concatenation ? It was there in original draft.
But in the exmaples section for SDH/SONET signals, it is shown that a
virtually concatenated signal can be built using NVC field with CCT
value as 0. Please clarify the reason in doing so.

Regards,
manoj.

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

Envelope-to: [email-masked]
Delivery-date: Mon, 18 Jun 2001 19:05:16 -0700
Date: Mon, 18 Jun 2001 19:04:12 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: draft-ietf-mpls-lmp-02.txt

Hi All,

Once upon a time, there was consensus to make the above document
(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt )
an MPLS WG document.

It now falls under the purvey of CCAMP.  Question: do you think this
document should be a CCAMP WG document?  (You know the drill ....)

Kireeti & Vijay.

Envelope-to: [email-masked]
Delivery-date: Mon, 18 Jun 2001 19:00:36 -0700
Date: Mon, 18 Jun 2001 18:59:48 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: draft-fontana-gmpls-control-g709-00.txt

Hi All,

There is a draft on signaling for G.709 networks, URL:
http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt

Please send comments to the CCAMP mailing list on whether you
think that this draft should be made a CCAMP WG document or not,
and why:
   a) yes, this draft is pretty good as it stands;
   b) yes, this draft needs some work, but is okay;
   c) no,  this draft is all wrong, but signaling in G.709 networks
      is something that the IETF should be working on;
   d) no,  this is not a subject that the IETF should touch.

(Just to make it clear: this proposal is not an architecture, or even
 a re-architecture of G.709 -- that work belongs in the ITU.)

Thanks,
Kireeti & Vijay.

Envelope-to: [email-masked]
Delivery-date: Mon, 18 Jun 2001 18:22:27 -0700
Date: Mon, 18 Jun 2001 18:21:33 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: OLI requirements

Hi All,

A document on Optical Link Interface Requirements has been submitted
(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt )

Please review the draft and comment (to _this_ list) on the following:
1) Are the requirements stated useful?
2) Are there useful requirements that are missing?
3) Do you think that this document should be a CCAMP WG document?
   a) as it stands today?
   b) only if it changed?
   c) no, no matter what surgery is done on it?
   d) yawn ...

Extra points for terse, technical and temperate comments.

We'd like to judge the sentiment towards this draft in a week or two,
so if you'd like your comments to be acted upon, send them soon.

Thanks,
Kireeti & Vijay.

Delivery-date: Mon, 18 Jun 2001 18:05:37 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubt in draft  ccamp-gmpls-sonet-sdh-00.txt
Date: Mon, 18 Jun 2001 18:03:03 -0700

Hi,

     I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt :

  The CCT field can have values no concatenation, standard
concatenation, arbitrary, vendor specific.
But why can't virtual concatenation ? It was there in original draft.
But in the exmaples section for SDH/SONET signals, it is shown that a
virtually concatenated signal can be built using NVC field with CCT
value as 0. Please clarify the reason in doing so.

Regards,
manoj.

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

Delivery-date: Thu, 14 Jun 2001 08:23:37 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Thu, 14 Jun 2001 11:20:21 -0400

I beg to disagree with some of the contents.
There will be an optical address (which could be in the IP format) At the
higher layer there will be an IP address for devices or an NSAP address for
ATM devices. 
Otherwise I agree with the main point - there is separate control at each
layer.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

 -----Original Message-----
From: 	Mannie, Eric [mailto:[email-masked]] 
Sent:	Thursday, June 14, 2001 4:12 AM
To:	[email-masked]'; [email-masked]
Cc:	[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject:	RE: GMPLS issues (was - GMPLS Last Calls)

Hello Ananth,

>The requirement is to support non-IP  addresses at the edge (this may
include NSAP) and 
>translate/encapsulate to a routable IP address in the core (a la in a 
>VPN scenario, where non-unique, non-IP addresses may be supported). 
>i.e, support just IP-based routing in the optical control plane.

One can support whatever you like at the edge/host. A layer above any GMPLS
controlled layer may use its own addressing, routing and signaling
independently.

For instance, if you want to use ATM with PNNI and NSAP addresses above a
photonic layer controlled by GMPLS that's fine. That should not have any
impact on GMPLS (layer independencies). An end-system will have two
addresses, one at the ATM layer and one at the IP layer for the GMPLS driver
of the photonic layer. In the same way an IP router has IP addresses at the
IP layer and ATM addresses associated with ATM drivers.

The address translation (from a "logical X address" to "physical IP
address") issue can be solved in many ways (DNS, static, via an address
resolution protocol (many were already designed), via routing integration,
etc). I don't believe that this should be embedded in the signaling protocol
used to open and maintain circuits. Too many non-related features in the
same protocol makes it more complex. So again, no impact on GMPLS.

Kind regards,

Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 9:07 PM
To: [email-masked]; Mannie, Eric
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Eric and others,
I think the NSAP support issue is being misunderstood. The requirement 
is to support non-IP  addresses at the edge (this may include NSAP) and 
translate/encapsulate to a routable IP address in the core (a la in a 
VPN scenario, where non-unique, non-IP addresses may be supported). 
i.e, support just IP-based routing in the optical control plane.
hope this helps clarify.

Ananth

-----Original Message-----
From: Eric.Mannie [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 5:32 AM
To: Nagarajan, Ananth; BRaja
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Hello Ananth,

>bala>> > 1) Type of legacy equipment needing NSAP addresses 
>bala>> > (also, is
>bala>> > this optical network element or client equipment?)
>bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
>bala>> > (2002, 2005, and 2010)
>bala>> > 3) Description of application in which this legacy equipment 
>bala>> > will use UNI
>bala>> > signaling
>bala>I don't recall seeing any response. furthermore, the NSAP
>bala>requirement was not unanimously endorsed by all carriers (at
>bala>the OIF). 
>
>From our OIF representatives, although it was not unanimously 
endorsed, 
>there was a significant demand for NSAP support. Well, NSAP is the 
main 
>non-IP type of addressing that is required. The general requirement is 
>to be able to support non-IP addresses (probably have an address 
>translation from non-IP addresses to routable addresses).
>NSAP support will be needed always (e.g. support for legacy DCC that 
>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can 
have an
IP stack and any other kind of stack using any other kind of addresses. 
The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The 
fact
that you have for instance a TMN stack using NSAP addresses is 
completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission 
network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's 
are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use 
IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP 
address
inside the NSAP address if you have a dual stack running on the box, 
that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP 
address and
I have to check what we do for the TMN stack. I think that it is 
transported
over IP, maybe using RFC1006. If I remember correctly we only configure 
an
IP address on the DWDM box. In that case, I presume that TSAP's are 
build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), 
and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for 
the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers 
and
their operations are independent of the nodes that we want to 
manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old 
equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is 
some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and 
GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in 
IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. 
The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the 
other
stacks that are already running.

Where is the issue ? Why do we need NSAP addresses in GMPLS ?

Kind regards,

Eric

Delivery-date: Thu, 14 Jun 2001 01:14:22 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Thu, 14 Jun 2001 10:11:48 +0200

Hello Ananth,

>The requirement is to support non-IP  addresses at the edge (this may
include NSAP) and 
>translate/encapsulate to a routable IP address in the core (a la in a 
>VPN scenario, where non-unique, non-IP addresses may be supported). 
>i.e, support just IP-based routing in the optical control plane.

One can support whatever you like at the edge/host. A layer above any GMPLS
controlled layer may use its own addressing, routing and signaling
independently.

For instance, if you want to use ATM with PNNI and NSAP addresses above a
photonic layer controlled by GMPLS that's fine. That should not have any
impact on GMPLS (layer independencies). An end-system will have two
addresses, one at the ATM layer and one at the IP layer for the GMPLS driver
of the photonic layer. In the same way an IP router has IP addresses at the
IP layer and ATM addresses associated with ATM drivers.

The address translation (from a "logical X address" to "physical IP
address") issue can be solved in many ways (DNS, static, via an address
resolution protocol (many were already designed), via routing integration,
etc). I don't believe that this should be embedded in the signaling protocol
used to open and maintain circuits. Too many non-related features in the
same protocol makes it more complex. So again, no impact on GMPLS.

Kind regards,

Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 9:07 PM
To: [email-masked]; Mannie, Eric
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Eric and others,
I think the NSAP support issue is being misunderstood. The requirement 
is to support non-IP  addresses at the edge (this may include NSAP) and 
translate/encapsulate to a routable IP address in the core (a la in a 
VPN scenario, where non-unique, non-IP addresses may be supported). 
i.e, support just IP-based routing in the optical control plane.
hope this helps clarify.

Ananth

-----Original Message-----
From: Eric.Mannie [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 5:32 AM
To: Nagarajan, Ananth; BRaja
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Hello Ananth,

>bala>> > 1) Type of legacy equipment needing NSAP addresses 
>bala>> > (also, is
>bala>> > this optical network element or client equipment?)
>bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
>bala>> > (2002, 2005, and 2010)
>bala>> > 3) Description of application in which this legacy equipment 
>bala>> > will use UNI
>bala>> > signaling
>bala>I don't recall seeing any response. furthermore, the NSAP
>bala>requirement was not unanimously endorsed by all carriers (at
>bala>the OIF). 
>
>From our OIF representatives, although it was not unanimously 
endorsed, 
>there was a significant demand for NSAP support. Well, NSAP is the 
main 
>non-IP type of addressing that is required. The general requirement is 
>to be able to support non-IP addresses (probably have an address 
>translation from non-IP addresses to routable addresses).
>NSAP support will be needed always (e.g. support for legacy DCC that 
>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can 
have an
IP stack and any other kind of stack using any other kind of addresses. 
The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The 
fact
that you have for instance a TMN stack using NSAP addresses is 
completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission 
network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's 
are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use 
IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP 
address
inside the NSAP address if you have a dual stack running on the box, 
that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP 
address and
I have to check what we do for the TMN stack. I think that it is 
transported
over IP, maybe using RFC1006. If I remember correctly we only configure 
an
IP address on the DWDM box. In that case, I presume that TSAP's are 
build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), 
and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for 
the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers 
and
their operations are independent of the nodes that we want to 
manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old 
equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is 
some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and 
GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in 
IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. 
The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the 
other
stacks that are already running.

Where is the issue ? Why do we need NSAP addresses in GMPLS ?

Kind regards,

Eric

Delivery-date: Wed, 13 Jun 2001 17:18:21 -0700
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>, John Drake <[email-masked]>, [email-masked],  [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 17:12:50 -0700

Comments in line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 3:41 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Hi John,

You observed 13 June 2001 16:20
> 
> Niel,
> 
> I think that the point that Eric was trying to make is that 
> the IETF isn't
> the correct venue
> for a PNNI based solution, although a PNNI based solution might be a
> perfectly fine thing.
NH=> Many thanks for acknowledging this.......and as both a signalling
expert and co-author of the PNNI specification your view should carry some
weight.

JD:  Um, I was just trying to be nice.  I don't have any idea of it
could actually work, and it is, shall we say, a stabilized protocol.

> 
> From a technical perspective, unless things have changed in 
> the past several
> years, the issues
> with using PNNI are its lack of support for 
> pre-emption/priority and make
> before break, and that
> its bandwidth advertisements are tightly coupled to ATM 
> service categories.
NH=> But PNNI seems as though it can more easily adapted to the required
job.  

JD:  This sounds suspiciously like an assertion.

It has certain features that make it quite attractive like:
-	mature/tested, already deployed and understood
-	proven carrier-strength

JD:  I think the whole point of GMPLS is that the same could be said of
the IP suite of protocols.

-	multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI

JD:  What are E-NNI and I-NNI?  Also, at least when I looked at AINI, it
had lots of problems with looping behavior and I don't know if they were
fixed.

-	separate link and signalling protocols, eg SSCOP keepalives separate
from signalling, allows more physical interfaces not just connections per
interface

JD:  The same is provided by LMP wrt routing and signalling protocols, and
link bundling provides better scalability wrt more physical interfaces than
PNNI which doesn't have a similar concept. 

-	supports crankback.....something now slated to be addded to
RSVP/CR-LDP I assume?
-	supports static routed interfaces (AINI)....seems essential for
inter-operator case;

JD:  GMPLS has this.

-	support for address translation

JD:  Not clear what you're referring to.

-	supports S-PVC-type service

JD:  GMPLS has this.

-	Logical Group Node concept provides powerful features, eg hides
interior behaviour, allows centralised signalling and/or path computation,
border nodes not burdened with higher layers, supports any topology, each
peer group can have a different internal behaviour, etc;

JD:  I think you're referring to peer groups.  In practice they were pretty
nasty to configure properly, and I don't think they have all of the
attributes
you've given them.  

-	good for phased migration (this is an importnat issue for
operators);

JD:  Given that ATM, like IP, is a service, I don't see why there would be 
any reason to prefer PNNI over GMPLS. 

-	centralised route computation may be better for OTNs.....this would
be allowed;

JD:  PNNI doesn't have this intrinsically and GMPLS would support it just
as easily. 

-	separate signalling and routing means just signalling part can be
used

JD:  I think that PNNI signalling and routing are much more tightly coupled
than their GMPLS counterparts.  Further, Eric Mannie designed in specific
support in GMPLS for signalling only deployments.

-	etc

It would, however, need some minor additional work to adapt it for SDH/OTN
as you note......like BW advertisements.

JD:  It's only minor until you actually start to work out the details.

BTW- we have significant experience of trying to run multiple pre-emption
schemes and found it not so useful.  So this is one aspect we would want,
and if it was present we would want to be able to turn it off.

JD:  GMPLS has only a single pre-emption scheme.

Regards, Neil

Delivery-date: Wed, 13 Jun 2001 17:14:14 -0700
From: "Don Fedyk" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 20:13:02 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F466.C699BEA0
Content-Type: text/plain;
	charset="iso-8859-1"

Neil

You have made some pretty far reaching arguments. We also evaluated 
these schemes when we started GMPLS. It is my opinion we chose the 
route because we thought the IP-MPLS synergy in routing was strong. 
We run OSPF or IS-IS + BGP and we kill the overhead of having two 
routing systems with all the ills that go with it. There was also 
as John Drake mentioned more flexibility in adoption of capabilities. 
We tried once to put these in ATM and were shut down. Only after 
several years crank back solutions were introduced with still with 
some inflexible resistance.

Next we looked at the signaling protocols and we fought hard to get 
flexibility and a connection oriented behavior. It is my opinion that 
CR-LDP was the best suited for this and we still use this model 
but we have conceded at present to talking to most of the routers 
with RSVP-TE. The signaling protocol is really not most of the 
work it is the flexibility we were striving for and with the 
exception of refresh the two protocols stay closely in synch.

As far as addressing everyone seem to agree that we can add 
external addresses that have nothing to do with the core addressing 
so this is not about addressing. 

It is my opinion the best place to do this work has been the IETF 
over the last few years and here we use IP protocols. It has been 
the most responsive to the work to date. I don't see this suddenly 
changing and while you are right about it will look a lot like ATM 
when we get through that is because it is a connection oriented problem.

Don

------_=_NextPart_001_01C0F466.C699BEA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: GMPLS issues (was - GMPLS Last Calls)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Neil</FONT>
</P>

<P><FONT SIZE=2>You have made some pretty far reaching arguments. We also evaluated </FONT>
<BR><FONT SIZE=2>these schemes when we started GMPLS. It is my opinion we chose the </FONT>
<BR><FONT SIZE=2>route because we thought the IP-MPLS synergy in routing was strong. </FONT>
<BR><FONT SIZE=2>We run OSPF or IS-IS + BGP and we kill the overhead of having two </FONT>
<BR><FONT SIZE=2>routing systems with all the ills that go with it. There was also </FONT>
<BR><FONT SIZE=2>as John Drake mentioned more flexibility in adoption of capabilities. </FONT>
<BR><FONT SIZE=2>We tried once to put these in ATM and were shut down. Only after </FONT>
<BR><FONT SIZE=2>several years crank back solutions were introduced with still with </FONT>
<BR><FONT SIZE=2>some inflexible resistance.</FONT>
</P>

<P><FONT SIZE=2>Next we looked at the signaling protocols and we fought hard to get </FONT>
<BR><FONT SIZE=2>flexibility and a connection oriented behavior. It is my opinion that </FONT>
<BR><FONT SIZE=2>CR-LDP was the best suited for this and we still use this model </FONT>
<BR><FONT SIZE=2>but we have conceded at present to talking to most of the routers </FONT>
<BR><FONT SIZE=2>with RSVP-TE. The signaling protocol is really not most of the </FONT>
<BR><FONT SIZE=2>work it is the flexibility we were striving for and with the </FONT>
<BR><FONT SIZE=2>exception of refresh the two protocols stay closely in synch.</FONT>
</P>

<P><FONT SIZE=2>As far as addressing everyone seem to agree that we can add </FONT>
<BR><FONT SIZE=2>external addresses that have nothing to do with the core addressing </FONT>
<BR><FONT SIZE=2>so this is not about addressing. </FONT>
</P>

<P><FONT SIZE=2>It is my opinion the best place to do this work has been the IETF </FONT>
<BR><FONT SIZE=2>over the last few years and here we use IP protocols. It has been </FONT>
<BR><FONT SIZE=2>the most responsive to the work to date. I don't see this suddenly </FONT>
<BR><FONT SIZE=2>changing and while you are right about it will look a lot like ATM </FONT>
<BR><FONT SIZE=2>when we get through that is because it is a connection oriented problem.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F466.C699BEA0--

Delivery-date: Wed, 13 Jun 2001 15:42:39 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 23:40:48 +0100

Hi John.....You could do this, but I don't believe this is pertinent to what
I was discussing.  See my response to Eric.

Regards, Neil

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 13 June 2001 15:59
> To: 'Mannie, Eric'; [email-masked]';
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: GMPLS issues (was - GMPLS Last Calls)
> 
> 
> Also, an ATM service using NSAP addresses for customer ports 
> could be built
> on top of a GMPLS core using IP addresses internally.  The ATM service
> delivery switches could use the GMPLS core to provison 
> lighpaths between
> themselves and then run
> PNNI as an overlay network for purposes of exchanging NSAP 
> reachability
> information. 
> 
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2001 7:33 AM
> To: [email-masked]'; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: GMPLS issues (was - GMPLS Last Calls)
> 
> 
> Hello Neil,
> 
> >Given that the layers have to be decoupled in the general case (for
> >commercial as well as technical reasons - see the BT 'Freeland'
> requirements
> >draft to 12/00 mtg) then there seems to be no reason why an 
> operator could
> >not use NSAPs for the access points of SDH or OTNs if he so 
> wished.  And,
> >given this choice, that operator might also prefer to use PNNI as the
> >signalling/routing solution too.  So, the issue seems not one of
> >'necesssity' but simply choice......though there may be 
> certain technical
> >benefits of choosing 1 solution over another.  I don't 
> believe there is
> >anything technically wrong with saying this and giving 
> operators/vendors a
> >choice here is there?.....if there is please point out the problems.
> 
> If somebody wants to use PNNI, it is not our business. The 
> choice between a
> GMPLS control plane and a PNNI control plane is not in our 
> scope. We are
> here working on GMPLS at the IETF, not on PNNI at the ATM 
> Forum and not on
> G.ASON at the ITU-T.
> 
> GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with 
> NSAP addresses.
> I don't think that somebody will choose a control plane only 
> because it uses
> IP or NSAP addresses, this doesn't make sense to me. There 
> are much more
> important distinctions between the two control planes than 
> the format of the
> addresses.
> 
> Technically I don't see arguments to adapt GMPLS to NSAP 
> addresses, or to
> AppleTalk addresses or to any kind of addresses that some people could
> prefer, or that could come from another standardization body.
> 
> If technically there is a clear benefit of using NSAP 
> addresses instead of
> IP addresses in GMPLS that should be demonstrated by 
> somebody. Up to now
> nobody made it (I think that when somebody wants to modify an 
> existing work
> in a standardization body this has to be justified with 
> technical reasons,
> not just by a personal preference). So I presume that there 
> is today no
> technical argument to use NSAP addresses in GMPLS.
> 
> Even if any benefit is demonstrated, that should be balanced with the
> disadvantages of supporting it and finaly the IETF should 
> decide if they
> want to adapt their protocols to other addressing schemes. 
> Personally, I
> don't think that this make sense.
> 
> Moreover, GMPLS is IP centric and this is one of its driving 
> forces. I don't
> see the interest of transforming an IP centric control plane 
> in a less IP
> centric control plane. This is going in the opposite 
> direction of what we
> are trying to do.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> EBONE (GTS)
> 

Delivery-date: Wed, 13 Jun 2001 15:42:37 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls) 
Date: Wed, 13 Jun 2001 23:40:51 +0100

Hello Yakov.....

> 
> Please note that there is a way to carry NSAPs in IPv6 addresses,
> although it does not support all types of NSAPs.  (see rfc1888 for
> more details). Please also note that GMPLS supports IPv6 (as well
> as IPv4). Finally, please note that a "perfect" solution (the one
> that addresses all the requirements of everyone) is a *non* goal
> for GMPLS.
NH=> That is a fair point.  Indeed, it is looking at a best fit from our
perspective that is driving us......and I feel sure our position would be
reflected by many large/established carriers.  But you need to talk to the
right people in those carriers to get the true view.......I suspect these
people will not be tracking any of this discussion nor have looked at the
issues in depth yet.
> 
> > And,
> > given this choice, that operator might also prefer to use 
> PNNI as the
> > signalling/routing solution too.  So, the issue seems not one of
> > 'necesssity' but simply choice......though there may be 
> certain technical
> > benefits of choosing 1 solution over another.  I don't 
> believe there is
> > anything technically wrong with saying this and giving 
> operators/vendors a
> > choice here is there?.....if there is please point out the problems.
> 
> Few points:
> 
> 1. Providing multiple choices for performing essentially the same
> thing, especially if these choices have similar characteristics,
> doesn't help to develop multi-vendor interoperable solutions.
NH=> Agreed.  But who calls the shots here?
> 
> 2. The fact that in the IETF there are not one, but two link-state
> IGPs (OSPF and ISIS) is a bug, and not a feature. 
> 
> 3. The same applies for MPLS signalling (CR-LDP vs RSVP).
> 
> 4. Suggesting yet another routing/signalling protocol, in addition
> to GMPLS, is adding yet another bug (not a feature).
NH=> Some bugs are better than others I guess.
> 
> 5. I understand that BT submitted a contribution to the ITU
> suggesting PNNI as (yet another) routing/signalling for optical 
> cross connects.
NH=> Better bug?

regards, Neil 

Delivery-date: Wed, 13 Jun 2001 15:42:36 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 23:40:50 +0100

Hi John,

You observed 13 June 2001 16:20
> 
> Niel,
> 
> I think that the point that Eric was trying to make is that 
> the IETF isn't
> the correct venue
> for a PNNI based solution, although a PNNI based solution might be a
> perfectly fine thing.
NH=> Many thanks for acknowledging this.......and as both a signalling
expert and co-author of the PNNI specification your view should carry some
weight.
> 
> From a technical perspective, unless things have changed in 
> the past several
> years, the issues
> with using PNNI are its lack of support for 
> pre-emption/priority and make
> before break, and that
> its bandwidth advertisements are tightly coupled to ATM 
> service categories.
NH=> But PNNI seems as though it can more easily adapted to the required
job.  It has certain features that make it quite attractive like:
-	mature/tested, already deployed and understood
-	proven carrier-strength
-	multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI
-	separate link and signalling protocols, eg SSCOP keepalives separate
from signalling, allows more physical interfaces not just connections per
interface
-	supports crankback.....something now slated to be addded to
RSVP/CR-LDP I assume?
-	supports static routed interfaces (AINI)....seems essential for
inter-operator case;
-	support for address translation
-	supports S-PVC-type service
-	Logical Group Node concept provides powerful features, eg hides
interior behaviour, allows centralised signalling and/or path computation,
border nodes not burdened with higher layers, supports any topology, each
peer group can have a different internal behaviour, etc;
-	good for phased migration (this is an importnat issue for
operators);
-	centralised route computation may be better for OTNs.....this would
be allowed;
-	separate signalling and routing means just signalling part can be
used
-	etc

It would, however, need some minor additional work to adapt it for SDH/OTN
as you note......like BW advertisements.
BTW- we have significant experience of trying to run multiple pre-emption
schemes and found it not so useful.  So this is one aspect we would want,
and if it was present we would want to be able to turn it off.

Regards, Neil

Delivery-date: Wed, 13 Jun 2001 15:42:33 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 23:40:46 +0100

Hi Eric.....many thanks for your comments....couple of observations:
<snipped>
> 
> If somebody wants to use PNNI, it is not our business. The 
> choice between a
> GMPLS control plane and a PNNI control plane is not in our 
> scope. We are
> here working on GMPLS at the IETF, not on PNNI at the ATM 
> Forum and not on
> G.ASON at the ITU-T.
NH=>We have to consider that the control-plane is composed of 3 principlly
independent  facets (ie addressing, signalling and routing) and it unfair to
group them under a generic banner or forum heading.  We really should be
striving for best current practice here. 
> 
> GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with 
> NSAP addresses.
> I don't think that somebody will choose a control plane only 
> because it uses
> IP or NSAP addresses, this doesn't make sense to me. There 
> are much more
> important distinctions between the two control planes than 
> the format of the
> addresses.
NH=> The addressing is almost an irrelevance......the addressing used can be
anything provided it meets the requirements specified in the Freeland draft.
Clearly we would re-use an existing addressing scheme, and v6 and NSAPs look
good.  v4 does not look so good.
> 
> Technically I don't see arguments to adapt GMPLS to NSAP 
> addresses, or to
> AppleTalk addresses or to any kind of addresses that some people could
> prefer, or that could come from another standardization body.
NH=> I don't want to do this either.
> 
> If technically there is a clear benefit of using NSAP 
> addresses instead of
> IP addresses in GMPLS that should be demonstrated by 
> somebody. Up to now
> nobody made it (I think that when somebody wants to modify an 
> existing work
> in a standardization body this has to be justified with 
> technical reasons,
> not just by a personal preference). So I presume that there 
> is today no
> technical argument to use NSAP addresses in GMPLS.
NH=> Focusing on addressing here is a distraction......the attributes of an
address that are required are that (i) it should be large enough for any
possible growth, (ii) able to be properly structured to follow topology (for
sensible hierarchical and aggregation reasons....so some 'wasted' space is
not a bad thing) and (ii) that addresses are decoupled wrt cross-layer
allocation (server layer trails = client layer links.....it can't be put
more direct/obvious than that I think). 
> 
> Even if any benefit is demonstrated, that should be balanced with the
> disadvantages of supporting it and finaly the IETF should 
> decide if they
> want to adapt their protocols to other addressing schemes. 
> Personally, I
> don't think that this make sense.
NH=> I really think the addressing aspect is a bit of a
distraction.......the key issues are all about the choice of signalling
protocol and how the routing aspects are used.  I cannot believe that a
signalling protocol like RSVP whose orgins are from a Rx-controlled,
multicast, IP, soft-state, etc environment is better fit than PNNI.  This is
not an attack of RSVP per se, it is all about re-using best available
protocols for a given job.  As Jon Crowcroft said at the NSIS BOF at the
last mtg:
"Don't fix signaling protocols via new requirements, but give a new
direction in signaling requirements. PNNI specifications are excellently
written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing
RSVP until you have read all these protocols. We should not reinvent the
wheel and waste the time of the IETF.
[See ref: http://www.ietf.org/proceedings/01mar/index.html NSIS BOF]
It is my opinion that all you will end up doing is re-inventing PNNI, eg
recent crankback drafts.  Sure you can do this but why waste the time of the
IETF on this?
> 
> Moreover, GMPLS is IP centric and this is one of its driving 
> forces. I don't
> see the interest of transforming an IP centric control plane 
> in a less IP
> centric control plane. This is going in the opposite 
> direction of what we
> are trying to do.
NH=> I don't really want to get into this area, so I will be as brief as
possible....there is no IP in the SDH or OTN user-plane and, for us at
least, the client and SDH/OTN networks must be decoupled.  Sure you can
force an IP oriented solution but that is by choice....it is certainly not
forced by any technical or commercial necessity.  Please also note that a
significant (around 50% in some cases) of our SDH traffic demands actually
come from 'native' managed BW customers.....so these are not even client
networks (ie neither IP nor something else) that are under our management
domain.  These observations lead us to the conclusion that if a
control-plane is to be introduced (and please note this is not a sure-fire
certainty for SDH in any case for us....and I would urge operators to look
at their billing, OSS and current operational practices before reaching any
conclusions here) it should be chosen on best current practice principles.
Further, we cannot see any good business case for SVCs in either SDH or
OTNs....S-PVCs maybe.  Has anyone really talked to operators about
this....offering SVCs at SDH/OTN trail levels I mean?  I would be amazed if
valid business cases could be constructed......so if any operators out there
know how to do this, we would be very keen to understand the arguments.
So....observing that we are dealing with CO/cct-sw networks it would seem to
make sense to us to use a signalling protocol that was designed to control
such a fabric...and all I am saying here is that PNNI appears to be a better
fit than RSVP (provided it is coupled with the right OSS/service
environment, eg S-PVC like services 1st).

regards, Neil

Delivery-date: Wed, 13 Jun 2001 12:08:19 -0700
From: [email-masked]
Date: Wed, 13 Jun 2001 14:07:09 -0500
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

--openmail-part-4186299a-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Wed, 13 Jun 2001 14:07:09 -0500"
Content-Transfer-Encoding: 7bit

Eric and others,
I think the NSAP support issue is being misunderstood. The requirement 
is to support non-IP  addresses at the edge (this may include NSAP) and 
translate/encapsulate to a routable IP address in the core (a la in a 
VPN scenario, where non-unique, non-IP addresses may be supported). 
i.e, support just IP-based routing in the optical control plane.
hope this helps clarify.

Ananth

-----Original Message-----
From: Eric.Mannie [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 5:32 AM
To: Nagarajan, Ananth; BRaja
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Hello Ananth,

>bala>> > 1) Type of legacy equipment needing NSAP addresses 
>bala>> > (also, is
>bala>> > this optical network element or client equipment?)
>bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
>bala>> > (2002, 2005, and 2010)
>bala>> > 3) Description of application in which this legacy equipment 
>bala>> > will use UNI
>bala>> > signaling
>bala>I don't recall seeing any response. furthermore, the NSAP
>bala>requirement was not unanimously endorsed by all carriers (at
>bala>the OIF). 
>
>From our OIF representatives, although it was not unanimously 
endorsed, 
>there was a significant demand for NSAP support. Well, NSAP is the 
main 
>non-IP type of addressing that is required. The general requirement is 
>to be able to support non-IP addresses (probably have an address 
>translation from non-IP addresses to routable addresses).
>NSAP support will be needed always (e.g. support for legacy DCC that 
>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can 
have an
IP stack and any other kind of stack using any other kind of addresses. 
The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The 
fact
that you have for instance a TMN stack using NSAP addresses is 
completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission 
network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's 
are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use 
IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP 
address
inside the NSAP address if you have a dual stack running on the box, 
that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP 
address and
I have to check what we do for the TMN stack. I think that it is 
transported
over IP, maybe using RFC1006. If I remember correctly we only configure 
an
IP address on the DWDM box. In that case, I presume that TSAP's are 
build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), 
and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for 
the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers 
and
their operations are independent of the nodes that we want to 
manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old 
equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is 
some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and 
GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in 
IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. 
The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the 
other
stacks that are already running.

Where is the issue ? Why do we need NSAP addresses in GMPLS ?

Kind regards,

Eric

--openmail-part-4186299a-00000001--

Delivery-date: Wed, 13 Jun 2001 10:08:44 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Signal Type doubt in GMPLS
Date: Wed, 13 Jun 2001 10:06:43 -0700

Hi Eric,

     Thanks for the reply. But I have still one thing not clear. When we 
request AUG-16, does this mean the whole STM-16 without
transparency ?
Similarly, In case of sonet, if signal type is one of STS-1 SPE, STS 
Group-3, STS Group-12, means whole STS-X without transparency. But if the 
requested signal type is one of STS-1 STS-3, STS-12 means with transparency 
?

Regards,
manoj.

>From: "Mannie, Eric" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, [email-masked]
>Subject: RE: Signal Type doubt in GMPLS
>Date: Wed, 13 Jun 2001 10:04:40 +0200
>
>Hello Manoj,
>
> >Also, for signal types STM-1, STM-4 etc. it is written in braces
> >that "only when requesting transparency". What does this exactly mean ?
>
>When you request some transparency it means transparency in the SOH, so you
>don't just request some payload, you request something related to the frame
>itself. Some part of the SOH has to be delivered at the other end of the 
>LSP
>untouched. This can be achieved in several ways, e.g. simply forwarded
>untouched (and this doesn't require any new standard, e.g. you keep the DCC
>untouched and you forward it :-) by the intermediate nodes in the network,
>or tunnelled in some overhead bytes.
>
>We didn't want to use a VC type of signal with transparency because the SOH
>is not part of this VC, we used STM-N. This is much cleaner.
>
> >What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs.
>
>An AUG-X signal type means the space taken by the AUG-X, it is like a TUG 
>or
>VTG signal. That allows to open a circuit without specifying its content,
>your SDH framer will recognise the content automatically.
>
>For instance, I am a customer and I don't care about transparency. I am
>connected to a switch with an STM-4 interface. I want to open a circuit 
>with
>the bandwidth equivalent of an STM-1 whose content can change, e.g. first I
>structure it as 3 x VC-3's, later on I want one VC-4. I request an AUG-1
>circuit.
>
>Kind regards,
>
>Eric
>
>-----Original Message-----
>From: manoj juneja [mailto:[email-masked]]
>Sent: Tuesday, June 12, 2001 9:31 PM
>To: [email-masked]
>Subject: Signal Type doubt in GMPLS
>
>
>Hi,
>     I have certain doubts regarding signal type field in sonet-sdh 00.txt
>draft.
>
>What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs.
>
>When signal type is AUG-256, what does this exatly mean ?
>
>Also, for signal types STM-1, STM-4 etc. it is written in braces
>that "only when requesting transparency". What does this exactly mean ?
>
>Please help.
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>

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

Delivery-date: Wed, 13 Jun 2001 10:03:05 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: RE: GMPLS Sonet extensions
Date: Wed, 13 Jun 2001 10:01:23 -0700

Hi Maarten, et. al., some comments in line. I'm kinda curious that this very
fundamental topic (layering and GMPLS) isn't generating more reponses than
"flexible arbitrary unconstrained unrestricted universal concatenation" but
then again I'm not sure I want a repeat of the last debate :-).  I've cut
some of the text where Maarten indicated that we were aligned. See the <GB>
... </GB> comments below.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 3:01 AM
To: Bernstein, Greg
Cc: Diego Caviglia; Susumu Yoneda; [email-masked]; Jimmy Gendron;
[email-masked]
Subject: Re: GMPLS Sonet extensions

Greg,

See my notes inline.

Regards,

Maarten
"Bernstein, Greg" wrote:

> Now if a vendor chooses to integrate STS-1 and VT1.5
> switching in the same box its up to them whether they choose to separate
> these signaling control entities or combine them into one entity.  

Partly aligned here... Within one vendor's subnetwork I agree that a
vendor may choose to do this. But when the other switch is outside that
vendor's subnetwork, the signaling protocol would have to meet the
standard interface specification, which for ASON will have separate
signalling control entities.

<GB> I was thinking of a fine grained VT1.5 switch that could also do some
STS-Nc level switching.  And hence the call processing entity (internal) may
be combined for both layers. And also the entities may have the same IP
address to the outside world.  The signaling interface specification would
have to be met. But, what do you mean by separate signalling control
entities? Do you want to be able to monitor the signaling activities for
each layer separately? Do you want to be able perform certain signaling
management activities on a single layer, e.g., say you've got a "signaling
storm" at a layer and want to shut down and then slowly bring back up the
entities at that layer.  Is this type of measurement and control of
signaling somewhat orthogonal to say  using a GMPLS signaling protocol or a
Q.2931 based protocol?
</GB>

> The logical layer model still stands.  I didn't assume any particular
> mechanism for the signaling transport (except IP) since different 
> layers/technologies may have different mechanisms available, e.g., 
> SONET's DCC.  I also didn't want to dictate where the network 
> engineering function resides, i.e., where in the above example
> you'd figure out the best place to put the STS-1 paths given
> locations of VT1.5 switches, traffic trends, SONET line capacities
> etc. Is this what you are calling a LNTC?

Yes, this is what I intend torefer to by LNTC. Note - LNTC is a new term
that came to my mind when creating the previous reply. During the
Q.12/15 meeting last week people indicated that we need alternative
terms for "traffic engineering" and "network engineering" in the way I
was using those. My "network engineering" is controlling to some extend
the layer network topology; of course it isn't capable to add extra
hardware or software to the network, but it can modify the topology by
adding/removing/increasing/shrinking links (G.805 terminology)). If you
can think of a better term for this, let me know. I am looking for a
better term for "traffic engineering" (in my definition) process.
Perhaps this should be split into two "controllers"; one concerned with
distributing reachability/topology information and link state
information, and another concerned with the actual route finding and
connection setup/release. Any suggestions?
<GB> I think we are getting somewhere with these clarifications. </GB>
> 
> (2) Routing for each layer -- Here things are a little less obvious to me.
> Yes, I can run a separate instance of a route protocol for each layer but
> can I keep things simpler and would it be truly simpler.  Back to the
SONET
> example.  For setting up STS-1 (or STS-Nc) connections I would want to
know
> about SONET line layer topology (via a link state route protocol). 

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET lines or something else.

> For setting up the VT1.5 connections I would want to know about the
> SONET STS-1 layer connectivity between the VT1.5 layer switches. 

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET STS-1s or something
else. E.g. a VC-4, sub-STM-0 or sub-STS-1 interfaces, ATM (some
operators use ATM VCs to carry VT/LOVC signals) or MPLS (see ongoing
SONEt/SDH over MPLS work).

> If one had a network with switches with combined (multi-layer)
> switching capability then I could see some advantages in combining
> these.  At a minimum I can see that the network engineering 
> function for the VT1.5 layer switches (the thing that
> needs to set up the bandwidth between the VT1.5 layer switches) would want
> to know about both layers (it must know about the SONET line layer). 

I have to disagree here. The network engineering function for the VT1.5
layer switches needs to know only 
- the set of VT1.5 layer network "S_LN" ports (refer to WD08 section 5,
figure 38) or "class D" ports (WD20, section 2.3, figure 3) that are
present in the VT1.5 switches
- the reachability information per (group of) port(s).

The network engineering function (or LNTC) decides on the available
information between which two VT1.5 switches a VT1.5 link is to be added
or extended. 
Once this is decided, the LNTC has to determine if this can be realised
by menas of a direct link (single hop) or if a multi-hop link is the
only possibility; in the latter case the two ports to be interconnected
can not reach each other directly.
Then, the VT1.5 LNTC requests the new VT1.5 link (or links) to be
created by its server layer(s) between the specific ports (or port
groups).

There is no need to know anything about the SONET line layer here.

Furthermore, you should consider that the network must perform its tasks
independent of the physical grouping of functions. I.e. the behaviour of
the network must be the same independent of the fact of VT1.5 fabrics
and STS fabrics are in separate equipment, or in the same equipment, or
a mix of both is present. 
You should not base your design on only one of the possible cases.

<GB> Let's see if we can bring this back together. In my example I assumed
VT1.5 switches interconnected via STS-1 paths over SONET lines.  I want to
do a few things when I set up additional (or any) STS-1 paths connecting
these switches: (a) meet current demands for VT1.5 carriage over the STS-1
layer network. (b) make efficient usage of STS-1 layer resources. (c) make
efficient usage of STS-1 layer resources in the future.  Hence I've got a
current demand matrix to be satisfied, some growth trends that I may know
about and SONET line layer connectivity (well as you say really STS-1 link
capacity but I'm trying to be specific for clarity).  Now for the trending
information I figured various snap shots over time of the VT1.5 layer
connectivity (via a link state protocol) would be used. Hence why I figured
upper layer information is useful.
Does this clarify my intent?
</GB>

> This
> is what motivates integrating multiple layers into a single instance of a
> routing protocol. But what about more than two layers? How would a knowing
> the DS0 connectivity/traffic trends be of use to the network engineering
> function for STS-1 paths between VT1.5 switches? I don't think so since we
> see this via the VT1.5 trends anyhow.  Similarly the properties of layers
> below the SONET line layer should be already summarized via SRLG info so
I'm
> not sure that knowing the exact topology down at the waveband level is all
> that helpful.  

I have the feeling that you are almost coming to the same conclusion as
I am in the lines above. I.e. if you can do a good job at DS0 level
without having knowledge of underlying STS, line and below layers why
would one need to have line level knowledge when being at VT1.5 level?
If you don't need it at one place, you can apply the same mechanism at
other places and you don't need it at those places either.
<GB> I guess I see most lower layer knowledge being abstracted via the use
of SRLGs and this would propagate upwards if desired. My WDM systems know
lots of things but only a few are useful for the upper layers. </GB>

> Kireeti (or Yakov) the forwarding adjacency concept was
> introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this
was
> for MPLS within MPLS now we are talking multiplex hierarchies where the
> entities at the different layers are very much different from each other.

Allow me a side step here... from a transport perspective MPLS is having
some unique characteristics: 
	"one technology, 
	 infinite number of layer networks, 
	 infinite number of connection monitoring levels (potential 
	 iff MPLS OAM is introduced)". 

E.g. as MPLS is connection oriented, I can use transport layer
terminology to describe the MPLS network architecture:
- the outer MPLS layer network connects to (non-MPLS) client layer
networks via adaptation functions
- adaptation functions to client layer networks can be of the 1:1 type
(1 client signal into 1 MPLS signal) or of the n:1 type (n client
signals multipelxed into 1 MPLS signal)
- a client layer signal is as such adapted to become an MPLS signal
before it is transported. Assume that MPLS OAM is available, such MPLS
OAM can be added to the signal to provide more extensive transport
monitoring capabilities to the signal transport. At this point,
end-to-end trail monitoring is established. 
- Traversing the MPLS layer network, the signal may pass through third
party subnetworks. Each of these subnetworks may need to monitor the
quality of service of the transport fo the signal through their network,
and these networks can now add a new level of MPLS OAM to the signal
(i.e. tandem connection monitoring). 
- Contrary to CBR techniques, MPLS doesn't have to steal overhead
bandwidht from the original signal. Instead it can simply add such OAM
to the signal. At the same time, it can add another MPLS header to the
signal and associate this with the new OAM that is added (improvement
over ATM's segment monitoring capability). This makes the signal
transport in one subnetwork domain realy independent of its transport in
previous domains (true independence is obtained).
- let me now focus on the multi-layer aspect of MPLS. If you multiplex
several MPLS signals into an MPLS aggregate signal, you have created
essentially a second MPLS layer network supporting the first MPLS layer
network. The trails in this second MPLS layer network support thus first
MPLS layer network links. 
- From a routing perspective links are static elements in the layer
network, and you can now operate the MPLS network as a bunch of
independent layer networks, with client/server relationships within the
MPLS network itself. On one technology you can now operate a number of
logical layers; e.g. an MPLS access layer, a MPLS metro layer and a MPLS
core layer. Each will have their specific characteristics (e.g. typical
bandwidth of the MPLS signal; small for access, medium for metro, large
for core).
- the nice thing here is that you can mix and match these logical MPLS
layer networks in equipment without the need to install different
fabrics. As each logical MPLS layer network can be run with its own
control plane instance, you will not run into scalability issues or
unwanted access/metro/core interactions. So, all the good stuff from CBR
networks without their restrictions. :-)

> 
> Maarten, are we converging here (except for terminology of course)?

I have the feeling that we are converging. Let's see if the above notes
bring us even closer.

Up to so far. Regards, Maarten

> 
> Greg B.
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 1:19 AM
> To: Bernstein, Greg
> Cc: Diego Caviglia; Susumu Yoneda; [email-masked]; Jimmy Gendron;
> [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> Greg,
> 
> > Since we have to (a) be able to set up connects at the appropriate
layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer
> protocol
> > instances than network layers.
> 
> I am not sure I understand the meaning of the last sentence... does it
> refer to:
> a common Signalling Communication Network (SCN) over which all
> signalling messages are transported for all layer networks?
> 
> The ASON model under definition shows per switched layer network a
> hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> These SCs communicate with each other over the SCN. LOVC-SCs communicate
> with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> communicate with other ODU1-SCs, etc to exchange link state/topology
> information (case of I-NNI), reachability information (case of E-NNI,
> UNI) and routing information (connection setup). This is at the moment
> also referred to as "intra-layer" information exchange.
> 
> For the case we decide that a Network Engineering agent is included in
> an SC, we will get also "inter-layer" information exchange. E.g.
> HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> layer network. For the case we decide that Network Engineering agents
> are not part of the SC (but in a separate "layer network topology
> controller" (LNTC)), "inter-layer" information exchange will be between
> an SC and a LNTC. This latter model has a preference at the moment,
> while the two processes (SC: routing, LNTC: network topology) have a
> different scope.
> 
> Note - LNTC within one layer network have to communicate with each other
> also to build up an understanding of potential topology capabilities
> present in the layer network (or layer network partition the LNTC is
> responsible for).
> 
> Separate of the above, the ASON recommendations will specify the signal
> flow over inter domain interfaces where
> - a customer interconnects with an operator
> - two operators interconnect
> - two vendors interconnect.
> 
> Over these inter domain interfaces you have to comply to the signal
> (message) structure. For ASON networks this will be based on the layer
> network structure. Within one domain the same layer network structured
> approach may be used, or one may decide to create a "spaghetti mountain"
> in which the layer network structure is not adhered to. That's up to the
> individual vendor.
> 
> Regards,
> 
> Maarten
> 
> "Bernstein, Greg" wrote:
> >
> > Hi Maarten, Diego, et. al.
> > what's interesting here is the question of what do we mean by "its own
> > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be
signaling
> to
> > those switches that are LOVC capable.  Other switches need not be
> involved.
> > If it turns out that the LOVC capable switches are not interconnected by
a
> > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > appropriate HOVC interconnecting the LOVC needs to be setup first.  In
> GMPLS
> > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > switches before we set up the LOVC LSPs.
> >
> > Since we have to (a) be able to set up connects at the appropriate
layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer
> protocol
> > instances than network layers.  Well actually as Maarten wrote in a
recent
> > ITU document that we would be primarily interested in those layers
> involved
> > in dynamic switching/multiplexing.  Note that we've started to bring in
> > non-dynamic layer information via other mechanisms, e.g., the SRLG
concept
> > (the WDM--SONET example I always give).
> >
> > With the signaling protocol things are really separated by who is
involved
> > in the signaling transaction.  In the routing case things are less
clear,
> > i.e., who wants/needs to know information about other layers and what
> burden
> > does this present to the NEs and scalability.  Which layers can benefit
by
> > integration...  I'll be updating the Optical inter-domain route
> requirements
> > draft soon (with others) and will be exploring some of these items in
more
> > depth.
> >
> > (Terminology: LOVC := Lower order virtual container, SDH term that
> includes
> > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher
order
> > virtual container, SDH terms that includes signals between 50Mbps-40Gbps
> in
> > the SDH hierarchy).
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Monday, June 11, 2001 7:46 AM
> > To: Diego Caviglia
> > Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> > Subject: Re: GMPLS Sonet extensions
> >
> > Diego,
> >
> > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > and OCh) will have its own (instance of) control plane.
> >
> > Each switched layer network runs a copy of the generic routing protocol;
> > it does so within the boundaries of the switched layer network.
> >
> > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > interfaces due to partitioning of a switched layer network. Topology
> > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > the other hand only provide reachability information.
> >
> > For the case an MPLS router is from a different organisation than the
> > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > the interface will be an MPLS-I-NNI.
> > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > section layers) the interface relation is to be determined independent
> > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > as at the HOVC layer entwork only reachability information is available
> > in the MPLS router (HOVC-E-NNI).
> >
> > The MPLS router should not be concerned at all about the routing of the
> > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > link between is needed between MPLS router A and MPLS router B, router A
> > needs to have knowledge of router B's address/name only to request a
> > VC-4-16c/STS-48c connection through the transport network. The switched
> > HOVC (transport) network will take care of the connection setup.
> >
> > And even if two diverse routed connections are required (e.g. to support
> > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > needs to request only the creation of 2 VC-4-16c connections with the
> > constraint of being diversely routed. The switched HOVC network will be
> > able to provide these two connections diversely routed between A and B
> > routers.
> >
> > At the moment, I recognise two connection types in a layer network:
> >         - native connections and
> >         - client connections.
> > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > native connection, and a DS3 connection or a LOVC link is a client
> > connection. A client connection is supported by the HOVC layer network
> > after adapting it to the layer network signal type (i.e. STS1 (to
> > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > can have a
> >         - 1:1,
> >         - 1:n,
> >         - n:1
> > relationship with the underlying layer network signal.
> > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > relationship.
> >
> > With client connections, an I-NNI is almost per definition not possible
> > (you go outside the layer network). Nevertheless, some people consider
> > the special 1:1 case as an area where an I-NNI could be deployed; of
> > course not for the case of DS3 -> STS1, but for the case of
> > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > HOVC layer network and a client signal to the OCh and ODU1 layer
> > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > wavelenght it is easy to think to be within one and the same layer
> > network. Personally, I believe that such very special case looks much
> > brighter than it is in the long term. I.e. don't declare very special
> > cases to be the common ones; keep those as very special cases, best even
> > keep those as regular cases obeying to the generic rules.
> >
> > Client connections as such have UNI or E-NNI interface relationships
> > over which reachability information is offered at best. This is the case
> > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > link over a HOVC/STS layer network).
> >
> > Regards,
> >
> > Maarten
> >
> > Diego Caviglia wrote:
> > >
> > > Maarten,
> > >                     I agree in principle with you but this means it
> would
> > be
> > > necessary to have a routing protocol for each layer doesn't it?
> > >
> > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > plane, your
> > > layered view of the network implies again the separation of the
control
> > planes.
> > >
> > > The  Transport  Network is very different from a flat IP network and
> > layering in
> > > TN is implicit.
> > >
> > > If  I  understood your model correctly the MPLS Router only views,
> Access
> > Groups
> > > and  links  to  other  MPLS Routers. If there are free resources
between
> > the two
> > > routers  the TE process calculates, accordingly to some rules, the
best
> > path.
> >
> > Agree.
> >
> > > If
> > > there are no resources a call to the Network Engineering agent is
> > performed, the
> > > NE  makes a call to the TE of the SONET layer in order to provide a
> trail
> > to the
> > > MPLS layer (this procedure is repeated until available resources are
> > created for
> > > the MPLS router connection). This trail modifies the topology at the
> MPLS
> > layer.
> >
> > Agree. One note however, operators have indicated that they would like
> > to deploy policies in the NE agent which may include some thresholds,
> > before it decides to change the topology of the layer network. E.g.
> > topology is not extended unless X calls failed. On the other hand, the
> > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > hour extra links are added or bandwidth of existing link is extended,
> > and at the end of busy hour the reverse is happening.
> >
> > >
> > > If  my  understanding is correct and we want to implement an automated
> TN
> > a sort
> > > of UNI has to be put between the NE at layer N and the TE at layer
N-1.
> >
> > UNI or E-NNI.
> >
> > >
> > > Maybe this will create some problems, on the other hand, as Maarten
> > pointed out,
> > > flat  networks  won't  work due the huge amount of routing information
> > that they
> > > have to carry.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Susumu Yoneda <[email-masked]>
> > >
> > >  cc:      [email-masked], Jimmy Gendron
> > >           <[email-masked]>, [email-masked](bcc:
> > >           Diego Caviglia/MAIN/MC1)
> > >
> > >
> > >
> > >  Subject: Re: GMPLS Sonet extensions
> > >
> > >
> > > Sharma,
> > >
> > > "flat" set up is the route to disaster... simply consider a switched
> > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also
DS0,
> > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > would get information of all these levels... an absolute disaster in a
> > > world wide switched transport network would be the result.
> > >
> > > Therefore, there is this layering in which a server layer network
> > > provides bandwidth to its client layer entworks. the client layer
> > > networks see this bandwidth as kind of "fixed" bandwidth over which
they
> > > can route their signals.
> > >
> > > A separate entity (I called it "network engineering") is looking over
> > > the shoulder of the call setup process to see if more bandwidth is
> > > needed and when it would be needed or not longer required. But today,
> > > this separate entity is not part of the control plane; it is in the
> > > management plane.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Susumu Yoneda wrote:
> > > >
> > > > Sharma,
> > > >
> > > > Thank you for letting me know your presentation material which looks
> > very
> > > > interesting. It seems to me that a layered setup would make a sense.
> > > > However, users may want to have a "flat" setup. Therefore, lower
> setups
> > > > would not be seen by users?
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [mailto:[email-masked]]
> > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > > Subject: RE: GMPLS Sonet extensions
> > > >
> > > > Jimmy, Susumu,
> > > >
> > > > Your idea (assuming a peer model) is basically correct. Since all
> nodes
> > > > have the same view of the network, you could compute an ERO at the
> > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > to the egress router.
> > > > (Note, however, that the PATH message will travel
> > > > on the out-of-band IP control network; therefore, it would be
> > non-associated
> > > > signaling.)
> > > >
> > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > in fact, have to be shared by all nodes, since that is precisely
what
> > > > the "peer model" implies.
> > > >
> > > > But you do have to be careful about what "LSP" you are requesting,
> since
> > the
> > > > characteristics of the requested LSP are not interpreted in the same
> way
> > by
> > > > the
> > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > different
> > > > way of defining a circuit than an IP router or an OXC.)
> > > > Therefore, one possibility would be to do a "layered setup", where
an
> > LSP
> > > > at the lower layer is setup before the PATH message at the higher
> layer
> > > > is tunnelled over it or allowed to propagate further.
> > > >
> > > > For example, when the PATH message for the packet
> > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to
setup
> > > > a corresponding SONET circuit between themselves, and then either
> tunnel
> > > > the PATH message for the packet LSP over this circuit, or (assuming
> your
> > > > out-of-band network), at that time, allow the PATH message for the
> > packet
> > > > LSP to propagate to the next MPLS router. (The setting up of the
SONET
> > > > channel, likewise, would be a recursive process, with the OXC first
> > setting
> > > > up an optical lightpath between themselves, and tunneling the
request
> to
> > > > set up the SONET channel over it, once that lightpath is setup.)
> > > >
> > > > A more detailed discussion of this subject, with corresponding
> > animations
> > > > and figures, that you may also find helpful is available in a talk I
> > gave at
> > > > MPLSCon'01, and can be found at:
> > > > http://www.mplscon.com/missing_presentations.htm
> > > > (Dynamic path establishment in MPLS-controlled multi-service
> networks.)
> > > >
> > > > -Vishal
> > > >
> > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > [SMTP:[email-masked]]
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I also assume that there would be an out-of-band signalling
network
> > based
> > > > on
> > > > > a suite of GMPLS protocols including LMP. I think there will be
> issues
> > to
> > > > > address whether all messages will be shared by all nodes, i.e
> router,
> > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > -------------------------------
> > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > Information & Communication Labs.
> > > > > e-mail  [email-masked]
> > > > > -------------------------------
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf
> > > > Of
> > > > > Jimmy Gendron
> > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > To: [email-masked]'
> > > > > Subject: GMPLS Sonet extensions
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > understand
> > > > > most of the architecture, but I still have a question since the
> > beginning;
> > > > > as an unified control plane, how do the routing/signaling
protocols
> > > > exchange
> > > > > informations on a configuration like this:
> > > > >
> > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM -----------
WDM
> > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > (Ingress)
> > > > >
> > > > > Its a basic point to point configuration, but it will allow me to
> > > > understand
> > > > > the basic features of GMPLS. If I want to create an MPLS LSP
between
> > the
> > > > two
> > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > (Assuming
> > > > > that we have an out-of-band IP control network running LMP)
> > > > >
> > > > > My guess is that the PATH message will leave the ingress router
with
> a
> > > > PATH
> > > > > message with a calculated ERO. It assumes that the network is in
> > respect
> > > > > with the peer model...everyone have the same routing table and
know
> > the
> > > > > actual network topology. So, my PATH message will follow the CSPF
> > (ERO)
> > > > and
> > > > > go to the egress router. Am I right?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jimmy Gendron
> > > > >

Delivery-date: Wed, 13 Jun 2001 08:40:50 -0700
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS issues (was - GMPLS Last Calls) 
Date: Wed, 13 Jun 2001 08:38:13 -0700
From: Yakov Rekhter <[email-masked]>

Neil,

> Eric, I understand your points on the 'management network'......that is, the
> addressing of it's user-plane is a separate network to the user-plane
> offered for cutsomer connections.  So let me concentrate on the 'external'
> user-plane here in an attempt to answer your question.
> 
> Seems we have some choices in GMPLS at the moment:
> Addressing - v4 or v6
> Signalling - RSVP or CR-LDP
> Routing - OSPF or IS-IS (but exterior is BGP only)
> 
> All these facets are, in principle, independent choices.  And, in
> particular, since 'server layer trails = client layer links' then addressing
> cannot be from the same space at a server and client layer.  The addressing
> might have exactly the same format, but it comes from a different space, ie
> address X at layer M is not = address X at layer M.
> 
> Given that the layers have to be decoupled in the general case (for
> commercial as well as technical reasons - see the BT 'Freeland' requirements
> draft to 12/00 mtg) then there seems to be no reason why an operator could
> not use NSAPs for the access points of SDH or OTNs if he so wished.  

Please note that there is a way to carry NSAPs in IPv6 addresses,
although it does not support all types of NSAPs.  (see rfc1888 for
more details). Please also note that GMPLS supports IPv6 (as well
as IPv4). Finally, please note that a "perfect" solution (the one
that addresses all the requirements of everyone) is a *non* goal
for GMPLS.

> And,
> given this choice, that operator might also prefer to use PNNI as the
> signalling/routing solution too.  So, the issue seems not one of
> 'necesssity' but simply choice......though there may be certain technical
> benefits of choosing 1 solution over another.  I don't believe there is
> anything technically wrong with saying this and giving operators/vendors a
> choice here is there?.....if there is please point out the problems.

Few points:

1. Providing multiple choices for performing essentially the same
thing, especially if these choices have similar characteristics,
doesn't help to develop multi-vendor interoperable solutions.

2. The fact that in the IETF there are not one, but two link-state
IGPs (OSPF and ISIS) is a bug, and not a feature. 

3. The same applies for MPLS signalling (CR-LDP vs RSVP).

4. Suggesting yet another routing/signalling protocol, in addition
to GMPLS, is adding yet another bug (not a feature).

5. I understand that BT submitted a contribution to the ITU
suggesting PNNI as (yet another) routing/signalling for optical 
cross connects.

Yakov.

Delivery-date: Wed, 13 Jun 2001 08:29:21 -0700
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 08:20:12 -0700

Niel,

I think that the point that Eric was trying to make is that the IETF isn't
the correct venue
for a PNNI based solution, although a PNNI based solution might be a
perfectly fine thing.

>From a technical perspective, unless things have changed in the past several
years, the issues
with using PNNI are its lack of support for pre-emption/priority and make
before break, and that
its bandwidth advertisements are tightly coupled to ATM service categories.

Thanks,

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 6:09 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

> Where is the issue ? Why do we need NSAP addresses in GMPLS ?
> 
> Kind regards,
> 
> Eric
>
Eric, I understand your points on the 'management network'......that is, the
addressing of it's user-plane is a separate network to the user-plane
offered for cutsomer connections.  So let me concentrate on the 'external'
user-plane here in an attempt to answer your question.

Seems we have some choices in GMPLS at the moment:
Addressing - v4 or v6
Signalling - RSVP or CR-LDP
Routing - OSPF or IS-IS (but exterior is BGP only)

All these facets are, in principle, independent choices.  And, in
particular, since 'server layer trails = client layer links' then addressing
cannot be from the same space at a server and client layer.  The addressing
might have exactly the same format, but it comes from a different space, ie
address X at layer M is not = address X at layer M.

Given that the layers have to be decoupled in the general case (for
commercial as well as technical reasons - see the BT 'Freeland' requirements
draft to 12/00 mtg) then there seems to be no reason why an operator could
not use NSAPs for the access points of SDH or OTNs if he so wished.  And,
given this choice, that operator might also prefer to use PNNI as the
signalling/routing solution too.  So, the issue seems not one of
'necesssity' but simply choice......though there may be certain technical
benefits of choosing 1 solution over another.  I don't believe there is
anything technically wrong with saying this and giving operators/vendors a
choice here is there?.....if there is please point out the problems.

regards, Neil

Delivery-date: Wed, 13 Jun 2001 08:06:34 -0700
From: John Drake <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 07:59:15 -0700

Also, an ATM service using NSAP addresses for customer ports could be built
on top of a GMPLS core using IP addresses internally.  The ATM service
delivery switches could use the GMPLS core to provison lighpaths between
themselves and then run
PNNI as an overlay network for purposes of exchanging NSAP reachability
information. 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 7:33 AM
To: [email-masked]'; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)

Hello Neil,

>Given that the layers have to be decoupled in the general case (for
>commercial as well as technical reasons - see the BT 'Freeland'
requirements
>draft to 12/00 mtg) then there seems to be no reason why an operator could
>not use NSAPs for the access points of SDH or OTNs if he so wished.  And,
>given this choice, that operator might also prefer to use PNNI as the
>signalling/routing solution too.  So, the issue seems not one of
>'necesssity' but simply choice......though there may be certain technical
>benefits of choosing 1 solution over another.  I don't believe there is
>anything technically wrong with saying this and giving operators/vendors a
>choice here is there?.....if there is please point out the problems.

If somebody wants to use PNNI, it is not our business. The choice between a
GMPLS control plane and a PNNI control plane is not in our scope. We are
here working on GMPLS at the IETF, not on PNNI at the ATM Forum and not on
G.ASON at the ITU-T.

GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with NSAP addresses.
I don't think that somebody will choose a control plane only because it uses
IP or NSAP addresses, this doesn't make sense to me. There are much more
important distinctions between the two control planes than the format of the
addresses.

Technically I don't see arguments to adapt GMPLS to NSAP addresses, or to
AppleTalk addresses or to any kind of addresses that some people could
prefer, or that could come from another standardization body.

If technically there is a clear benefit of using NSAP addresses instead of
IP addresses in GMPLS that should be demonstrated by somebody. Up to now
nobody made it (I think that when somebody wants to modify an existing work
in a standardization body this has to be justified with technical reasons,
not just by a personal preference). So I presume that there is today no
technical argument to use NSAP addresses in GMPLS.

Even if any benefit is demonstrated, that should be balanced with the
disadvantages of supporting it and finaly the IETF should decide if they
want to adapt their protocols to other addressing schemes. Personally, I
don't think that this make sense.

Moreover, GMPLS is IP centric and this is one of its driving forces. I don't
see the interest of transforming an IP centric control plane in a less IP
centric control plane. This is going in the opposite direction of what we
are trying to do.

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

Delivery-date: Wed, 13 Jun 2001 07:34:07 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 16:32:41 +0200

Hello Neil,

>Given that the layers have to be decoupled in the general case (for
>commercial as well as technical reasons - see the BT 'Freeland'
requirements
>draft to 12/00 mtg) then there seems to be no reason why an operator could
>not use NSAPs for the access points of SDH or OTNs if he so wished.  And,
>given this choice, that operator might also prefer to use PNNI as the
>signalling/routing solution too.  So, the issue seems not one of
>'necesssity' but simply choice......though there may be certain technical
>benefits of choosing 1 solution over another.  I don't believe there is
>anything technically wrong with saying this and giving operators/vendors a
>choice here is there?.....if there is please point out the problems.

If somebody wants to use PNNI, it is not our business. The choice between a
GMPLS control plane and a PNNI control plane is not in our scope. We are
here working on GMPLS at the IETF, not on PNNI at the ATM Forum and not on
G.ASON at the ITU-T.

GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with NSAP addresses.
I don't think that somebody will choose a control plane only because it uses
IP or NSAP addresses, this doesn't make sense to me. There are much more
important distinctions between the two control planes than the format of the
addresses.

Technically I don't see arguments to adapt GMPLS to NSAP addresses, or to
AppleTalk addresses or to any kind of addresses that some people could
prefer, or that could come from another standardization body.

If technically there is a clear benefit of using NSAP addresses instead of
IP addresses in GMPLS that should be demonstrated by somebody. Up to now
nobody made it (I think that when somebody wants to modify an existing work
in a standardization body this has to be justified with technical reasons,
not just by a personal preference). So I presume that there is today no
technical argument to use NSAP addresses in GMPLS.

Even if any benefit is demonstrated, that should be balanced with the
disadvantages of supporting it and finaly the IETF should decide if they
want to adapt their protocols to other addressing schemes. Personally, I
don't think that this make sense.

Moreover, GMPLS is IP centric and this is one of its driving forces. I don't
see the interest of transforming an IP centric control plane in a less IP
centric control plane. This is going in the opposite direction of what we
are trying to do.

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

Delivery-date: Wed, 13 Jun 2001 06:54:25 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Date: Wed, 13 Jun 2001 09:52:09 -0400
Subject: Fwd: I-D ACTION:draft-many-oli-reqts-00.txt

FYI... Andre

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-many-oli-reqts-00.txt
>Date: Wed, 13 Jun 2001 07:09:56 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Optical Link Interface Requirements
>         Author(s)       : A. Fredette et al.
>         Filename        : draft-many-oli-reqts-00.txt
>         Pages           : 15
>         Date            : 12-Jun-01
>
>The emergence of transparent optical switches, together with a
>movement towards more dynamic, multi-vendor networks, has introduced
>a need for information sharing between optical line systems and
>client devices.  The information that needs to be shared includes
>link status and link properties.  We call this interface the Optical
>Link Interface (OLI).  In this document, we provide high-level
>requirements for the OLI.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-many-oli-reqts-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-many-oli-reqts-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-many-oli-reqts-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt>

Delivery-date: Wed, 13 Jun 2001 06:11:05 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 14:08:47 +0100

> Where is the issue ? Why do we need NSAP addresses in GMPLS ?
> 
> Kind regards,
> 
> Eric
>
Eric, I understand your points on the 'management network'......that is, the
addressing of it's user-plane is a separate network to the user-plane
offered for cutsomer connections.  So let me concentrate on the 'external'
user-plane here in an attempt to answer your question.

Seems we have some choices in GMPLS at the moment:
Addressing - v4 or v6
Signalling - RSVP or CR-LDP
Routing - OSPF or IS-IS (but exterior is BGP only)

All these facets are, in principle, independent choices.  And, in
particular, since 'server layer trails = client layer links' then addressing
cannot be from the same space at a server and client layer.  The addressing
might have exactly the same format, but it comes from a different space, ie
address X at layer M is not = address X at layer M.

Given that the layers have to be decoupled in the general case (for
commercial as well as technical reasons - see the BT 'Freeland' requirements
draft to 12/00 mtg) then there seems to be no reason why an operator could
not use NSAPs for the access points of SDH or OTNs if he so wished.  And,
given this choice, that operator might also prefer to use PNNI as the
signalling/routing solution too.  So, the issue seems not one of
'necesssity' but simply choice......though there may be certain technical
benefits of choosing 1 solution over another.  I don't believe there is
anything technically wrong with saying this and giving operators/vendors a
choice here is there?.....if there is please point out the problems.

regards, Neil

Delivery-date: Wed, 13 Jun 2001 03:32:30 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
Date: Wed, 13 Jun 2001 12:31:37 +0200

Hello Ananth,

>bala>> > 1) Type of legacy equipment needing NSAP addresses 
>bala>> > (also, is
>bala>> > this optical network element or client equipment?)
>bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
>bala>> > (2002, 2005, and 2010)
>bala>> > 3) Description of application in which this legacy equipment 
>bala>> > will use UNI
>bala>> > signaling
>bala>I don't recall seeing any response. furthermore, the NSAP
>bala>requirement was not unanimously endorsed by all carriers (at
>bala>the OIF). 
>
>From our OIF representatives, although it was not unanimously endorsed, 
>there was a significant demand for NSAP support. Well, NSAP is the main 
>non-IP type of addressing that is required. The general requirement is 
>to be able to support non-IP addresses (probably have an address 
>translation from non-IP addresses to routable addresses).
>NSAP support will be needed always (e.g. support for legacy DCC that 
>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can have an
IP stack and any other kind of stack using any other kind of addresses. The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The fact
that you have for instance a TMN stack using NSAP addresses is completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP address
inside the NSAP address if you have a dual stack running on the box, that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and
I have to check what we do for the TMN stack. I think that it is transported
over IP, maybe using RFC1006. If I remember correctly we only configure an
IP address on the DWDM box. In that case, I presume that TSAP's are build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and
their operations are independent of the nodes that we want to manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the other
stacks that are already running.

Where is the issue ? Why do we need NSAP addresses in GMPLS ?

Kind regards,

Eric

Delivery-date: Wed, 13 Jun 2001 03:01:10 -0700
Cc: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Wed, 13 Jun 2001 12:00:41 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------768A252F6A467CD4C58CEF3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

See my notes inline.

Regards,

Maarten
PS. ITU-T has created an open area to share information with IETF and
T1X1.5. for the moment access is limited via ftp client only. Work is
ongoing to provide web access as well.

> Host Name: ftp.itu.int
> Host Type: Unix (Standard)
> Remote Host Name: /tsg15opticaltransport
> Log in with your username and password
> Username: sg15opticalt
> Password: otxchange

In this open area you will find now 3 ASTN/ASON architecture document I
have created.
WD07 ASTN Layer Network Architecture - Multiplicity and interactions of
Traffic Engineering and Network Engineering processes
WD08 ASTN Layer Network Architecture 
WD20 ASTN/ASON Layer Network Architecture (view)

"Bernstein, Greg" wrote:
> 
> Hi Maarten et. al., I had two cases in mind. You'll have to meet me halfway
> on the terminology (I'm using SONET below in my examples).

No problem, SONET terminology is well understood by me. :-)

> (1) Signaling for each layer -- this can use a "common signaling" protocol
> with different "objects" or "information element" particular to that layer.
> This protocol would be used between the appropriate entities that control
> the switching at that particular layer.  For example, say I want to switch
> VT1.5s (a container for carrying T1s in SONET) then I would signal between
> the VT1.5 switches along the path using this common protocol.  If I first
> needed to connect some STS-1 paths between these VT1.5 switches then the
> signaling protocol (with STS-1 descriptions in it) would be used between
> these STS-1 switches.  

We seem aligned here.

> Now if a vendor chooses to integrate STS-1 and VT1.5
> switching in the same box its up to them whether they choose to separate
> these signaling control entities or combine them into one entity.  

Partly aligned here... Within one vendor's subnetwork I agree that a
vendor may choose to do this. But when the other switch is outside that
vendor's subnetwork, the signaling protocol would have to meet the
standard interface specification, which for ASON will have separate
signalling control entities.

> The logical layer model still stands.  I didn't assume any particular
> mechanism for the signaling transport (except IP) since different 
> layers/technologies may have different mechanisms available, e.g., 
> SONET's DCC.  I also didn't want to dictate where the network 
> engineering function resides, i.e., where in the above example
> you'd figure out the best place to put the STS-1 paths given
> locations of VT1.5 switches, traffic trends, SONET line capacities
> etc. Is this what you are calling a LNTC?

Yes, this is what I intend torefer to by LNTC. Note - LNTC is a new term
that came to my mind when creating the previous reply. During the
Q.12/15 meeting last week people indicated that we need alternative
terms for "traffic engineering" and "network engineering" in the way I
was using those. My "network engineering" is controlling to some extend
the layer network topology; of course it isn't capable to add extra
hardware or software to the network, but it can modify the topology by
adding/removing/increasing/shrinking links (G.805 terminology)). If you
can think of a better term for this, let me know. I am looking for a
better term for "traffic engineering" (in my definition) process.
Perhaps this should be split into two "controllers"; one concerned with
distributing reachability/topology information and link state
information, and another concerned with the actual route finding and
connection setup/release. Any suggestions?

> 
> (2) Routing for each layer -- Here things are a little less obvious to me.
> Yes, I can run a separate instance of a route protocol for each layer but
> can I keep things simpler and would it be truly simpler.  Back to the SONET
> example.  For setting up STS-1 (or STS-Nc) connections I would want to know
> about SONET line layer topology (via a link state route protocol). 

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET lines or something else.

> For setting up the VT1.5 connections I would want to know about the
> SONET STS-1 layer connectivity between the VT1.5 layer switches. 

You need to know the fabrics and the links between those fabrics. It is
irrelevant if those links are provided by SONET STS-1s or something
else. E.g. a VC-4, sub-STM-0 or sub-STS-1 interfaces, ATM (some
operators use ATM VCs to carry VT/LOVC signals) or MPLS (see ongoing
SONEt/SDH over MPLS work).

> If one had a network with switches with combined (multi-layer)
> switching capability then I could see some advantages in combining
> these.  At a minimum I can see that the network engineering 
> function for the VT1.5 layer switches (the thing that
> needs to set up the bandwidth between the VT1.5 layer switches) would want
> to know about both layers (it must know about the SONET line layer). 

I have to disagree here. The network engineering function for the VT1.5
layer switches needs to know only 
- the set of VT1.5 layer network "S_LN" ports (refer to WD08 section 5,
figure 38) or "class D" ports (WD20, section 2.3, figure 3) that are
present in the VT1.5 switches
- the reachability information per (group of) port(s).

The network engineering function (or LNTC) decides on the available
information between which two VT1.5 switches a VT1.5 link is to be added
or extended. 
Once this is decided, the LNTC has to determine if this can be realised
by menas of a direct link (single hop) or if a multi-hop link is the
only possibility; in the latter case the two ports to be interconnected
can not reach each other directly.
Then, the VT1.5 LNTC requests the new VT1.5 link (or links) to be
created by its server layer(s) between the specific ports (or port
groups).

There is no need to know anything about the SONET line layer here.

Furthermore, you should consider that the network must perform its tasks
independent of the physical grouping of functions. I.e. the behaviour of
the network must be the same independent of the fact of VT1.5 fabrics
and STS fabrics are in separate equipment, or in the same equipment, or
a mix of both is present. 
You should not base your design on only one of the possible cases.

> This
> is what motivates integrating multiple layers into a single instance of a
> routing protocol. But what about more than two layers? How would a knowing
> the DS0 connectivity/traffic trends be of use to the network engineering
> function for STS-1 paths between VT1.5 switches? I don't think so since we
> see this via the VT1.5 trends anyhow.  Similarly the properties of layers
> below the SONET line layer should be already summarized via SRLG info so I'm
> not sure that knowing the exact topology down at the waveband level is all
> that helpful.  

I have the feeling that you are almost coming to the same conclusion as
I am in the lines above. I.e. if you can do a good job at DS0 level
without having knowledge of underlying STS, line and below layers why
would one need to have line level knowledge when being at VT1.5 level?
If you don't need it at one place, you can apply the same mechanism at
other places and you don't need it at those places either.

> Kireeti (or Yakov) the forwarding adjacency concept was
> introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was
> for MPLS within MPLS now we are talking multiplex hierarchies where the
> entities at the different layers are very much different from each other.

Allow me a side step here... from a transport perspective MPLS is having
some unique characteristics: 
	"one technology, 
	 infinite number of layer networks, 
	 infinite number of connection monitoring levels (potential 
	 iff MPLS OAM is introduced)". 

E.g. as MPLS is connection oriented, I can use transport layer
terminology to describe the MPLS network architecture:
- the outer MPLS layer network connects to (non-MPLS) client layer
networks via adaptation functions
- adaptation functions to client layer networks can be of the 1:1 type
(1 client signal into 1 MPLS signal) or of the n:1 type (n client
signals multipelxed into 1 MPLS signal)
- a client layer signal is as such adapted to become an MPLS signal
before it is transported. Assume that MPLS OAM is available, such MPLS
OAM can be added to the signal to provide more extensive transport
monitoring capabilities to the signal transport. At this point,
end-to-end trail monitoring is established. 
- Traversing the MPLS layer network, the signal may pass through third
party subnetworks. Each of these subnetworks may need to monitor the
quality of service of the transport fo the signal through their network,
and these networks can now add a new level of MPLS OAM to the signal
(i.e. tandem connection monitoring). 
- Contrary to CBR techniques, MPLS doesn't have to steal overhead
bandwidht from the original signal. Instead it can simply add such OAM
to the signal. At the same time, it can add another MPLS header to the
signal and associate this with the new OAM that is added (improvement
over ATM's segment monitoring capability). This makes the signal
transport in one subnetwork domain realy independent of its transport in
previous domains (true independence is obtained).
- let me now focus on the multi-layer aspect of MPLS. If you multiplex
several MPLS signals into an MPLS aggregate signal, you have created
essentially a second MPLS layer network supporting the first MPLS layer
network. The trails in this second MPLS layer network support thus first
MPLS layer network links. 
- From a routing perspective links are static elements in the layer
network, and you can now operate the MPLS network as a bunch of
independent layer networks, with client/server relationships within the
MPLS network itself. On one technology you can now operate a number of
logical layers; e.g. an MPLS access layer, a MPLS metro layer and a MPLS
core layer. Each will have their specific characteristics (e.g. typical
bandwidth of the MPLS signal; small for access, medium for metro, large
for core).
- the nice thing here is that you can mix and match these logical MPLS
layer networks in equipment without the need to install different
fabrics. As each logical MPLS layer network can be run with its own
control plane instance, you will not run into scalability issues or
unwanted access/metro/core interactions. So, all the good stuff from CBR
networks without their restrictions. :-)

> 
> Maarten, are we converging here (except for terminology of course)?

I have the feeling that we are converging. Let's see if the above notes
bring us even closer.

Up to so far. Regards, Maarten

> 
> Greg B.
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 1:19 AM
> To: Bernstein, Greg
> Cc: Diego Caviglia; Susumu Yoneda; [email-masked]; Jimmy Gendron;
> [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> Greg,
> 
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer
> protocol
> > instances than network layers.
> 
> I am not sure I understand the meaning of the last sentence... does it
> refer to:
> a common Signalling Communication Network (SCN) over which all
> signalling messages are transported for all layer networks?
> 
> The ASON model under definition shows per switched layer network a
> hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> These SCs communicate with each other over the SCN. LOVC-SCs communicate
> with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> communicate with other ODU1-SCs, etc to exchange link state/topology
> information (case of I-NNI), reachability information (case of E-NNI,
> UNI) and routing information (connection setup). This is at the moment
> also referred to as "intra-layer" information exchange.
> 
> For the case we decide that a Network Engineering agent is included in
> an SC, we will get also "inter-layer" information exchange. E.g.
> HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> layer network. For the case we decide that Network Engineering agents
> are not part of the SC (but in a separate "layer network topology
> controller" (LNTC)), "inter-layer" information exchange will be between
> an SC and a LNTC. This latter model has a preference at the moment,
> while the two processes (SC: routing, LNTC: network topology) have a
> different scope.
> 
> Note - LNTC within one layer network have to communicate with each other
> also to build up an understanding of potential topology capabilities
> present in the layer network (or layer network partition the LNTC is
> responsible for).
> 
> Separate of the above, the ASON recommendations will specify the signal
> flow over inter domain interfaces where
> - a customer interconnects with an operator
> - two operators interconnect
> - two vendors interconnect.
> 
> Over these inter domain interfaces you have to comply to the signal
> (message) structure. For ASON networks this will be based on the layer
> network structure. Within one domain the same layer network structured
> approach may be used, or one may decide to create a "spaghetti mountain"
> in which the layer network structure is not adhered to. That's up to the
> individual vendor.
> 
> Regards,
> 
> Maarten
> 
> "Bernstein, Greg" wrote:
> >
> > Hi Maarten, Diego, et. al.
> > what's interesting here is the question of what do we mean by "its own
> > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling
> to
> > those switches that are LOVC capable.  Other switches need not be
> involved.
> > If it turns out that the LOVC capable switches are not interconnected by a
> > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > appropriate HOVC interconnecting the LOVC needs to be setup first.  In
> GMPLS
> > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > switches before we set up the LOVC LSPs.
> >
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer
> protocol
> > instances than network layers.  Well actually as Maarten wrote in a recent
> > ITU document that we would be primarily interested in those layers
> involved
> > in dynamic switching/multiplexing.  Note that we've started to bring in
> > non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> > (the WDM--SONET example I always give).
> >
> > With the signaling protocol things are really separated by who is involved
> > in the signaling transaction.  In the routing case things are less clear,
> > i.e., who wants/needs to know information about other layers and what
> burden
> > does this present to the NEs and scalability.  Which layers can benefit by
> > integration...  I'll be updating the Optical inter-domain route
> requirements
> > draft soon (with others) and will be exploring some of these items in more
> > depth.
> >
> > (Terminology: LOVC := Lower order virtual container, SDH term that
> includes
> > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> > virtual container, SDH terms that includes signals between 50Mbps-40Gbps
> in
> > the SDH hierarchy).
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Monday, June 11, 2001 7:46 AM
> > To: Diego Caviglia
> > Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> > Subject: Re: GMPLS Sonet extensions
> >
> > Diego,
> >
> > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > and OCh) will have its own (instance of) control plane.
> >
> > Each switched layer network runs a copy of the generic routing protocol;
> > it does so within the boundaries of the switched layer network.
> >
> > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > interfaces due to partitioning of a switched layer network. Topology
> > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > the other hand only provide reachability information.
> >
> > For the case an MPLS router is from a different organisation than the
> > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > the interface will be an MPLS-I-NNI.
> > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > section layers) the interface relation is to be determined independent
> > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > as at the HOVC layer entwork only reachability information is available
> > in the MPLS router (HOVC-E-NNI).
> >
> > The MPLS router should not be concerned at all about the routing of the
> > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > link between is needed between MPLS router A and MPLS router B, router A
> > needs to have knowledge of router B's address/name only to request a
> > VC-4-16c/STS-48c connection through the transport network. The switched
> > HOVC (transport) network will take care of the connection setup.
> >
> > And even if two diverse routed connections are required (e.g. to support
> > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > needs to request only the creation of 2 VC-4-16c connections with the
> > constraint of being diversely routed. The switched HOVC network will be
> > able to provide these two connections diversely routed between A and B
> > routers.
> >
> > At the moment, I recognise two connection types in a layer network:
> >         - native connections and
> >         - client connections.
> > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > native connection, and a DS3 connection or a LOVC link is a client
> > connection. A client connection is supported by the HOVC layer network
> > after adapting it to the layer network signal type (i.e. STS1 (to
> > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > can have a
> >         - 1:1,
> >         - 1:n,
> >         - n:1
> > relationship with the underlying layer network signal.
> > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > relationship.
> >
> > With client connections, an I-NNI is almost per definition not possible
> > (you go outside the layer network). Nevertheless, some people consider
> > the special 1:1 case as an area where an I-NNI could be deployed; of
> > course not for the case of DS3 -> STS1, but for the case of
> > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > HOVC layer network and a client signal to the OCh and ODU1 layer
> > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > wavelenght it is easy to think to be within one and the same layer
> > network. Personally, I believe that such very special case looks much
> > brighter than it is in the long term. I.e. don't declare very special
> > cases to be the common ones; keep those as very special cases, best even
> > keep those as regular cases obeying to the generic rules.
> >
> > Client connections as such have UNI or E-NNI interface relationships
> > over which reachability information is offered at best. This is the case
> > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > link over a HOVC/STS layer network).
> >
> > Regards,
> >
> > Maarten
> >
> > Diego Caviglia wrote:
> > >
> > > Maarten,
> > >                     I agree in principle with you but this means it
> would
> > be
> > > necessary to have a routing protocol for each layer doesn't it?
> > >
> > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > plane, your
> > > layered view of the network implies again the separation of the control
> > planes.
> > >
> > > The  Transport  Network is very different from a flat IP network and
> > layering in
> > > TN is implicit.
> > >
> > > If  I  understood your model correctly the MPLS Router only views,
> Access
> > Groups
> > > and  links  to  other  MPLS Routers. If there are free resources between
> > the two
> > > routers  the TE process calculates, accordingly to some rules, the best
> > path.
> >
> > Agree.
> >
> > > If
> > > there are no resources a call to the Network Engineering agent is
> > performed, the
> > > NE  makes a call to the TE of the SONET layer in order to provide a
> trail
> > to the
> > > MPLS layer (this procedure is repeated until available resources are
> > created for
> > > the MPLS router connection). This trail modifies the topology at the
> MPLS
> > layer.
> >
> > Agree. One note however, operators have indicated that they would like
> > to deploy policies in the NE agent which may include some thresholds,
> > before it decides to change the topology of the layer network. E.g.
> > topology is not extended unless X calls failed. On the other hand, the
> > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > hour extra links are added or bandwidth of existing link is extended,
> > and at the end of busy hour the reverse is happening.
> >
> > >
> > > If  my  understanding is correct and we want to implement an automated
> TN
> > a sort
> > > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> >
> > UNI or E-NNI.
> >
> > >
> > > Maybe this will create some problems, on the other hand, as Maarten
> > pointed out,
> > > flat  networks  won't  work due the huge amount of routing information
> > that they
> > > have to carry.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Susumu Yoneda <[email-masked]>
> > >
> > >  cc:      [email-masked], Jimmy Gendron
> > >           <[email-masked]>, [email-masked](bcc:
> > >           Diego Caviglia/MAIN/MC1)
> > >
> > >
> > >
> > >  Subject: Re: GMPLS Sonet extensions
> > >
> > >
> > > Sharma,
> > >
> > > "flat" set up is the route to disaster... simply consider a switched
> > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > would get information of all these levels... an absolute disaster in a
> > > world wide switched transport network would be the result.
> > >
> > > Therefore, there is this layering in which a server layer network
> > > provides bandwidth to its client layer entworks. the client layer
> > > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > > can route their signals.
> > >
> > > A separate entity (I called it "network engineering") is looking over
> > > the shoulder of the call setup process to see if more bandwidth is
> > > needed and when it would be needed or not longer required. But today,
> > > this separate entity is not part of the control plane; it is in the
> > > management plane.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Susumu Yoneda wrote:
> > > >
> > > > Sharma,
> > > >
> > > > Thank you for letting me know your presentation material which looks
> > very
> > > > interesting. It seems to me that a layered setup would make a sense.
> > > > However, users may want to have a "flat" setup. Therefore, lower
> setups
> > > > would not be seen by users?
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [mailto:[email-masked]]
> > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > > Subject: RE: GMPLS Sonet extensions
> > > >
> > > > Jimmy, Susumu,
> > > >
> > > > Your idea (assuming a peer model) is basically correct. Since all
> nodes
> > > > have the same view of the network, you could compute an ERO at the
> > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > to the egress router.
> > > > (Note, however, that the PATH message will travel
> > > > on the out-of-band IP control network; therefore, it would be
> > non-associated
> > > > signaling.)
> > > >
> > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > in fact, have to be shared by all nodes, since that is precisely what
> > > > the "peer model" implies.
> > > >
> > > > But you do have to be careful about what "LSP" you are requesting,
> since
> > the
> > > > characteristics of the requested LSP are not interpreted in the same
> way
> > by
> > > > the
> > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > different
> > > > way of defining a circuit than an IP router or an OXC.)
> > > > Therefore, one possibility would be to do a "layered setup", where an
> > LSP
> > > > at the lower layer is setup before the PATH message at the higher
> layer
> > > > is tunnelled over it or allowed to propagate further.
> > > >
> > > > For example, when the PATH message for the packet
> > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > > a corresponding SONET circuit between themselves, and then either
> tunnel
> > > > the PATH message for the packet LSP over this circuit, or (assuming
> your
> > > > out-of-band network), at that time, allow the PATH message for the
> > packet
> > > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > > channel, likewise, would be a recursive process, with the OXC first
> > setting
> > > > up an optical lightpath between themselves, and tunneling the request
> to
> > > > set up the SONET channel over it, once that lightpath is setup.)
> > > >
> > > > A more detailed discussion of this subject, with corresponding
> > animations
> > > > and figures, that you may also find helpful is available in a talk I
> > gave at
> > > > MPLSCon'01, and can be found at:
> > > > http://www.mplscon.com/missing_presentations.htm
> > > > (Dynamic path establishment in MPLS-controlled multi-service
> networks.)
> > > >
> > > > -Vishal
> > > >
> > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > [SMTP:[email-masked]]
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I also assume that there would be an out-of-band signalling network
> > based
> > > > on
> > > > > a suite of GMPLS protocols including LMP. I think there will be
> issues
> > to
> > > > > address whether all messages will be shared by all nodes, i.e
> router,
> > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > -------------------------------
> > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > Information & Communication Labs.
> > > > > e-mail  [email-masked]
> > > > > -------------------------------
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf
> > > > Of
> > > > > Jimmy Gendron
> > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > To: [email-masked]'
> > > > > Subject: GMPLS Sonet extensions
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > understand
> > > > > most of the architecture, but I still have a question since the
> > beginning;
> > > > > as an unified control plane, how do the routing/signaling protocols
> > > > exchange
> > > > > informations on a configuration like this:
> > > > >
> > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > (Ingress)
> > > > >
> > > > > Its a basic point to point configuration, but it will allow me to
> > > > understand
> > > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> > the
> > > > two
> > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > (Assuming
> > > > > that we have an out-of-band IP control network running LMP)
> > > > >
> > > > > My guess is that the PATH message will leave the ingress router with
> a
> > > > PATH
> > > > > message with a calculated ERO. It assumes that the network is in
> > respect
> > > > > with the peer model...everyone have the same routing table and know
> > the
> > > > > actual network topology. So, my PATH message will follow the CSPF
> > (ERO)
> > > > and
> > > > > go to the egress router. Am I right?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jimmy Gendron
> > > > >
--------------768A252F6A467CD4C58CEF3D
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------768A252F6A467CD4C58CEF3D--

Delivery-date: Wed, 13 Jun 2001 02:56:16 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, Mina Azad <[email-masked]>
Cc: Scott Bradner <[email-masked]>
Subject: RE: TE-WG Design Team
Date: Wed, 13 Jun 2001 11:54:29 +0200

I thought that in the announcement we explained that we had far too
many volunteers. You then have to choose. We consulted with 
a number of ADs and TAs and the WG chairs, and based on the
input we got from the volunteers we came up with the list.
We used cirteria like apparent knowledge of the topic, know
organization, etc... 

I don't think it makes sense to go into a detailed discussion here.
But instead... we should trust that the DT will come up with a good 
initial InternetDraft that contains the requirements and that based on
that we can have a good technical discussion.

Bert

> ----------
> From: 	Mina Azad[SMTP:[email-masked]]
> Sent: 	Tuesday, June 12, 2001 11:09 PM
> To: 	Wijnen, Bert (Bert); ccamp-wg
> Cc: 	Scott Bradner
> Subject: 	RE: TE-WG Design Team
> 
> You wrote: 
> "We evaluated the volunteers with the ADs, TAs and TEWG chairs and we
> decided to compose the team..." 
> 
> May I ask what was your evaluation criteria?    
> 
> 		Mina Azad 
> 	ATM/IP OAM Standards Specialist   
> 	Nortel Networks 
> 	[email-masked]
> 	1-613-763-2044 (ESN 393-2044) 
> 
> 
> > -----Original Message----- 
> > From: Wijnen, Bert (Bert) [ mailto:[email-masked]] 
> > Sent: Tuesday, June 12, 2001 4:49 PM 
> > To: ccamp-wg 
> > Cc: Scott Bradner 
> > Subject: TE-WG Design Team 
> > 
> > 
> > All, 
> > 
> > > We had a great response to our call for volunteers - 27 
> > people sent in 
> > > their names and indicated their readyness to help.  As 
> > noted in RFC 2418 
> > > sec 6.5 design teams work best when they are small so we 
> > could not accept 
> > > everyone who offered their services. We evaluated the 
> > volunteers with the 
> > > ADs, TAs and TEWG chairs and we decided to compose the team 
> > as follows: 
> > > 
> >    Ed Kern, [email-masked]  (chair). 
> > >    Malin Carlzon, [email-masked] 
> >    Tim Griffin, [email-masked] 
> >    Tom Reddington, [email-masked] 
> >    Chris Liljenstolpe, [email-masked] 
> >    Wai Sum Lai, [email-masked] 
> >    Longsong Lin,  [email-masked] 
> >    Dave McDysan, [email-masked] 
> >    Rob Coltun, [email-masked] 
> > 
> > > We thank everyone who volunteered for their willingness to 
> > serve.  we also 
> > > want to remind everyone (including the design team) that, as noted 
> > > in the same section of RFC 2418, "The output of a design 
> > team is always 
> > > subject to approval, rejection or modification by the WG as 
> > a whole." 
> > > i.e. being on the design team means that the rest of the WG 
> > will get to 
> > > comment on their work without having to put in the original effort. 
> > > 
> > > We will be sending out a formal charge to the designe team 
> > in the next few 
> > > days and expect that they will produce an Internet Draft 
> > (well) before 
> > > the ID cutoff for the London IETF meeting. 
> > > 
> > > Bert & Scott 
> > > 
> > 
> > 
> 
> 

Delivery-date: Wed, 13 Jun 2001 01:06:03 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Signal Type doubt in GMPLS
Date: Wed, 13 Jun 2001 10:04:40 +0200

Hello Manoj,

>Also, for signal types STM-1, STM-4 etc. it is written in braces
>that "only when requesting transparency". What does this exactly mean ?

When you request some transparency it means transparency in the SOH, so you
don't just request some payload, you request something related to the frame
itself. Some part of the SOH has to be delivered at the other end of the LSP
untouched. This can be achieved in several ways, e.g. simply forwarded
untouched (and this doesn't require any new standard, e.g. you keep the DCC
untouched and you forward it :-) by the intermediate nodes in the network,
or tunnelled in some overhead bytes.

We didn't want to use a VC type of signal with transparency because the SOH
is not part of this VC, we used STM-N. This is much cleaner.

>What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs.

An AUG-X signal type means the space taken by the AUG-X, it is like a TUG or
VTG signal. That allows to open a circuit without specifying its content,
your SDH framer will recognise the content automatically.

For instance, I am a customer and I don't care about transparency. I am
connected to a switch with an STM-4 interface. I want to open a circuit with
the bandwidth equivalent of an STM-1 whose content can change, e.g. first I
structure it as 3 x VC-3's, later on I want one VC-4. I request an AUG-1
circuit.

Kind regards,

Eric

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 9:31 PM
To: [email-masked]
Subject: Signal Type doubt in GMPLS

Hi,
    I have certain doubts regarding signal type field in sonet-sdh 00.txt 
draft.

What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs.

When signal type is AUG-256, what does this exatly mean ?

Also, for signal types STM-1, STM-4 etc. it is written in braces
that "only when requesting transparency". What does this exactly mean ?

Please help.

Regards,
manoj.

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

Delivery-date: Tue, 12 Jun 2001 16:09:55 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: RE: GMPLS Sonet extensions
Date: Tue, 12 Jun 2001 16:06:12 -0700

Hi Maarten et. al., I had two cases in mind. You'll have to meet me halfway
on the terminology (I'm using SONET below in my examples).
(1) Signaling for each layer -- this can use a "common signaling" protocol
with different "objects" or "information element" particular to that layer.
This protocol would be used between the appropriate entities that control
the switching at that particular layer.  For example, say I want to switch
VT1.5s (a container for carrying T1s in SONET) then I would signal between
the VT1.5 switches along the path using this common protocol.  If I first
needed to connect some STS-1 paths between these VT1.5 switches then the
signaling protocol (with STS-1 descriptions in it) would be used between
these STS-1 switches.  Now if a vendor chooses to integrate STS-1 and VT1.5
switching in the same box its up to them whether they choose to separate
these signaling control entities or combine them into one entity.  The
logical layer model still stands.  I didn't assume any particular mechanism
for the signaling transport (except IP) since different layers/technologies
may have different mechanisms available, e.g., SONET's DCC.  I also didn't
want to dictate where the network engineering function resides, i.e., where
in the above example you'd figure out the best place to put the STS-1 paths
given locations of VT1.5 switches, traffic trends, SONET line capacities
etc. Is this what you are calling a LNTC?

(2) Routing for each layer -- Here things are a little less obvious to me.
Yes, I can run a separate instance of a route protocol for each layer but
can I keep things simpler and would it be truly simpler.  Back to the SONET
example.  For setting up STS-1 (or STS-Nc) connections I would want to know
about SONET line layer topology (via a link state route protocol).  For
setting up the VT1.5 connections I would want to know about the SONET STS-1
layer connectivity between the VT1.5 layer switches.  If one had a network
with switches with combined (multi-layer) switching capability then I could
see some advantages in combining these.  At a minimum I can see that the
network engineering function for the VT1.5 layer switches (the thing that
needs to set up the bandwidth between the VT1.5 layer switches) would want
to know about both layers (it must know about the SONET line layer).  This
is what motivates integrating multiple layers into a single instance of a
routing protocol. But what about more than two layers? How would a knowing
the DS0 connectivity/traffic trends be of use to the network engineering
function for STS-1 paths between VT1.5 switches? I don't think so since we
see this via the VT1.5 trends anyhow.  Similarly the properties of layers
below the SONET line layer should be already summarized via SRLG info so I'm
not sure that knowing the exact topology down at the waveband level is all
that helpful.  Kireeti (or Yakov) the forwarding adjacency concept was
introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was
for MPLS within MPLS now we are talking multiplex hierarchies where the
entities at the different layers are very much different from each other.

Maarten, are we converging here (except for terminology of course)?

Greg B.

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 1:19 AM
To: Bernstein, Greg
Cc: Diego Caviglia; Susumu Yoneda; [email-masked]; Jimmy Gendron;
[email-masked]
Subject: Re: GMPLS Sonet extensions

Greg,

> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer
protocol
> instances than network layers.  

I am not sure I understand the meaning of the last sentence... does it
refer to:
a common Signalling Communication Network (SCN) over which all
signalling messages are transported for all layer networks? 

The ASON model under definition shows per switched layer network a
hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
These SCs communicate with each other over the SCN. LOVC-SCs communicate
with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
communicate with other ODU1-SCs, etc to exchange link state/topology
information (case of I-NNI), reachability information (case of E-NNI,
UNI) and routing information (connection setup). This is at the moment
also referred to as "intra-layer" information exchange.

For the case we decide that a Network Engineering agent is included in
an SC, we will get also "inter-layer" information exchange. E.g.
HOVC-SCs may also communicate with LOVC-SCs to provide reachability
information for ports (e.g. STS1 and VC4 access groups) within the LOVC
layer network. For the case we decide that Network Engineering agents
are not part of the SC (but in a separate "layer network topology
controller" (LNTC)), "inter-layer" information exchange will be between
an SC and a LNTC. This latter model has a preference at the moment,
while the two processes (SC: routing, LNTC: network topology) have a
different scope.

Note - LNTC within one layer network have to communicate with each other
also to build up an understanding of potential topology capabilities
present in the layer network (or layer network partition the LNTC is
responsible for).

Separate of the above, the ASON recommendations will specify the signal
flow over inter domain interfaces where
- a customer interconnects with an operator
- two operators interconnect
- two vendors interconnect.

Over these inter domain interfaces you have to comply to the signal
(message) structure. For ASON networks this will be based on the layer
network structure. Within one domain the same layer network structured
approach may be used, or one may decide to create a "spaghetti mountain"
in which the layer network structure is not adhered to. That's up to the
individual vendor.

Regards,

Maarten

"Bernstein, Greg" wrote:
> 
> Hi Maarten, Diego, et. al.
> what's interesting here is the question of what do we mean by "its own
> instance of a control plane"?  Obviously if we are setting up a LOVC (in
> SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling
to
> those switches that are LOVC capable.  Other switches need not be
involved.
> If it turns out that the LOVC capable switches are not interconnected by a
> HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> appropriate HOVC interconnecting the LOVC needs to be setup first.  In
GMPLS
> speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> switches before we set up the LOVC LSPs.
> 
> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer
protocol
> instances than network layers.  Well actually as Maarten wrote in a recent
> ITU document that we would be primarily interested in those layers
involved
> in dynamic switching/multiplexing.  Note that we've started to bring in
> non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> (the WDM--SONET example I always give).
> 
> With the signaling protocol things are really separated by who is involved
> in the signaling transaction.  In the routing case things are less clear,
> i.e., who wants/needs to know information about other layers and what
burden
> does this present to the NEs and scalability.  Which layers can benefit by
> integration...  I'll be updating the Optical inter-domain route
requirements
> draft soon (with others) and will be exploring some of these items in more
> depth.
> 
> (Terminology: LOVC := Lower order virtual container, SDH term that
includes
> signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> virtual container, SDH terms that includes signals between 50Mbps-40Gbps
in
> the SDH hierarchy).
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 7:46 AM
> To: Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> Diego,
> 
> Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> and OCh) will have its own (instance of) control plane.
> 
> Each switched layer network runs a copy of the generic routing protocol;
> it does so within the boundaries of the switched layer network.
> 
> Within each switched layer network you will find UNI, E-NNI and I-NNI
> interfaces due to partitioning of a switched layer network. Topology
> information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> the other hand only provide reachability information.
> 
> For the case an MPLS router is from a different organisation than the
> transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> the interface will be an MPLS-I-NNI.
> For the server layers within the MPLS router (e.g. HOVC and STM-N
> section layers) the interface relation is to be determined independent
> of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> as at the HOVC layer entwork only reachability information is available
> in the MPLS router (HOVC-E-NNI).
> 
> The MPLS router should not be concerned at all about the routing of the
> HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> link between is needed between MPLS router A and MPLS router B, router A
> needs to have knowledge of router B's address/name only to request a
> VC-4-16c/STS-48c connection through the transport network. The switched
> HOVC (transport) network will take care of the connection setup.
> 
> And even if two diverse routed connections are required (e.g. to support
> VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> needs to request only the creation of 2 VC-4-16c connections with the
> constraint of being diversely routed. The switched HOVC network will be
> able to provide these two connections diversely routed between A and B
> routers.
> 
> At the moment, I recognise two connection types in a layer network:
>         - native connections and
>         - client connections.
> Example: within a HOVC layer network a STS1 or VC-4 connection is a
> native connection, and a DS3 connection or a LOVC link is a client
> connection. A client connection is supported by the HOVC layer network
> after adapting it to the layer network signal type (i.e. STS1 (to
> support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> can have a
>         - 1:1,
>         - 1:n,
>         - n:1
> relationship with the underlying layer network signal.
> Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> relationship.
> 
> With client connections, an I-NNI is almost per definition not possible
> (you go outside the layer network). Nevertheless, some people consider
> the special 1:1 case as an area where an I-NNI could be deployed; of
> course not for the case of DS3 -> STS1, but for the case of
> STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> HOVC layer network and a client signal to the OCh and ODU1 layer
> networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> wavelenght it is easy to think to be within one and the same layer
> network. Personally, I believe that such very special case looks much
> brighter than it is in the long term. I.e. don't declare very special
> cases to be the common ones; keep those as very special cases, best even
> keep those as regular cases obeying to the generic rules.
> 
> Client connections as such have UNI or E-NNI interface relationships
> over which reachability information is offered at best. This is the case
> for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> layer entwork) as well as "vertical client connections" (e.g. a LOVC
> link over a HOVC/STS layer network).
> 
> Regards,
> 
> Maarten
> 
> Diego Caviglia wrote:
> >
> > Maarten,
> >                     I agree in principle with you but this means it
would
> be
> > necessary to have a routing protocol for each layer doesn't it?
> >
> > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> plane, your
> > layered view of the network implies again the separation of the control
> planes.
> >
> > The  Transport  Network is very different from a flat IP network and
> layering in
> > TN is implicit.
> >
> > If  I  understood your model correctly the MPLS Router only views,
Access
> Groups
> > and  links  to  other  MPLS Routers. If there are free resources between
> the two
> > routers  the TE process calculates, accordingly to some rules, the best
> path.
> 
> Agree.
> 
> > If
> > there are no resources a call to the Network Engineering agent is
> performed, the
> > NE  makes a call to the TE of the SONET layer in order to provide a
trail
> to the
> > MPLS layer (this procedure is repeated until available resources are
> created for
> > the MPLS router connection). This trail modifies the topology at the
MPLS
> layer.
> 
> Agree. One note however, operators have indicated that they would like
> to deploy policies in the NE agent which may include some thresholds,
> before it decides to change the topology of the layer network. E.g.
> topology is not extended unless X calls failed. On the other hand, the
> NE agent may have scheduled topology changes; e.g. at the begin of busy
> hour extra links are added or bandwidth of existing link is extended,
> and at the end of busy hour the reverse is happening.
> 
> >
> > If  my  understanding is correct and we want to implement an automated
TN
> a sort
> > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> 
> UNI or E-NNI.
> 
> >
> > Maybe this will create some problems, on the other hand, as Maarten
> pointed out,
> > flat  networks  won't  work due the huge amount of routing information
> that they
> > have to carry.
> >
> > Regards
> >
> > Diego
> >
> > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> >
> >
> >
> >
> >
> >
> >
> >  To:      Susumu Yoneda <[email-masked]>
> >
> >  cc:      [email-masked], Jimmy Gendron
> >           <[email-masked]>, [email-masked](bcc:
> >           Diego Caviglia/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: GMPLS Sonet extensions
> >
> >
> > Sharma,
> >
> > "flat" set up is the route to disaster... simply consider a switched
> > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > would get information of all these levels... an absolute disaster in a
> > world wide switched transport network would be the result.
> >
> > Therefore, there is this layering in which a server layer network
> > provides bandwidth to its client layer entworks. the client layer
> > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > can route their signals.
> >
> > A separate entity (I called it "network engineering") is looking over
> > the shoulder of the call setup process to see if more bandwidth is
> > needed and when it would be needed or not longer required. But today,
> > this separate entity is not part of the control plane; it is in the
> > management plane.
> >
> > Regards,
> >
> > Maarten
> >
> > Susumu Yoneda wrote:
> > >
> > > Sharma,
> > >
> > > Thank you for letting me know your presentation material which looks
> very
> > > interesting. It seems to me that a layered setup would make a sense.
> > > However, users may want to have a "flat" setup. Therefore, lower
setups
> > > would not be seen by users?
> > >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: Saturday, June 09, 2001 11:06 AM
> > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > Subject: RE: GMPLS Sonet extensions
> > >
> > > Jimmy, Susumu,
> > >
> > > Your idea (assuming a peer model) is basically correct. Since all
nodes
> > > have the same view of the network, you could compute an ERO at the
> > > ingress router and have the PATH message follow the hop-by-hop route
> > > to the egress router.
> > > (Note, however, that the PATH message will travel
> > > on the out-of-band IP control network; therefore, it would be
> non-associated
> > > signaling.)
> > >
> > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > in fact, have to be shared by all nodes, since that is precisely what
> > > the "peer model" implies.
> > >
> > > But you do have to be careful about what "LSP" you are requesting,
since
> the
> > > characteristics of the requested LSP are not interpreted in the same
way
> by
> > > the
> > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > different
> > > way of defining a circuit than an IP router or an OXC.)
> > > Therefore, one possibility would be to do a "layered setup", where an
> LSP
> > > at the lower layer is setup before the PATH message at the higher
layer
> > > is tunnelled over it or allowed to propagate further.
> > >
> > > For example, when the PATH message for the packet
> > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > a corresponding SONET circuit between themselves, and then either
tunnel
> > > the PATH message for the packet LSP over this circuit, or (assuming
your
> > > out-of-band network), at that time, allow the PATH message for the
> packet
> > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > channel, likewise, would be a recursive process, with the OXC first
> setting
> > > up an optical lightpath between themselves, and tunneling the request
to
> > > set up the SONET channel over it, once that lightpath is setup.)
> > >
> > > A more detailed discussion of this subject, with corresponding
> animations
> > > and figures, that you may also find helpful is available in a talk I
> gave at
> > > MPLSCon'01, and can be found at:
> > > http://www.mplscon.com/missing_presentations.htm
> > > (Dynamic path establishment in MPLS-controlled multi-service
networks.)
> > >
> > > -Vishal
> > >
> > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Hi,
> > > >
> > > > I also assume that there would be an out-of-band signalling network
> based
> > > on
> > > > a suite of GMPLS protocols including LMP. I think there will be
issues
> to
> > > > address whether all messages will be shared by all nodes, i.e
router,
> > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > -------------------------------
> > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > Japan Telecom    fax +81 3 5540 8485
> > > > Information & Communication Labs.
> > > > e-mail  [email-masked]
> > > > -------------------------------
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> Behalf
> > > Of
> > > > Jimmy Gendron
> > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > To: [email-masked]'
> > > > Subject: GMPLS Sonet extensions
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I used to read almost all stuff regarding GMPLS since a week. I
> understand
> > > > most of the architecture, but I still have a question since the
> beginning;
> > > > as an unified control plane, how do the routing/signaling protocols
> > > exchange
> > > > informations on a configuration like this:
> > > >
> > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > (Ingress)
> > > >
> > > > Its a basic point to point configuration, but it will allow me to
> > > understand
> > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> the
> > > two
> > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > (Assuming
> > > > that we have an out-of-band IP control network running LMP)
> > > >
> > > > My guess is that the PATH message will leave the ingress router with
a
> > > PATH
> > > > message with a calculated ERO. It assumes that the network is in
> respect
> > > > with the peer model...everyone have the same routing table and know
> the
> > > > actual network topology. So, my PATH message will follow the CSPF
> (ERO)
> > > and
> > > > go to the egress router. Am I right?
> > > >
> > > > Best regards,
> > > >
> > > > Jimmy Gendron
> > > >

Delivery-date: Tue, 12 Jun 2001 16:03:54 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Date: Tue, 12 Jun 2001 16:02:17 -0700

Hi,
     I am looking for the information regarding the companies who have
implemented GMPLS. I want to know whether they support SONET/SDH only
or waveband is also supported ?

Thanks in advance,
manoj.

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

Delivery-date: Tue, 12 Jun 2001 14:11:23 -0700
From: "Mina Azad" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Cc: Scott Bradner <[email-masked]>
Subject: RE: TE-WG Design Team
Date: Tue, 12 Jun 2001 17:09:03 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F383.E84DC4D0
Content-Type: text/plain;
	charset="ISO-8859-1"

You wrote:
"We evaluated the volunteers with the ADs, TAs and TEWG chairs and we
decided to compose the team..."

May I ask what was your evaluation criteria?    

> 	Mina Azad
> 	ATM/IP OAM Standards Specialist   
> 	Nortel Networks
> 	[email-masked]
> 	1-613-763-2044 (ESN 393-2044)
> 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 4:49 PM
> To: ccamp-wg
> Cc: Scott Bradner
> Subject: TE-WG Design Team
> 
> 
> All, 
> 
> > We had a great response to our call for volunteers - 27 
> people sent in
> > their names and indicated their readyness to help.  As 
> noted in RFC 2418
> > sec 6.5 design teams work best when they are small so we 
> could not accept 
> > everyone who offered their services. We evaluated the 
> volunteers with the
> > ADs, TAs and TEWG chairs and we decided to compose the team 
> as follows: 
> > 
>    Ed Kern, [email-masked]  (chair).
> >    Malin Carlzon, [email-masked]
>    Tim Griffin, [email-masked]
>    Tom Reddington, [email-masked]
>    Chris Liljenstolpe, [email-masked]
>    Wai Sum Lai, [email-masked]
>    Longsong Lin,  [email-masked]
>    Dave McDysan, [email-masked]
>    Rob Coltun, [email-masked]
> 
> > We thank everyone who volunteered for their willingness to 
> serve.  we also
> > want to remind everyone (including the design team) that, as noted
> > in the same section of RFC 2418, "The output of a design 
> team is always 
> > subject to approval, rejection or modification by the WG as 
> a whole."
> > i.e. being on the design team means that the rest of the WG 
> will get to
> > comment on their work without having to put in the original effort.
> > 
> > We will be sending out a formal charge to the designe team 
> in the next few
> > days and expect that they will produce an Internet Draft 
> (well) before
> > the ID cutoff for the London IETF meeting.
> > 
> > Bert & Scott
> > 
> 
> 

------_=_NextPart_001_01C0F383.E84DC4D0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: TE-WG Design Team</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">You wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;We evaluated the volunteers =
with the ADs, TAs and TEWG chairs and we decided to compose the =
team...&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">May I ask what was your evaluation =
criteria?&nbsp;&nbsp;&nbsp; </FONT>
</P>
<UL><UL>
<P><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Monotype Corsiva">Mina =
Azad</FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Monotype =
Corsiva">ATM/IP OAM Standards Specialist&nbsp;&nbsp; </FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Monotype =
Corsiva">Nortel Networks</FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Monotype =
Corsiva">[email-masked]<BR>
1-613-763-2044 (ESN 393-2044)</FONT></I>
</P>
<BR>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: Wijnen, Bert (Bert) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent: Tuesday, June 12, 2001 =
4:49 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; To: ccamp-wg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Cc: Scott Bradner</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Subject: TE-WG Design =
Team</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; All, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; We had a great response to =
our call for volunteers - 27 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; people sent in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; their names and indicated =
their readyness to help.&nbsp; As </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; noted in RFC 2418</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; sec 6.5 design teams work =
best when they are small so we </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; could not accept </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; everyone who offered their =
services. We evaluated the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; volunteers with the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; ADs, TAs and TEWG chairs =
and we decided to compose the team </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; as follows: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Ed Kern, =
[email-masked]&nbsp; (chair).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp;&nbsp;&nbsp; Malin =
Carlzon, [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Tim Griffin, =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Tom =
Reddington, [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Chris =
Liljenstolpe, [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Wai Sum Lai, =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Longsong =
Lin,&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Dave McDysan, =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; Rob Coltun, =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; We thank everyone who =
volunteered for their willingness to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; serve.&nbsp; we also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; want to remind everyone =
(including the design team) that, as noted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; in the same section of RFC =
2418, &quot;The output of a design </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; team is always </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; subject to approval, =
rejection or modification by the WG as </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a whole.&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; i.e. being on the design =
team means that the rest of the WG </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; will get to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; comment on their work =
without having to put in the original effort.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; We will be sending out a =
formal charge to the designe team </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in the next few</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; days and expect that they =
will produce an Internet Draft </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (well) before</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; the ID cutoff for the =
London IETF meeting.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Bert &amp; Scott</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0F383.E84DC4D0--

Delivery-date: Tue, 12 Jun 2001 13:50:24 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Cc: Scott Bradner <[email-masked]>
Subject: TE-WG Design Team
Date: Tue, 12 Jun 2001 22:48:45 +0200

All, 

> We had a great response to our call for volunteers - 27 people sent in
> their names and indicated their readyness to help.  As noted in RFC 2418
> sec 6.5 design teams work best when they are small so we could not accept 
> everyone who offered their services. We evaluated the volunteers with the
> ADs, TAs and TEWG chairs and we decided to compose the team as follows: 
> 
   Ed Kern, [email-masked]  (chair).
>    Malin Carlzon, [email-masked]
   Tim Griffin, [email-masked]
   Tom Reddington, [email-masked]
   Chris Liljenstolpe, [email-masked]
   Wai Sum Lai, [email-masked]
   Longsong Lin,  [email-masked]
   Dave McDysan, [email-masked]
   Rob Coltun, [email-masked]

> We thank everyone who volunteered for their willingness to serve.  we also
> want to remind everyone (including the design team) that, as noted
> in the same section of RFC 2418, "The output of a design team is always 
> subject to approval, rejection or modification by the WG as a whole."
> i.e. being on the design team means that the rest of the WG will get to
> comment on their work without having to put in the original effort.
> 
> We will be sending out a formal charge to the designe team in the next few
> days and expect that they will produce an Internet Draft (well) before
> the ID cutoff for the London IETF meeting.
> 
> Bert & Scott
> 

Delivery-date: Tue, 12 Jun 2001 13:38:49 -0700
From: [email-masked]
Date: Tue, 12 Jun 2001 15:27:31 -0500
Subject: RE: GMPLS issues (was - GMPLS Last Calls)
TO: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

--openmail-part-4167abb8-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Tue, 12 Jun 2001 15:27:31 -0500"
Content-Transfer-Encoding: 7bit

Bala,
Thanks for your reply.  Sorry it took so long to reply back. Please see 
in-line.

Thanks,
Ananth

bala>> > 1) Type of legacy equipment needing NSAP addresses 
bala>> > (also, is
bala>> > this optical network element or client equipment?)
bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
bala>> > (2002, 2005, and 2010)
bala>> > 3) Description of application in which this legacy equipment 
bala>> > will use UNI
bala>> > signaling
bala>I don't recall seeing any response. furthermore, the NSAP
bala>requirement was not unanimously endorsed by all carriers (at
bala>the OIF). 

>From our OIF representatives, although it was not unanimously endorsed, 
there was a significant demand for NSAP support. Well, NSAP is the main 
non-IP type of addressing that is required. The general requirement is 
to be able to support non-IP addresses (probably have an address 
translation from non-IP addresses to routable addresses).

bala>It would also be nice if you can give some insight on
bala>the timeline in which you need various features, and whether
bala>the current GMPLS developments are inadequate within
bala>that timeline. (We can always have a progression of features).

NSAP support will be needed always (e.g. support for legacy DCC that 
uses NSAP).  So the timeframe requirement is now. 

Ananth>2) GMPLS is being defined based on assumptions about proprietary 
Ananth>transmission planes without those assumptions being specified. 
How can 
Ananth>we be sure that the control plane support is correct? How can we 
be 
Ananth>sure that it can be combined with other features?  Assumptions 
Ananth>regarding the transmission plane that can affect the control 
plane must 
Ananth>be clearly documented. This creates the additional related 
problem that 
Ananth>there is not a clear inter-working defined for interaction 
between 
Ananth>standard/proprietary control planes/transmission planes.

bala>BR: I get the feeling you're referring to the 
concatenation/transperency
bala>issues discussed recently. While the debate has been hot, there's
bala>no show stopper here. Several suggestions are being considered for
bala>clarifying standard/non-standard features supported.

The concatenation/transparency issues are a concern.  In addition, 
management features such as manual protection switching, protection 
switching configuration, billing support (e.g. usage collection) etc 
need to be supported too.

Ananth>3) Assuring separation of the control plane from the data plane 
Ananth>continues to arise.. When the control plane fails it should not 
affect 
Ananth> existing connections.  Also if connections in progress are 
affected 
Ananth>then they should not leave partially setup connections - they 
should 
Ananth>fail gracefully informing the initiator. The GMPLS architecture 
Ananth>document mentions this separation, but it's not clear how the 
GMPLS 
Ananth>signaling specifications reflect the implications of this 
decoupling.  

bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS
bala>based, as you know), and solutions in the RSVP/LDP space have been
bala>proposed (some drafts may be written).
bala>This is also not a show stopper by any means.

Don't understand how the OIF UNI addresses this. Our concerns are more 
with respect to the NNI (internal separation of control and data). If 
this is not addressed, it is definitely a showstopper.  According to 
our OIF representatives, the OIF is looking at the IETF to specify 
these protocols.

To be specific, existing connections shouldn't be impacted when the 
control plane fails.

Ananth>4) Support for NSAP addresses and in general support such that 
control 
Ananth>plane addressing is independent of clients and vice versa.  Also 
Ananth>scalable naming/addressing scheme such as proposed in OIF.

bala>BR: NSAP, see my initial comments. The OIF is not dealing with
bala>names/resolution, etc. This has been decided to be out of the
bala>scope of UNI signaling, and considered as a separate function.

Address translation of some form (for e.g. NSAP address translation) 
should be supported. See comment at the beginning of the email.

Ananth>5) Since the control plane may be supported via multiple 
protocols, 
Ananth>clear statement of what is - and  isn't - covered in the GMPLS 
Signaling 
Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed.

bala>BR: Don't understand this, but doesn't look like a major issue from
bala>your phrasing.

Recommend the development of applicability statements to cover this 
(otherwise, it is difficult to understand how the different pieces join 
together to form a coherent picture).

Ananth>6) Terminology is an issue (e.g., waveband switching, link)

bala>BR: Any inconsistencies can be taken care of easily.

Like your comment. Hope it is as easy as it sounds :-) Mapping of 
terminology between standards bodies and also between different drafts 
in the IETF can be painful. Agreed however, that this is not a 
show-stopper.

Ananth>7) Transaction support for connection set-up and release is 
needed for 
Ananth>connection oriented networks (e.g. crankback capability).

bala>BR: Internet drafts have already been written on crankback. I 
suggest
bala>that you please consider writing some drafts if there is something
bala>missing.

Aware of the "iwata-draft". Are there others? 

Ananth>8) Reliable message transfer 

bala>BR: Very much a part of signaling. the OIF work has considered this
bala>aspect also. 

'soft-state' signaling protocols may not be acceptable for the optical 
control plane.  Live channels must not be dropped as a result of 
signaling message delivery failures (e.g. timer refresh failures)

Ananth>9) Security concerns have not been fully addressed, particularly 
at the 
Ananth> architectural level.  The use of separate control network may 
Ananth>necessitate the need for 24 hour staff to protect against 
'Denial of 
Ananth>Service' attacks as currently happens for IP router networks. In 
Ananth>general, admission control issues need to be addressed.

bala>BR: Please elaborate on these, specifically, what's new in the
bala>context of GMPLS.

e.g. in the case of ATM UNI, if a user or users attempt too many call 
setups
simultaneously the switch control processor can become overloaded.  So, 
some form of call pacing/overload handling is needed.  Is there 
something similar in the GMPLS context for optical devices?

Ananth>10) The definition of transparency may be overly simplified.  
See 
Ananth>comments by Ben Mack-Crane:
Ananth>I think the debate on transparency indicates that the issue is 
not as 
Ananth>clear
Ananth>as we might think.  The OIF document you cite defines forms of 
Ananth>transparency
Ananth>that are very straightforward (flags 1,2) not the more complex 
forms in 
Ananth>the current GMPLS drafts (flags 3..10).  Also, these are easily 
Ananth>provided in
Ananth>O-E-O or O-O-O networks operating at the lambda level, but there 
is no
Ananth>standard for providing these over TDM multiplexed SONET/SDH 
links.

bala>BR: This is an ongoing topic of discussion. Doesn't break down
bala>the rest of the proposal.

Agreed.

Ananth>If two vendors implement the same signaling but different TDM 
Ananth>multiplexing, that 
Ananth>doesn't achieve interoperability.  Is there any way in the 
drafts to 
Ananth>determine the scope
Ananth>of application of the various signaling elements (that is, 
whether they 
Ananth>apply to UNI or NNI, whether they apply to specific network 
Ananth>layers/technologies)?

Ananth>11) One summary of additional items with issues includes:
Ananth>- SDH/SONET transparency.
Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation.
Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities.
Ananth>- All kinds of end-to-end protection/restoration for any layer, 
except 
Ananth>the IP layer.

bala>BR: Restoration is not actually covered in the current set of 
drafts.
bala>An earlier thread discussed this, and my suggestion is that this
bala>feature be dealt with separately.

Potential show-stopper for deployment if restoration is not covered. 
Would agree that it could be addressed separately, though.

Ananth>- The label set object (only used for lambda issues).
Ananth>- LSP encoding type, bandwidth encoding and GPID have to be 
simplified 
Ananth>accordingly.
Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is 
not yet 
Ananth>defined).

bala>BR: A draft is forthcoming on this.

Have been made aware of this. Thanks.

Ananth>12) Support for paths across SONET/SDH gateways

bala>BR: Please clarify the issues/write drafts.

Quoting from Siegfried Giebl's email regarding 
<draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
"If I understand this document correctly, then you are completely
separating SONET and SDH signal types from each other,  thus making it
difficult to deal with paths across SONET/SDH gateways. As an 
alternative, I
suggest you work only with entities of level STS-1 (STM-0) and higher. 
On the other hand why don't you go the full way and also add 64 kb/s 
channels ?"

Ananth> 13) Compatibility is required/desired with legacy SDH/SONET 
equipment 
Ananth>[and also legacy DWDM]

bala>BR: Same as above.

NSAP issue identified above. Elements within a link may not communicate 
using the signaling, i.e., legacy SDH/SONET equipment that does not 
participate in signaling (participate only in connectivity)

Thanks,
Ananth

--openmail-part-4167abb8-00000001--

Delivery-date: Tue, 12 Jun 2001 12:33:14 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Signal Type doubt in GMPLS
Date: Tue, 12 Jun 2001 12:31:23 -0700

Hi,
    I have certain doubts regarding signal type field in sonet-sdh 00.txt 
draft.

What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs.

When signal type is AUG-256, what does this exatly mean ?

Also, for signal types STM-1, STM-4 etc. it is written in braces
that "only when requesting transparency". What does this exactly mean ?

Please help.

Regards,
manoj.

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

Delivery-date: Tue, 12 Jun 2001 07:48:16 -0700
Cc: "'Diego Caviglia'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, Jimmy Gendron <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 12 Jun 2001 16:46:12 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "[email-masked]" <[email-masked]>
Original-CC: "'Diego Caviglia'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, Jimmy Gendron <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------1FCC5DEAD6811498CA279252
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vishal,

Comments inline.

Regards,

Maarten

Vishal Sharma wrote:
> 
> Diego,
> 
> Comments inline.
> 
> -Vishal
> On Tuesday, June 12, 2001 2:51 AM, Diego Caviglia
> [SMTP:[email-masked]] wrote:
> >
> >
> > Maaeten,
> >
> >                 In my understanding Greg's sentence (but of course the last
> >                 word
> > on  the  matter  of  his  sentence  is  up  to him) refers to the possibility
> > of
> > aggregating  information  from  different  layers in order to have less
> > protocol
> > instances than layers.
> >
> > If we consider all the possible layers inside the TN we have:
> >
> > 1.   LOVC
> >
> > 2.   HOVC
> >
> > 3.   ODU1
> >
> > 4.   ODU2
> >
> > 5.   ODU3
> >
> > 6.   Lambda
> 
> Exactly right.
> 
> > Moreover  we  have to take into account for Lambda switching purpose the type
> > of
> > the  fiber  (I  mean if the fiber is G.655, G.653, G.652 and maybe the vendor
> > of
> > the fiber) and for diversity routing purpose the duct layer.
> >
> > Do  we  need  to  aggregate  information  from  these layers? If so how could
> > we
> > aggregate layers?
> 
> Good question. I believe it is this aggregation that Greg was alluding to
> in his email, but we'll wait to hear what he has to say.
> 
> > Is  OSPF/IS-IS with extension the right choice in this layered environment or
> > do
> > we have to move to another routing protocol?
> >
> > The  routing  protocol(s) have to cope with lots of constraints and with lots
> > of
> > problems  that  were not in the "flat" IP networks for which they were
> > designed.
> 
> Exactly the point! This is indeed what needs to be looked at carefully.
> Of course, this does not mean abandoning the layered network approach
> (Maarten would certainly think that will collapse the global transport network
> :-)).

Correct :-). It is all based on domain engineering principles. Proper
decomposition will "reduce" the complexity of the item and support
graceful operation.

> But... it does mean a thorough examination of the available protocols,
> in the light of what is needed, to see if they can be made to fit the bill, and
> yet be made scalable, or if something new entirely might be needed.
> 
> > e.g.  can a LOVC request trigger a HOVC trail creation? Repeating the process
> > it
> > could  be  possible  that  a  LOVC  request triggers a Lambda trail that from
> > an
> > operator perspective, which I suppose is not desirable.
> 
> Technically, in a layered network under a common control plane this could
> certainly happen. However, when a request crosses the "layers" in a layered
> network in this manner, I believe it would have to have some interaction with
> the EMS/NMS or a policy engine somewhere that would need to determine
> what kind of HOVC or lambda trail needs to be setup to accommodate this
> (and possibly future) requests.

Correct. Operators are indicating that topology of a layer network is
changed based on policies, which are operator specific (operators will
differentiate themselve here from other operators). At the moment this
policy engine is located in the management plane (EMS/NMS/operators).

> 
> > Maarten Vissers <[email-masked]> on 12/06/2001 10.18.38
> >
> >
> 
> >
> >
> 
> >
> >
> 
> >
> >
> >
> >
> >
> >  To:      "Bernstein, Greg" <[email-masked]>
> >
> >  cc:      Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda
> >           <[email-masked]>, [email-masked],
> >           Jimmy Gendron <[email-masked]>,
> >           [email-masked]
> >
> >
> >
> >  Subject: Re: GMPLS Sonet extensions
> >
> >
> >
> >
> >
> >
> >
> >
> > Greg,
> >
> > > Since we have to (a) be able to set up connects at the appropriate layers,
> > > (b) understand the topology at each layer, to me this sounds like an
> > > instance of a control plane at each layer.
> > > However, it doesn't necessarily tell me whether I'd want to (or not)
> > > integrate multiple layer information into a protocol and run fewer protocol
> > > instances than network layers.
> >
> > I am not sure I understand the meaning of the last sentence... does it
> > refer to:
> > a common Signalling Communication Network (SCN) over which all
> > signalling messages are transported for all layer networks?
> >
> > The ASON model under definition shows per switched layer network a
> > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> > Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> > These SCs communicate with each other over the SCN. LOVC-SCs communicate
> > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> > communicate with other ODU1-SCs, etc to exchange link state/topology
> > information (case of I-NNI), reachability information (case of E-NNI,
> > UNI) and routing information (connection setup). This is at the moment
> > also referred to as "intra-layer" information exchange.
> >
> > For the case we decide that a Network Engineering agent is included in
> > an SC, we will get also "inter-layer" information exchange. E.g.
> > HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> > information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> > layer network. For the case we decide that Network Engineering agents
> > are not part of the SC (but in a separate "layer network topology
> > controller" (LNTC)), "inter-layer" information exchange will be between
> > an SC and a LNTC. This latter model has a preference at the moment,
> > while the two processes (SC: routing, LNTC: network topology) have a
> > different scope.
> >
> > Note - LNTC within one layer network have to communicate with each other
> > also to build up an understanding of potential topology capabilities
> > present in the layer network (or layer network partition the LNTC is
> > responsible for).
> >
> >
> >
> > Separate of the above, the ASON recommendations will specify the signal
> > flow over inter domain interfaces where
> > - a customer interconnects with an operator
> > - two operators interconnect
> > - two vendors interconnect.
> >
> > Over these inter domain interfaces you have to comply to the signal
> > (message) structure. For ASON networks this will be based on the layer
> > network structure. Within one domain the same layer network structured
> > approach may be used, or one may decide to create a "spaghetti mountain"
> > in which the layer network structure is not adhered to. That's up to the
> > individual vendor.
> >
> > Regards,
> >
> > Maarten
> >
> >
> >
> >
> > "Bernstein, Greg" wrote:
> > >
> > > Hi Maarten, Diego, et. al.
> > > what's interesting here is the question of what do we mean by "its own
> > > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling
> > > to
> > > those switches that are LOVC capable.  Other switches need not be involved.
> > > If it turns out that the LOVC capable switches are not interconnected by a
> > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > > appropriate HOVC interconnecting the LOVC needs to be setup first.  In
> > > GMPLS
> > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > > switches before we set up the LOVC LSPs.
> > >
> > > Since we have to (a) be able to set up connects at the appropriate layers,
> > > (b) understand the topology at each layer, to me this sounds like an
> > > instance of a control plane at each layer.
> > > However, it doesn't necessarily tell me whether I'd want to (or not)
> > > integrate multiple layer information into a protocol and run fewer protocol
> > > instances than network layers.  Well actually as Maarten wrote in a recent
> > > ITU document that we would be primarily interested in those layers involved
> > > in dynamic switching/multiplexing.  Note that we've started to bring in
> > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> > > (the WDM--SONET example I always give).
> > >
> > > With the signaling protocol things are really separated by who is involved
> > > in the signaling transaction.  In the routing case things are less clear,
> > > i.e., who wants/needs to know information about other layers and what
> > > burden
> > > does this present to the NEs and scalability.  Which layers can benefit by
> > > integration...  I'll be updating the Optical inter-domain route
> > > requirements
> > > draft soon (with others) and will be exploring some of these items in more
> > > depth.
> > >
> > > (Terminology: LOVC := Lower order virtual container, SDH term that includes
> > > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> > > the SDH hierarchy).
> > >
> > > Greg B.
> > > ***********************************
> > > Dr. Greg M. Bernstein
> > > Senior Scientist, Ciena Corporation
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Monday, June 11, 2001 7:46 AM
> > > To: Diego Caviglia
> > > Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> > > Subject: Re: GMPLS Sonet extensions
> > >
> > > Diego,
> > >
> > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > > and OCh) will have its own (instance of) control plane.
> > >
> > > Each switched layer network runs a copy of the generic routing protocol;
> > > it does so within the boundaries of the switched layer network.
> > >
> > > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > > interfaces due to partitioning of a switched layer network. Topology
> > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > > the other hand only provide reachability information.
> > >
> > > For the case an MPLS router is from a different organisation than the
> > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > > the interface will be an MPLS-I-NNI.
> > > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > > section layers) the interface relation is to be determined independent
> > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > > as at the HOVC layer entwork only reachability information is available
> > > in the MPLS router (HOVC-E-NNI).
> > >
> > > The MPLS router should not be concerned at all about the routing of the
> > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > > link between is needed between MPLS router A and MPLS router B, router A
> > > needs to have knowledge of router B's address/name only to request a
> > > VC-4-16c/STS-48c connection through the transport network. The switched
> > > HOVC (transport) network will take care of the connection setup.
> > >
> > > And even if two diverse routed connections are required (e.g. to support
> > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > > needs to request only the creation of 2 VC-4-16c connections with the
> > > constraint of being diversely routed. The switched HOVC network will be
> > > able to provide these two connections diversely routed between A and B
> > > routers.
> > >
> > > At the moment, I recognise two connection types in a layer network:
> > >         - native connections and
> > >         - client connections.
> > > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > > native connection, and a DS3 connection or a LOVC link is a client
> > > connection. A client connection is supported by the HOVC layer network
> > > after adapting it to the layer network signal type (i.e. STS1 (to
> > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > > can have a
> > >         - 1:1,
> > >         - 1:n,
> > >         - n:1
> > > relationship with the underlying layer network signal.
> > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > > relationship.
> > >
> > > With client connections, an I-NNI is almost per definition not possible
> > > (you go outside the layer network). Nevertheless, some people consider
> > > the special 1:1 case as an area where an I-NNI could be deployed; of
> > > course not for the case of DS3 -> STS1, but for the case of
> > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > > HOVC layer network and a client signal to the OCh and ODU1 layer
> > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > > wavelenght it is easy to think to be within one and the same layer
> > > network. Personally, I believe that such very special case looks much
> > > brighter than it is in the long term. I.e. don't declare very special
> > > cases to be the common ones; keep those as very special cases, best even
> > > keep those as regular cases obeying to the generic rules.
> > >
> > > Client connections as such have UNI or E-NNI interface relationships
> > > over which reachability information is offered at best. This is the case
> > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > > link over a HOVC/STS layer network).
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Diego Caviglia wrote:
> > > >
> > > > Maarten,
> > > >                     I agree in principle with you but this means it would
> > > be
> > > > necessary to have a routing protocol for each layer doesn't it?
> > > >
> > > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > > plane, your
> > > > layered view of the network implies again the separation of the control
> > > planes.
> > > >
> > > > The  Transport  Network is very different from a flat IP network and
> > > layering in
> > > > TN is implicit.
> > > >
> > > > If  I  understood your model correctly the MPLS Router only views, Access
> > > Groups
> > > > and  links  to  other  MPLS Routers. If there are free resources between
> > > the two
> > > > routers  the TE process calculates, accordingly to some rules, the best
> > > path.
> > >
> > > Agree.
> > >
> > > > If
> > > > there are no resources a call to the Network Engineering agent is
> > > performed, the
> > > > NE  makes a call to the TE of the SONET layer in order to provide a trail
> > > to the
> > > > MPLS layer (this procedure is repeated until available resources are
> > > created for
> > > > the MPLS router connection). This trail modifies the topology at the MPLS
> > > layer.
> > >
> > > Agree. One note however, operators have indicated that they would like
> > > to deploy policies in the NE agent which may include some thresholds,
> > > before it decides to change the topology of the layer network. E.g.
> > > topology is not extended unless X calls failed. On the other hand, the
> > > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > > hour extra links are added or bandwidth of existing link is extended,
> > > and at the end of busy hour the reverse is happening.
> > >
> > > >
> > > > If  my  understanding is correct and we want to implement an automated TN
> > > a sort
> > > > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> > >
> > > UNI or E-NNI.
> > >
> > > >
> > > > Maybe this will create some problems, on the other hand, as Maarten
> > > pointed out,
> > > > flat  networks  won't  work due the huge amount of routing information
> > > that they
> > > > have to carry.
> > > >
> > > > Regards
> > > >
> > > > Diego
> > > >
> > > > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  To:      Susumu Yoneda <[email-masked]>
> > > >
> > > >  cc:      [email-masked], Jimmy Gendron
> > > >           <[email-masked]>, [email-masked](bcc:
> > > >           Diego Caviglia/MAIN/MC1)
> > > >
> > > >
> > > >
> > > >  Subject: Re: GMPLS Sonet extensions
> > > >
> > > >
> > > > Sharma,
> > > >
> > > > "flat" set up is the route to disaster... simply consider a switched
> > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > > would get information of all these levels... an absolute disaster in a
> > > > world wide switched transport network would be the result.
> > > >
> > > > Therefore, there is this layering in which a server layer network
> > > > provides bandwidth to its client layer entworks. the client layer
> > > > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > > > can route their signals.
> > > >
> > > > A separate entity (I called it "network engineering") is looking over
> > > > the shoulder of the call setup process to see if more bandwidth is
> > > > needed and when it would be needed or not longer required. But today,
> > > > this separate entity is not part of the control plane; it is in the
> > > > management plane.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > Susumu Yoneda wrote:
> > > > >
> > > > > Sharma,
> > > > >
> > > > > Thank you for letting me know your presentation material which looks
> > > very
> > > > > interesting. It seems to me that a layered setup would make a sense.
> > > > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > > > would not be seen by users?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Vishal Sharma [mailto:[email-masked]]
> > > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > > > Subject: RE: GMPLS Sonet extensions
> > > > >
> > > > > Jimmy, Susumu,
> > > > >
> > > > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > > > have the same view of the network, you could compute an ERO at the
> > > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > > to the egress router.
> > > > > (Note, however, that the PATH message will travel
> > > > > on the out-of-band IP control network; therefore, it would be
> > > non-associated
> > > > > signaling.)
> > > > >
> > > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > > in fact, have to be shared by all nodes, since that is precisely what
> > > > > the "peer model" implies.
> > > > >
> > > > > But you do have to be careful about what "LSP" you are requesting,
> > > > > since
> > > the
> > > > > characteristics of the requested LSP are not interpreted in the same
> > > > > way
> > > by
> > > > > the
> > > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > > different
> > > > > way of defining a circuit than an IP router or an OXC.)
> > > > > Therefore, one possibility would be to do a "layered setup", where an
> > > LSP
> > > > > at the lower layer is setup before the PATH message at the higher layer
> > > > > is tunnelled over it or allowed to propagate further.
> > > > >
> > > > > For example, when the PATH message for the packet
> > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > > > a corresponding SONET circuit between themselves, and then either
> > > > > tunnel
> > > > > the PATH message for the packet LSP over this circuit, or (assuming
> > > > > your
> > > > > out-of-band network), at that time, allow the PATH message for the
> > > packet
> > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > > > channel, likewise, would be a recursive process, with the OXC first
> > > setting
> > > > > up an optical lightpath between themselves, and tunneling the request
> > > > > to
> > > > > set up the SONET channel over it, once that lightpath is setup.)
> > > > >
> > > > > A more detailed discussion of this subject, with corresponding
> > > animations
> > > > > and figures, that you may also find helpful is available in a talk I
> > > gave at
> > > > > MPLSCon'01, and can be found at:
> > > > > http://www.mplscon.com/missing_presentations.htm
> > > > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > > > >
> > > > > -Vishal
> > > > >
> > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > > [SMTP:[email-masked]]
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I also assume that there would be an out-of-band signalling network
> > > based
> > > > > on
> > > > > > a suite of GMPLS protocols including LMP. I think there will be
> > > > > > issues
> > > to
> > > > > > address whether all messages will be shared by all nodes, i.e router,
> > > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > > -------------------------------
> > > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > > Information & Communication Labs.
> > > > > > e-mail  [email-masked]
> > > > > > -------------------------------
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf
> > > > > Of
> > > > > > Jimmy Gendron
> > > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > > To: [email-masked]'
> > > > > > Subject: GMPLS Sonet extensions
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > > understand
> > > > > > most of the architecture, but I still have a question since the
> > > beginning;
> > > > > > as an unified control plane, how do the routing/signaling protocols
> > > > > exchange
> > > > > > informations on a configuration like this:
> > > > > >
> > > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > > (Ingress)
> > > > > >
> > > > > > Its a basic point to point configuration, but it will allow me to
> > > > > understand
> > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> > > the
> > > > > two
> > > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > > (Assuming
> > > > > > that we have an out-of-band IP control network running LMP)
> > > > > >
> > > > > > My guess is that the PATH message will leave the ingress router with
> > > > > > a
> > > > > PATH
> > > > > > message with a calculated ERO. It assumes that the network is in
> > > respect
> > > > > > with the peer model...everyone have the same routing table and know
> > > the
> > > > > > actual network topology. So, my PATH message will follow the CSPF
> > > (ERO)
> > > > > and
> > > > > > go to the egress router. Am I right?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Jimmy Gendron
> > > > > >
> >  << File: mvissers.vcf >>
--------------1FCC5DEAD6811498CA279252
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------1FCC5DEAD6811498CA279252--

Delivery-date: Tue, 12 Jun 2001 05:56:07 -0700
Cc: "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Tue, 12 Jun 2001 14:54:49 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Diego Caviglia <[email-masked]>
Original-CC: "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------659DBFFCE48B83F81DD81695
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Diego,

If we assume that e.g. LOVC-SCs communicate with other LOVC-SCs and that
HOVC-SCs communicate with other HOVC-SCs, then it seems not possible to
me (might be wrong) to aggregate LOVC information exchanged between
LOVC-SCs with HOVC information exchanged between HOVC-SCs in one and the
same message. Aggregation can be realised in this case by multiplexing
both information flows onto the same SCN only.

The SCN is a data network in which LOVC-SCs, HOVC-SCs, ODU1-SCs, etc are
endpoints. If this network is build up with e.g. MPLS connections we may
multiplex LOVC information flows with HOVC information flows over the
same MPLS connection (e.g. between A and B) if e.g. LOVC-SC and HOVC-SC
within network element A need to communicate with LOVC-SC and HOVC-SC in
network element B. But logically, there are a LOVC-SC-A to LOVC-SC-B
MPLS connection, a HOVC-SC-A to HOVC-SC-B MPLS connection and an NE-A to
NE-B MPLS aggregate connection.

Regards,

Maarten

Diego Caviglia wrote:
> 
> Maaeten,
> 
>                 In my understanding Greg's sentence (but of course the last word
> on  the  matter  of  his  sentence  is  up  to him) refers to the possibility of
> aggregating  information  from  different  layers in order to have less protocol
> instances than layers.
> 
> If we consider all the possible layers inside the TN we have:
> 
> 1.   LOVC
> 
> 2.   HOVC
> 
> 3.   ODU1
> 
> 4.   ODU2
> 
> 5.   ODU3
> 
> 6.   Lambda

I prefer to refer to the latter one as "OCh" (optical channel). A
"Lambda" is a representation of a tributary (i.e. frequency) slot in an
aggregate signal. Thus a Lambda is not a signal. 

"Lambda switching" is as such also impossible; instead the "optical
channel signal" (transported over a "lambda") is switched from a lambda
in the incoming aggregate signal to a lambda in the outgoing aggregate
signal (or to a single channel outgoing signal without lambda).

> 
> Moreover  we  have to take into account for Lambda switching purpose the type of
> the  fiber  (I  mean if the fiber is G.655, G.653, G.652 and maybe the vendor of
> the fiber) and for diversity routing purpose the duct layer.
> 
> Do  we  need  to  aggregate  information  from  these layers? If so how could we
> aggregate layers?
> 
> Is  OSPF/IS-IS with extension the right choice in this layered environment or do
> we have to move to another routing protocol?
> 
> The  routing  protocol(s) have to cope with lots of constraints and with lots of
> problems  that  were not in the "flat" IP networks for which they were designed.
> e.g.  can a LOVC request trigger a HOVC trail creation? Repeating the process it
> could  be  possible  that  a  LOVC  request triggers a Lambda trail that from an
> operator perspective, which I suppose is not desirable.

Correct. My example is a DS1 (1.5M) connection request creating a 40G
ODU3 trail; see ftp://ftp.t1.org/T1X1/X1.5/1x151260.doc

Regards,

Maarten

> 
> Best regards.
> 
> Diego
> 
> Maarten Vissers <[email-masked]> on 12/06/2001 10.18.38
> 
> 
> 
> 
> 
> 
> 
>  To:      "Bernstein, Greg" <[email-masked]>
> 
>  cc:      Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda
>           <[email-masked]>, [email-masked],
>           Jimmy Gendron <[email-masked]>,
>           [email-masked]
> 
> 
> 
>  Subject: Re: GMPLS Sonet extensions
> 
> 
> Greg,
> 
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.
> 
> I am not sure I understand the meaning of the last sentence... does it
> refer to:
> a common Signalling Communication Network (SCN) over which all
> signalling messages are transported for all layer networks?
> 
> The ASON model under definition shows per switched layer network a
> hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> These SCs communicate with each other over the SCN. LOVC-SCs communicate
> with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> communicate with other ODU1-SCs, etc to exchange link state/topology
> information (case of I-NNI), reachability information (case of E-NNI,
> UNI) and routing information (connection setup). This is at the moment
> also referred to as "intra-layer" information exchange.
> 
> For the case we decide that a Network Engineering agent is included in
> an SC, we will get also "inter-layer" information exchange. E.g.
> HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> layer network. For the case we decide that Network Engineering agents
> are not part of the SC (but in a separate "layer network topology
> controller" (LNTC)), "inter-layer" information exchange will be between
> an SC and a LNTC. This latter model has a preference at the moment,
> while the two processes (SC: routing, LNTC: network topology) have a
> different scope.
> 
> Note - LNTC within one layer network have to communicate with each other
> also to build up an understanding of potential topology capabilities
> present in the layer network (or layer network partition the LNTC is
> responsible for).
> 
> Separate of the above, the ASON recommendations will specify the signal
> flow over inter domain interfaces where
> - a customer interconnects with an operator
> - two operators interconnect
> - two vendors interconnect.
> 
> Over these inter domain interfaces you have to comply to the signal
> (message) structure. For ASON networks this will be based on the layer
> network structure. Within one domain the same layer network structured
> approach may be used, or one may decide to create a "spaghetti mountain"
> in which the layer network structure is not adhered to. That's up to the
> individual vendor.
> 
> Regards,
> 
> Maarten
> 
> "Bernstein, Greg" wrote:
> >
> > Hi Maarten, Diego, et. al.
> > what's interesting here is the question of what do we mean by "its own
> > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
> > those switches that are LOVC capable.  Other switches need not be involved.
> > If it turns out that the LOVC capable switches are not interconnected by a
> > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
> > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > switches before we set up the LOVC LSPs.
> >
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.  Well actually as Maarten wrote in a recent
> > ITU document that we would be primarily interested in those layers involved
> > in dynamic switching/multiplexing.  Note that we've started to bring in
> > non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> > (the WDM--SONET example I always give).
> >
> > With the signaling protocol things are really separated by who is involved
> > in the signaling transaction.  In the routing case things are less clear,
> > i.e., who wants/needs to know information about other layers and what burden
> > does this present to the NEs and scalability.  Which layers can benefit by
> > integration...  I'll be updating the Optical inter-domain route requirements
> > draft soon (with others) and will be exploring some of these items in more
> > depth.
> >
> > (Terminology: LOVC := Lower order virtual container, SDH term that includes
> > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> > the SDH hierarchy).
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Monday, June 11, 2001 7:46 AM
> > To: Diego Caviglia
> > Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> > Subject: Re: GMPLS Sonet extensions
> >
> > Diego,
> >
> > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > and OCh) will have its own (instance of) control plane.
> >
> > Each switched layer network runs a copy of the generic routing protocol;
> > it does so within the boundaries of the switched layer network.
> >
> > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > interfaces due to partitioning of a switched layer network. Topology
> > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > the other hand only provide reachability information.
> >
> > For the case an MPLS router is from a different organisation than the
> > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > the interface will be an MPLS-I-NNI.
> > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > section layers) the interface relation is to be determined independent
> > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > as at the HOVC layer entwork only reachability information is available
> > in the MPLS router (HOVC-E-NNI).
> >
> > The MPLS router should not be concerned at all about the routing of the
> > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > link between is needed between MPLS router A and MPLS router B, router A
> > needs to have knowledge of router B's address/name only to request a
> > VC-4-16c/STS-48c connection through the transport network. The switched
> > HOVC (transport) network will take care of the connection setup.
> >
> > And even if two diverse routed connections are required (e.g. to support
> > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > needs to request only the creation of 2 VC-4-16c connections with the
> > constraint of being diversely routed. The switched HOVC network will be
> > able to provide these two connections diversely routed between A and B
> > routers.
> >
> > At the moment, I recognise two connection types in a layer network:
> >         - native connections and
> >         - client connections.
> > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > native connection, and a DS3 connection or a LOVC link is a client
> > connection. A client connection is supported by the HOVC layer network
> > after adapting it to the layer network signal type (i.e. STS1 (to
> > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > can have a
> >         - 1:1,
> >         - 1:n,
> >         - n:1
> > relationship with the underlying layer network signal.
> > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > relationship.
> >
> > With client connections, an I-NNI is almost per definition not possible
> > (you go outside the layer network). Nevertheless, some people consider
> > the special 1:1 case as an area where an I-NNI could be deployed; of
> > course not for the case of DS3 -> STS1, but for the case of
> > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > HOVC layer network and a client signal to the OCh and ODU1 layer
> > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > wavelenght it is easy to think to be within one and the same layer
> > network. Personally, I believe that such very special case looks much
> > brighter than it is in the long term. I.e. don't declare very special
> > cases to be the common ones; keep those as very special cases, best even
> > keep those as regular cases obeying to the generic rules.
> >
> > Client connections as such have UNI or E-NNI interface relationships
> > over which reachability information is offered at best. This is the case
> > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > link over a HOVC/STS layer network).
> >
> > Regards,
> >
> > Maarten
> >
> > Diego Caviglia wrote:
> > >
> > > Maarten,
> > >                     I agree in principle with you but this means it would
> > be
> > > necessary to have a routing protocol for each layer doesn't it?
> > >
> > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > plane, your
> > > layered view of the network implies again the separation of the control
> > planes.
> > >
> > > The  Transport  Network is very different from a flat IP network and
> > layering in
> > > TN is implicit.
> > >
> > > If  I  understood your model correctly the MPLS Router only views, Access
> > Groups
> > > and  links  to  other  MPLS Routers. If there are free resources between
> > the two
> > > routers  the TE process calculates, accordingly to some rules, the best
> > path.
> >
> > Agree.
> >
> > > If
> > > there are no resources a call to the Network Engineering agent is
> > performed, the
> > > NE  makes a call to the TE of the SONET layer in order to provide a trail
> > to the
> > > MPLS layer (this procedure is repeated until available resources are
> > created for
> > > the MPLS router connection). This trail modifies the topology at the MPLS
> > layer.
> >
> > Agree. One note however, operators have indicated that they would like
> > to deploy policies in the NE agent which may include some thresholds,
> > before it decides to change the topology of the layer network. E.g.
> > topology is not extended unless X calls failed. On the other hand, the
> > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > hour extra links are added or bandwidth of existing link is extended,
> > and at the end of busy hour the reverse is happening.
> >
> > >
> > > If  my  understanding is correct and we want to implement an automated TN
> > a sort
> > > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> >
> > UNI or E-NNI.
> >
> > >
> > > Maybe this will create some problems, on the other hand, as Maarten
> > pointed out,
> > > flat  networks  won't  work due the huge amount of routing information
> > that they
> > > have to carry.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Susumu Yoneda <[email-masked]>
> > >
> > >  cc:      [email-masked], Jimmy Gendron
> > >           <[email-masked]>, [email-masked](bcc:
> > >           Diego Caviglia/MAIN/MC1)
> > >
> > >
> > >
> > >  Subject: Re: GMPLS Sonet extensions
> > >
> > >
> > > Sharma,
> > >
> > > "flat" set up is the route to disaster... simply consider a switched
> > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > would get information of all these levels... an absolute disaster in a
> > > world wide switched transport network would be the result.
> > >
> > > Therefore, there is this layering in which a server layer network
> > > provides bandwidth to its client layer entworks. the client layer
> > > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > > can route their signals.
> > >
> > > A separate entity (I called it "network engineering") is looking over
> > > the shoulder of the call setup process to see if more bandwidth is
> > > needed and when it would be needed or not longer required. But today,
> > > this separate entity is not part of the control plane; it is in the
> > > management plane.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Susumu Yoneda wrote:
> > > >
> > > > Sharma,
> > > >
> > > > Thank you for letting me know your presentation material which looks
> > very
> > > > interesting. It seems to me that a layered setup would make a sense.
> > > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > > would not be seen by users?
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [mailto:[email-masked]]
> > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > > Subject: RE: GMPLS Sonet extensions
> > > >
> > > > Jimmy, Susumu,
> > > >
> > > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > > have the same view of the network, you could compute an ERO at the
> > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > to the egress router.
> > > > (Note, however, that the PATH message will travel
> > > > on the out-of-band IP control network; therefore, it would be
> > non-associated
> > > > signaling.)
> > > >
> > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > in fact, have to be shared by all nodes, since that is precisely what
> > > > the "peer model" implies.
> > > >
> > > > But you do have to be careful about what "LSP" you are requesting, since
> > the
> > > > characteristics of the requested LSP are not interpreted in the same way
> > by
> > > > the
> > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > different
> > > > way of defining a circuit than an IP router or an OXC.)
> > > > Therefore, one possibility would be to do a "layered setup", where an
> > LSP
> > > > at the lower layer is setup before the PATH message at the higher layer
> > > > is tunnelled over it or allowed to propagate further.
> > > >
> > > > For example, when the PATH message for the packet
> > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > > a corresponding SONET circuit between themselves, and then either tunnel
> > > > the PATH message for the packet LSP over this circuit, or (assuming your
> > > > out-of-band network), at that time, allow the PATH message for the
> > packet
> > > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > > channel, likewise, would be a recursive process, with the OXC first
> > setting
> > > > up an optical lightpath between themselves, and tunneling the request to
> > > > set up the SONET channel over it, once that lightpath is setup.)
> > > >
> > > > A more detailed discussion of this subject, with corresponding
> > animations
> > > > and figures, that you may also find helpful is available in a talk I
> > gave at
> > > > MPLSCon'01, and can be found at:
> > > > http://www.mplscon.com/missing_presentations.htm
> > > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > > >
> > > > -Vishal
> > > >
> > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > [SMTP:[email-masked]]
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I also assume that there would be an out-of-band signalling network
> > based
> > > > on
> > > > > a suite of GMPLS protocols including LMP. I think there will be issues
> > to
> > > > > address whether all messages will be shared by all nodes, i.e router,
> > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > -------------------------------
> > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > Information & Communication Labs.
> > > > > e-mail  [email-masked]
> > > > > -------------------------------
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf
> > > > Of
> > > > > Jimmy Gendron
> > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > To: [email-masked]'
> > > > > Subject: GMPLS Sonet extensions
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > understand
> > > > > most of the architecture, but I still have a question since the
> > beginning;
> > > > > as an unified control plane, how do the routing/signaling protocols
> > > > exchange
> > > > > informations on a configuration like this:
> > > > >
> > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > (Ingress)
> > > > >
> > > > > Its a basic point to point configuration, but it will allow me to
> > > > understand
> > > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> > the
> > > > two
> > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > (Assuming
> > > > > that we have an out-of-band IP control network running LMP)
> > > > >
> > > > > My guess is that the PATH message will leave the ingress router with a
> > > > PATH
> > > > > message with a calculated ERO. It assumes that the network is in
> > respect
> > > > > with the peer model...everyone have the same routing table and know
> > the
> > > > > actual network topology. So, my PATH message will follow the CSPF
> > (ERO)
> > > > and
> > > > > go to the egress router. Am I right?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jimmy Gendron
> > > > >
--------------659DBFFCE48B83F81DD81695
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------659DBFFCE48B83F81DD81695--

Delivery-date: Tue, 12 Jun 2001 03:51:39 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Diego Caviglia'" <[email-masked]>, Maarten Vissers <[email-masked]>
Cc: "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, "[email-masked]" <[email-masked]>, Jimmy Gendron <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Tue, 12 Jun 2001 03:52:52 -0700

Diego,

Comments inline.

-Vishal
On Tuesday, June 12, 2001 2:51 AM, Diego Caviglia 
[SMTP:[email-masked]] wrote:
>
>
> Maaeten,
>
>                 In my understanding Greg's sentence (but of course the last
>                 word
> on  the  matter  of  his  sentence  is  up  to him) refers to the possibility
> of
> aggregating  information  from  different  layers in order to have less
> protocol
> instances than layers.
>
> If we consider all the possible layers inside the TN we have:
>
> 1.   LOVC
>
> 2.   HOVC
>
> 3.   ODU1
>
> 4.   ODU2
>
> 5.   ODU3
>
> 6.   Lambda

Exactly right.

> Moreover  we  have to take into account for Lambda switching purpose the type
> of
> the  fiber  (I  mean if the fiber is G.655, G.653, G.652 and maybe the vendor
> of
> the fiber) and for diversity routing purpose the duct layer.
>
> Do  we  need  to  aggregate  information  from  these layers? If so how could
> we
> aggregate layers?

Good question. I believe it is this aggregation that Greg was alluding to
in his email, but we'll wait to hear what he has to say.

> Is  OSPF/IS-IS with extension the right choice in this layered environment or
> do
> we have to move to another routing protocol?
>
> The  routing  protocol(s) have to cope with lots of constraints and with lots
> of
> problems  that  were not in the "flat" IP networks for which they were
> designed.

Exactly the point! This is indeed what needs to be looked at carefully.
Of course, this does not mean abandoning the layered network approach
(Maarten would certainly think that will collapse the global transport network 
:-)).
But... it does mean a thorough examination of the available protocols,
in the light of what is needed, to see if they can be made to fit the bill, and
yet be made scalable, or if something new entirely might be needed.

> e.g.  can a LOVC request trigger a HOVC trail creation? Repeating the process
> it
> could  be  possible  that  a  LOVC  request triggers a Lambda trail that from
> an
> operator perspective, which I suppose is not desirable.

Technically, in a layered network under a common control plane this could
certainly happen. However, when a request crosses the "layers" in a layered
network in this manner, I believe it would have to have some interaction with
the EMS/NMS or a policy engine somewhere that would need to determine
what kind of HOVC or lambda trail needs to be setup to accommodate this
(and possibly future) requests.

> Maarten Vissers <[email-masked]> on 12/06/2001 10.18.38
> 
> 
   
> 
> 
   
> 
> 
   
>
>
>
>
>
>  To:      "Bernstein, Greg" <[email-masked]>
>
>  cc:      Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda
>           <[email-masked]>, [email-masked],
>           Jimmy Gendron <[email-masked]>,
>           [email-masked]
>
>
>
>  Subject: Re: GMPLS Sonet extensions
>
>
>
>
>
>
>
>
> Greg,
>
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.
>
> I am not sure I understand the meaning of the last sentence... does it
> refer to:
> a common Signalling Communication Network (SCN) over which all
> signalling messages are transported for all layer networks?
>
> The ASON model under definition shows per switched layer network a
> hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
> Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
> These SCs communicate with each other over the SCN. LOVC-SCs communicate
> with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
> communicate with other ODU1-SCs, etc to exchange link state/topology
> information (case of I-NNI), reachability information (case of E-NNI,
> UNI) and routing information (connection setup). This is at the moment
> also referred to as "intra-layer" information exchange.
>
> For the case we decide that a Network Engineering agent is included in
> an SC, we will get also "inter-layer" information exchange. E.g.
> HOVC-SCs may also communicate with LOVC-SCs to provide reachability
> information for ports (e.g. STS1 and VC4 access groups) within the LOVC
> layer network. For the case we decide that Network Engineering agents
> are not part of the SC (but in a separate "layer network topology
> controller" (LNTC)), "inter-layer" information exchange will be between
> an SC and a LNTC. This latter model has a preference at the moment,
> while the two processes (SC: routing, LNTC: network topology) have a
> different scope.
>
> Note - LNTC within one layer network have to communicate with each other
> also to build up an understanding of potential topology capabilities
> present in the layer network (or layer network partition the LNTC is
> responsible for).
>
>
>
> Separate of the above, the ASON recommendations will specify the signal
> flow over inter domain interfaces where
> - a customer interconnects with an operator
> - two operators interconnect
> - two vendors interconnect.
>
> Over these inter domain interfaces you have to comply to the signal
> (message) structure. For ASON networks this will be based on the layer
> network structure. Within one domain the same layer network structured
> approach may be used, or one may decide to create a "spaghetti mountain"
> in which the layer network structure is not adhered to. That's up to the
> individual vendor.
>
> Regards,
>
> Maarten
>
>
>
>
> "Bernstein, Greg" wrote:
> >
> > Hi Maarten, Diego, et. al.
> > what's interesting here is the question of what do we mean by "its own
> > instance of a control plane"?  Obviously if we are setting up a LOVC (in
> > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling
> > to
> > those switches that are LOVC capable.  Other switches need not be involved.
> > If it turns out that the LOVC capable switches are not interconnected by a
> > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> > appropriate HOVC interconnecting the LOVC needs to be setup first.  In
> > GMPLS
> > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> > switches before we set up the LOVC LSPs.
> >
> > Since we have to (a) be able to set up connects at the appropriate layers,
> > (b) understand the topology at each layer, to me this sounds like an
> > instance of a control plane at each layer.
> > However, it doesn't necessarily tell me whether I'd want to (or not)
> > integrate multiple layer information into a protocol and run fewer protocol
> > instances than network layers.  Well actually as Maarten wrote in a recent
> > ITU document that we would be primarily interested in those layers involved
> > in dynamic switching/multiplexing.  Note that we've started to bring in
> > non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> > (the WDM--SONET example I always give).
> >
> > With the signaling protocol things are really separated by who is involved
> > in the signaling transaction.  In the routing case things are less clear,
> > i.e., who wants/needs to know information about other layers and what
> > burden
> > does this present to the NEs and scalability.  Which layers can benefit by
> > integration...  I'll be updating the Optical inter-domain route
> > requirements
> > draft soon (with others) and will be exploring some of these items in more
> > depth.
> >
> > (Terminology: LOVC := Lower order virtual container, SDH term that includes
> > signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> > the SDH hierarchy).
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Monday, June 11, 2001 7:46 AM
> > To: Diego Caviglia
> > Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> > Subject: Re: GMPLS Sonet extensions
> >
> > Diego,
> >
> > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> > and OCh) will have its own (instance of) control plane.
> >
> > Each switched layer network runs a copy of the generic routing protocol;
> > it does so within the boundaries of the switched layer network.
> >
> > Within each switched layer network you will find UNI, E-NNI and I-NNI
> > interfaces due to partitioning of a switched layer network. Topology
> > information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> > the other hand only provide reachability information.
> >
> > For the case an MPLS router is from a different organisation than the
> > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> > interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> > the interface will be an MPLS-I-NNI.
> > For the server layers within the MPLS router (e.g. HOVC and STM-N
> > section layers) the interface relation is to be determined independent
> > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> > at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> > as at the HOVC layer entwork only reachability information is available
> > in the MPLS router (HOVC-E-NNI).
> >
> > The MPLS router should not be concerned at all about the routing of the
> > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> > between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> > link between is needed between MPLS router A and MPLS router B, router A
> > needs to have knowledge of router B's address/name only to request a
> > VC-4-16c/STS-48c connection through the transport network. The switched
> > HOVC (transport) network will take care of the connection setup.
> >
> > And even if two diverse routed connections are required (e.g. to support
> > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> > needs to request only the creation of 2 VC-4-16c connections with the
> > constraint of being diversely routed. The switched HOVC network will be
> > able to provide these two connections diversely routed between A and B
> > routers.
> >
> > At the moment, I recognise two connection types in a layer network:
> >         - native connections and
> >         - client connections.
> > Example: within a HOVC layer network a STS1 or VC-4 connection is a
> > native connection, and a DS3 connection or a LOVC link is a client
> > connection. A client connection is supported by the HOVC layer network
> > after adapting it to the layer network signal type (i.e. STS1 (to
> > support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> > can have a
> >         - 1:1,
> >         - 1:n,
> >         - n:1
> > relationship with the underlying layer network signal.
> > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> > relationship.
> >
> > With client connections, an I-NNI is almost per definition not possible
> > (you go outside the layer network). Nevertheless, some people consider
> > the special 1:1 case as an area where an I-NNI could be deployed; of
> > course not for the case of DS3 -> STS1, but for the case of
> > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> > HOVC layer network and a client signal to the OCh and ODU1 layer
> > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> > wavelenght it is easy to think to be within one and the same layer
> > network. Personally, I believe that such very special case looks much
> > brighter than it is in the long term. I.e. don't declare very special
> > cases to be the common ones; keep those as very special cases, best even
> > keep those as regular cases obeying to the generic rules.
> >
> > Client connections as such have UNI or E-NNI interface relationships
> > over which reachability information is offered at best. This is the case
> > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> > layer entwork) as well as "vertical client connections" (e.g. a LOVC
> > link over a HOVC/STS layer network).
> >
> > Regards,
> >
> > Maarten
> >
> > Diego Caviglia wrote:
> > >
> > > Maarten,
> > >                     I agree in principle with you but this means it would
> > be
> > > necessary to have a routing protocol for each layer doesn't it?
> > >
> > > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> > plane, your
> > > layered view of the network implies again the separation of the control
> > planes.
> > >
> > > The  Transport  Network is very different from a flat IP network and
> > layering in
> > > TN is implicit.
> > >
> > > If  I  understood your model correctly the MPLS Router only views, Access
> > Groups
> > > and  links  to  other  MPLS Routers. If there are free resources between
> > the two
> > > routers  the TE process calculates, accordingly to some rules, the best
> > path.
> >
> > Agree.
> >
> > > If
> > > there are no resources a call to the Network Engineering agent is
> > performed, the
> > > NE  makes a call to the TE of the SONET layer in order to provide a trail
> > to the
> > > MPLS layer (this procedure is repeated until available resources are
> > created for
> > > the MPLS router connection). This trail modifies the topology at the MPLS
> > layer.
> >
> > Agree. One note however, operators have indicated that they would like
> > to deploy policies in the NE agent which may include some thresholds,
> > before it decides to change the topology of the layer network. E.g.
> > topology is not extended unless X calls failed. On the other hand, the
> > NE agent may have scheduled topology changes; e.g. at the begin of busy
> > hour extra links are added or bandwidth of existing link is extended,
> > and at the end of busy hour the reverse is happening.
> >
> > >
> > > If  my  understanding is correct and we want to implement an automated TN
> > a sort
> > > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> >
> > UNI or E-NNI.
> >
> > >
> > > Maybe this will create some problems, on the other hand, as Maarten
> > pointed out,
> > > flat  networks  won't  work due the huge amount of routing information
> > that they
> > > have to carry.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Susumu Yoneda <[email-masked]>
> > >
> > >  cc:      [email-masked], Jimmy Gendron
> > >           <[email-masked]>, [email-masked](bcc:
> > >           Diego Caviglia/MAIN/MC1)
> > >
> > >
> > >
> > >  Subject: Re: GMPLS Sonet extensions
> > >
> > >
> > > Sharma,
> > >
> > > "flat" set up is the route to disaster... simply consider a switched
> > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > > would get information of all these levels... an absolute disaster in a
> > > world wide switched transport network would be the result.
> > >
> > > Therefore, there is this layering in which a server layer network
> > > provides bandwidth to its client layer entworks. the client layer
> > > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > > can route their signals.
> > >
> > > A separate entity (I called it "network engineering") is looking over
> > > the shoulder of the call setup process to see if more bandwidth is
> > > needed and when it would be needed or not longer required. But today,
> > > this separate entity is not part of the control plane; it is in the
> > > management plane.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Susumu Yoneda wrote:
> > > >
> > > > Sharma,
> > > >
> > > > Thank you for letting me know your presentation material which looks
> > very
> > > > interesting. It seems to me that a layered setup would make a sense.
> > > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > > would not be seen by users?
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [mailto:[email-masked]]
> > > > Sent: Saturday, June 09, 2001 11:06 AM
> > > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > > Subject: RE: GMPLS Sonet extensions
> > > >
> > > > Jimmy, Susumu,
> > > >
> > > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > > have the same view of the network, you could compute an ERO at the
> > > > ingress router and have the PATH message follow the hop-by-hop route
> > > > to the egress router.
> > > > (Note, however, that the PATH message will travel
> > > > on the out-of-band IP control network; therefore, it would be
> > non-associated
> > > > signaling.)
> > > >
> > > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > > in fact, have to be shared by all nodes, since that is precisely what
> > > > the "peer model" implies.
> > > >
> > > > But you do have to be careful about what "LSP" you are requesting,
> > > > since
> > the
> > > > characteristics of the requested LSP are not interpreted in the same
> > > > way
> > by
> > > > the
> > > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > > different
> > > > way of defining a circuit than an IP router or an OXC.)
> > > > Therefore, one possibility would be to do a "layered setup", where an
> > LSP
> > > > at the lower layer is setup before the PATH message at the higher layer
> > > > is tunnelled over it or allowed to propagate further.
> > > >
> > > > For example, when the PATH message for the packet
> > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > > a corresponding SONET circuit between themselves, and then either
> > > > tunnel
> > > > the PATH message for the packet LSP over this circuit, or (assuming
> > > > your
> > > > out-of-band network), at that time, allow the PATH message for the
> > packet
> > > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > > channel, likewise, would be a recursive process, with the OXC first
> > setting
> > > > up an optical lightpath between themselves, and tunneling the request
> > > > to
> > > > set up the SONET channel over it, once that lightpath is setup.)
> > > >
> > > > A more detailed discussion of this subject, with corresponding
> > animations
> > > > and figures, that you may also find helpful is available in a talk I
> > gave at
> > > > MPLSCon'01, and can be found at:
> > > > http://www.mplscon.com/missing_presentations.htm
> > > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > > >
> > > > -Vishal
> > > >
> > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > > [SMTP:[email-masked]]
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I also assume that there would be an out-of-band signalling network
> > based
> > > > on
> > > > > a suite of GMPLS protocols including LMP. I think there will be
> > > > > issues
> > to
> > > > > address whether all messages will be shared by all nodes, i.e router,
> > > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > > -------------------------------
> > > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > > Japan Telecom    fax +81 3 5540 8485
> > > > > Information & Communication Labs.
> > > > > e-mail  [email-masked]
> > > > > -------------------------------
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf
> > > > Of
> > > > > Jimmy Gendron
> > > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > > To: [email-masked]'
> > > > > Subject: GMPLS Sonet extensions
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I used to read almost all stuff regarding GMPLS since a week. I
> > understand
> > > > > most of the architecture, but I still have a question since the
> > beginning;
> > > > > as an unified control plane, how do the routing/signaling protocols
> > > > exchange
> > > > > informations on a configuration like this:
> > > > >
> > > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > > (Ingress)
> > > > >
> > > > > Its a basic point to point configuration, but it will allow me to
> > > > understand
> > > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> > the
> > > > two
> > > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > > (Assuming
> > > > > that we have an out-of-band IP control network running LMP)
> > > > >
> > > > > My guess is that the PATH message will leave the ingress router with
> > > > > a
> > > > PATH
> > > > > message with a calculated ERO. It assumes that the network is in
> > respect
> > > > > with the peer model...everyone have the same routing table and know
> > the
> > > > > actual network topology. So, my PATH message will follow the CSPF
> > (ERO)
> > > > and
> > > > > go to the egress router. Am I right?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Jimmy Gendron
> > > > >
>  << File: mvissers.vcf >> 

Delivery-date: Tue, 12 Jun 2001 03:19:24 -0700
From: "Diego Caviglia" <[email-masked]>
To: Maarten Vissers <[email-masked]>
cc: "Bernstein, Greg" <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Tue, 12 Jun 2001 11:51:14 +0200
Subject: Re: GMPLS Sonet extensions

--0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Maaeten,

                In my understanding Greg's sentence (but of course the last word
on  the  matter  of  his  sentence  is  up  to him) refers to the possibility of
aggregating  information  from  different  layers in order to have less protocol
instances than layers.

If we consider all the possible layers inside the TN we have:

1.   LOVC

2.   HOVC

3.   ODU1

4.   ODU2

5.   ODU3

6.   Lambda

Moreover  we  have to take into account for Lambda switching purpose the type of
the  fiber  (I  mean if the fiber is G.655, G.653, G.652 and maybe the vendor of
the fiber) and for diversity routing purpose the duct layer.

Do  we  need  to  aggregate  information  from  these layers? If so how could we
aggregate layers?

Is  OSPF/IS-IS with extension the right choice in this layered environment or do
we have to move to another routing protocol?

The  routing  protocol(s) have to cope with lots of constraints and with lots of
problems  that  were not in the "flat" IP networks for which they were designed.
e.g.  can a LOVC request trigger a HOVC trail creation? Repeating the process it
could  be  possible  that  a  LOVC  request triggers a Lambda trail that from an
operator perspective, which I suppose is not desirable.

Best regards.

Diego

Maarten Vissers <[email-masked]> on 12/06/2001 10.18.38

                                                                                

                                                              

 To:      "Bernstein, Greg" <[email-masked]>                 
                                                              
 cc:      Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda       
          <[email-masked]>, [email-masked],      
          Jimmy Gendron <[email-masked]>,             
          [email-masked]                                  

                                                              
 Subject: Re: GMPLS Sonet extensions                          

Greg,

> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer protocol
> instances than network layers.

I am not sure I understand the meaning of the last sentence... does it
refer to:
a common Signalling Communication Network (SCN) over which all
signalling messages are transported for all layer networks?

The ASON model under definition shows per switched layer network a
hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
These SCs communicate with each other over the SCN. LOVC-SCs communicate
with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
communicate with other ODU1-SCs, etc to exchange link state/topology
information (case of I-NNI), reachability information (case of E-NNI,
UNI) and routing information (connection setup). This is at the moment
also referred to as "intra-layer" information exchange.

For the case we decide that a Network Engineering agent is included in
an SC, we will get also "inter-layer" information exchange. E.g.
HOVC-SCs may also communicate with LOVC-SCs to provide reachability
information for ports (e.g. STS1 and VC4 access groups) within the LOVC
layer network. For the case we decide that Network Engineering agents
are not part of the SC (but in a separate "layer network topology
controller" (LNTC)), "inter-layer" information exchange will be between
an SC and a LNTC. This latter model has a preference at the moment,
while the two processes (SC: routing, LNTC: network topology) have a
different scope.

Note - LNTC within one layer network have to communicate with each other
also to build up an understanding of potential topology capabilities
present in the layer network (or layer network partition the LNTC is
responsible for).

Separate of the above, the ASON recommendations will specify the signal
flow over inter domain interfaces where
- a customer interconnects with an operator
- two operators interconnect
- two vendors interconnect.

Over these inter domain interfaces you have to comply to the signal
(message) structure. For ASON networks this will be based on the layer
network structure. Within one domain the same layer network structured
approach may be used, or one may decide to create a "spaghetti mountain"
in which the layer network structure is not adhered to. That's up to the
individual vendor.

Regards,

Maarten

"Bernstein, Greg" wrote:
>
> Hi Maarten, Diego, et. al.
> what's interesting here is the question of what do we mean by "its own
> instance of a control plane"?  Obviously if we are setting up a LOVC (in
> SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
> those switches that are LOVC capable.  Other switches need not be involved.
> If it turns out that the LOVC capable switches are not interconnected by a
> HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
> speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> switches before we set up the LOVC LSPs.
>
> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer protocol
> instances than network layers.  Well actually as Maarten wrote in a recent
> ITU document that we would be primarily interested in those layers involved
> in dynamic switching/multiplexing.  Note that we've started to bring in
> non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> (the WDM--SONET example I always give).
>
> With the signaling protocol things are really separated by who is involved
> in the signaling transaction.  In the routing case things are less clear,
> i.e., who wants/needs to know information about other layers and what burden
> does this present to the NEs and scalability.  Which layers can benefit by
> integration...  I'll be updating the Optical inter-domain route requirements
> draft soon (with others) and will be exploring some of these items in more
> depth.
>
> (Terminology: LOVC := Lower order virtual container, SDH term that includes
> signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> the SDH hierarchy).
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 7:46 AM
> To: Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> Subject: Re: GMPLS Sonet extensions
>
> Diego,
>
> Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> and OCh) will have its own (instance of) control plane.
>
> Each switched layer network runs a copy of the generic routing protocol;
> it does so within the boundaries of the switched layer network.
>
> Within each switched layer network you will find UNI, E-NNI and I-NNI
> interfaces due to partitioning of a switched layer network. Topology
> information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> the other hand only provide reachability information.
>
> For the case an MPLS router is from a different organisation than the
> transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> the interface will be an MPLS-I-NNI.
> For the server layers within the MPLS router (e.g. HOVC and STM-N
> section layers) the interface relation is to be determined independent
> of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> as at the HOVC layer entwork only reachability information is available
> in the MPLS router (HOVC-E-NNI).
>
> The MPLS router should not be concerned at all about the routing of the
> HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> link between is needed between MPLS router A and MPLS router B, router A
> needs to have knowledge of router B's address/name only to request a
> VC-4-16c/STS-48c connection through the transport network. The switched
> HOVC (transport) network will take care of the connection setup.
>
> And even if two diverse routed connections are required (e.g. to support
> VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> needs to request only the creation of 2 VC-4-16c connections with the
> constraint of being diversely routed. The switched HOVC network will be
> able to provide these two connections diversely routed between A and B
> routers.
>
> At the moment, I recognise two connection types in a layer network:
>         - native connections and
>         - client connections.
> Example: within a HOVC layer network a STS1 or VC-4 connection is a
> native connection, and a DS3 connection or a LOVC link is a client
> connection. A client connection is supported by the HOVC layer network
> after adapting it to the layer network signal type (i.e. STS1 (to
> support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> can have a
>         - 1:1,
>         - 1:n,
>         - n:1
> relationship with the underlying layer network signal.
> Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> relationship.
>
> With client connections, an I-NNI is almost per definition not possible
> (you go outside the layer network). Nevertheless, some people consider
> the special 1:1 case as an area where an I-NNI could be deployed; of
> course not for the case of DS3 -> STS1, but for the case of
> STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> HOVC layer network and a client signal to the OCh and ODU1 layer
> networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> wavelenght it is easy to think to be within one and the same layer
> network. Personally, I believe that such very special case looks much
> brighter than it is in the long term. I.e. don't declare very special
> cases to be the common ones; keep those as very special cases, best even
> keep those as regular cases obeying to the generic rules.
>
> Client connections as such have UNI or E-NNI interface relationships
> over which reachability information is offered at best. This is the case
> for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> layer entwork) as well as "vertical client connections" (e.g. a LOVC
> link over a HOVC/STS layer network).
>
> Regards,
>
> Maarten
>
> Diego Caviglia wrote:
> >
> > Maarten,
> >                     I agree in principle with you but this means it would
> be
> > necessary to have a routing protocol for each layer doesn't it?
> >
> > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> plane, your
> > layered view of the network implies again the separation of the control
> planes.
> >
> > The  Transport  Network is very different from a flat IP network and
> layering in
> > TN is implicit.
> >
> > If  I  understood your model correctly the MPLS Router only views, Access
> Groups
> > and  links  to  other  MPLS Routers. If there are free resources between
> the two
> > routers  the TE process calculates, accordingly to some rules, the best
> path.
>
> Agree.
>
> > If
> > there are no resources a call to the Network Engineering agent is
> performed, the
> > NE  makes a call to the TE of the SONET layer in order to provide a trail
> to the
> > MPLS layer (this procedure is repeated until available resources are
> created for
> > the MPLS router connection). This trail modifies the topology at the MPLS
> layer.
>
> Agree. One note however, operators have indicated that they would like
> to deploy policies in the NE agent which may include some thresholds,
> before it decides to change the topology of the layer network. E.g.
> topology is not extended unless X calls failed. On the other hand, the
> NE agent may have scheduled topology changes; e.g. at the begin of busy
> hour extra links are added or bandwidth of existing link is extended,
> and at the end of busy hour the reverse is happening.
>
> >
> > If  my  understanding is correct and we want to implement an automated TN
> a sort
> > of UNI has to be put between the NE at layer N and the TE at layer N-1.
>
> UNI or E-NNI.
>
> >
> > Maybe this will create some problems, on the other hand, as Maarten
> pointed out,
> > flat  networks  won't  work due the huge amount of routing information
> that they
> > have to carry.
> >
> > Regards
> >
> > Diego
> >
> > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> >
> >
> >
> >
> >
> >
> >
> >  To:      Susumu Yoneda <[email-masked]>
> >
> >  cc:      [email-masked], Jimmy Gendron
> >           <[email-masked]>, [email-masked](bcc:
> >           Diego Caviglia/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: GMPLS Sonet extensions
> >
> >
> > Sharma,
> >
> > "flat" set up is the route to disaster... simply consider a switched
> > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > would get information of all these levels... an absolute disaster in a
> > world wide switched transport network would be the result.
> >
> > Therefore, there is this layering in which a server layer network
> > provides bandwidth to its client layer entworks. the client layer
> > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > can route their signals.
> >
> > A separate entity (I called it "network engineering") is looking over
> > the shoulder of the call setup process to see if more bandwidth is
> > needed and when it would be needed or not longer required. But today,
> > this separate entity is not part of the control plane; it is in the
> > management plane.
> >
> > Regards,
> >
> > Maarten
> >
> > Susumu Yoneda wrote:
> > >
> > > Sharma,
> > >
> > > Thank you for letting me know your presentation material which looks
> very
> > > interesting. It seems to me that a layered setup would make a sense.
> > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > would not be seen by users?
> > >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: Saturday, June 09, 2001 11:06 AM
> > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > Subject: RE: GMPLS Sonet extensions
> > >
> > > Jimmy, Susumu,
> > >
> > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > have the same view of the network, you could compute an ERO at the
> > > ingress router and have the PATH message follow the hop-by-hop route
> > > to the egress router.
> > > (Note, however, that the PATH message will travel
> > > on the out-of-band IP control network; therefore, it would be
> non-associated
> > > signaling.)
> > >
> > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > in fact, have to be shared by all nodes, since that is precisely what
> > > the "peer model" implies.
> > >
> > > But you do have to be careful about what "LSP" you are requesting, since
> the
> > > characteristics of the requested LSP are not interpreted in the same way
> by
> > > the
> > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > different
> > > way of defining a circuit than an IP router or an OXC.)
> > > Therefore, one possibility would be to do a "layered setup", where an
> LSP
> > > at the lower layer is setup before the PATH message at the higher layer
> > > is tunnelled over it or allowed to propagate further.
> > >
> > > For example, when the PATH message for the packet
> > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > a corresponding SONET circuit between themselves, and then either tunnel
> > > the PATH message for the packet LSP over this circuit, or (assuming your
> > > out-of-band network), at that time, allow the PATH message for the
> packet
> > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > channel, likewise, would be a recursive process, with the OXC first
> setting
> > > up an optical lightpath between themselves, and tunneling the request to
> > > set up the SONET channel over it, once that lightpath is setup.)
> > >
> > > A more detailed discussion of this subject, with corresponding
> animations
> > > and figures, that you may also find helpful is available in a talk I
> gave at
> > > MPLSCon'01, and can be found at:
> > > http://www.mplscon.com/missing_presentations.htm
> > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > >
> > > -Vishal
> > >
> > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Hi,
> > > >
> > > > I also assume that there would be an out-of-band signalling network
> based
> > > on
> > > > a suite of GMPLS protocols including LMP. I think there will be issues
> to
> > > > address whether all messages will be shared by all nodes, i.e router,
> > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > -------------------------------
> > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > Japan Telecom    fax +81 3 5540 8485
> > > > Information & Communication Labs.
> > > > e-mail  [email-masked]
> > > > -------------------------------
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> Behalf
> > > Of
> > > > Jimmy Gendron
> > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > To: [email-masked]'
> > > > Subject: GMPLS Sonet extensions
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I used to read almost all stuff regarding GMPLS since a week. I
> understand
> > > > most of the architecture, but I still have a question since the
> beginning;
> > > > as an unified control plane, how do the routing/signaling protocols
> > > exchange
> > > > informations on a configuration like this:
> > > >
> > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > (Ingress)
> > > >
> > > > Its a basic point to point configuration, but it will allow me to
> > > understand
> > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> the
> > > two
> > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > (Assuming
> > > > that we have an out-of-band IP control network running LMP)
> > > >
> > > > My guess is that the PATH message will leave the ingress router with a
> > > PATH
> > > > message with a calculated ERO. It assumes that the network is in
> respect
> > > > with the peer model...everyone have the same routing table and know
> the
> > > > actual network topology. So, my PATH message will follow the CSPF
> (ERO)
> > > and
> > > > go to the egress router. Am I right?
> > > >
> > > > Best regards,
> > > >
> > > > Jimmy Gendron
> > > >

--0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5
Content-type: application/octet-stream; 
	name="mvissers.vcf"
Content-Disposition: attachment; filename="mvissers.vcf"
Content-transfer-encoding: base64

YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1
DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7
d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO
ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K
ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i
ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh
dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh
cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K

--0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5--

Delivery-date: Tue, 12 Jun 2001 01:21:41 -0700
Cc: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Tue, 12 Jun 2001 10:18:38 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------0A9E3D8D94ED6A15EFAB5D30
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer protocol
> instances than network layers.  

I am not sure I understand the meaning of the last sentence... does it
refer to:
a common Signalling Communication Network (SCN) over which all
signalling messages are transported for all layer networks? 

The ASON model under definition shows per switched layer network a
hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork.
Subnetworks may be nested, and the lowest level subnetwork is a Fabric.
These SCs communicate with each other over the SCN. LOVC-SCs communicate
with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs
communicate with other ODU1-SCs, etc to exchange link state/topology
information (case of I-NNI), reachability information (case of E-NNI,
UNI) and routing information (connection setup). This is at the moment
also referred to as "intra-layer" information exchange.

For the case we decide that a Network Engineering agent is included in
an SC, we will get also "inter-layer" information exchange. E.g.
HOVC-SCs may also communicate with LOVC-SCs to provide reachability
information for ports (e.g. STS1 and VC4 access groups) within the LOVC
layer network. For the case we decide that Network Engineering agents
are not part of the SC (but in a separate "layer network topology
controller" (LNTC)), "inter-layer" information exchange will be between
an SC and a LNTC. This latter model has a preference at the moment,
while the two processes (SC: routing, LNTC: network topology) have a
different scope.

Note - LNTC within one layer network have to communicate with each other
also to build up an understanding of potential topology capabilities
present in the layer network (or layer network partition the LNTC is
responsible for).

Separate of the above, the ASON recommendations will specify the signal
flow over inter domain interfaces where
- a customer interconnects with an operator
- two operators interconnect
- two vendors interconnect.

Over these inter domain interfaces you have to comply to the signal
(message) structure. For ASON networks this will be based on the layer
network structure. Within one domain the same layer network structured
approach may be used, or one may decide to create a "spaghetti mountain"
in which the layer network structure is not adhered to. That's up to the
individual vendor.

Regards,

Maarten

"Bernstein, Greg" wrote:
> 
> Hi Maarten, Diego, et. al.
> what's interesting here is the question of what do we mean by "its own
> instance of a control plane"?  Obviously if we are setting up a LOVC (in
> SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
> those switches that are LOVC capable.  Other switches need not be involved.
> If it turns out that the LOVC capable switches are not interconnected by a
> HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
> speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> switches before we set up the LOVC LSPs.
> 
> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer protocol
> instances than network layers.  Well actually as Maarten wrote in a recent
> ITU document that we would be primarily interested in those layers involved
> in dynamic switching/multiplexing.  Note that we've started to bring in
> non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> (the WDM--SONET example I always give).
> 
> With the signaling protocol things are really separated by who is involved
> in the signaling transaction.  In the routing case things are less clear,
> i.e., who wants/needs to know information about other layers and what burden
> does this present to the NEs and scalability.  Which layers can benefit by
> integration...  I'll be updating the Optical inter-domain route requirements
> draft soon (with others) and will be exploring some of these items in more
> depth.
> 
> (Terminology: LOVC := Lower order virtual container, SDH term that includes
> signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> the SDH hierarchy).
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 7:46 AM
> To: Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> Diego,
> 
> Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> and OCh) will have its own (instance of) control plane.
> 
> Each switched layer network runs a copy of the generic routing protocol;
> it does so within the boundaries of the switched layer network.
> 
> Within each switched layer network you will find UNI, E-NNI and I-NNI
> interfaces due to partitioning of a switched layer network. Topology
> information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> the other hand only provide reachability information.
> 
> For the case an MPLS router is from a different organisation than the
> transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> the interface will be an MPLS-I-NNI.
> For the server layers within the MPLS router (e.g. HOVC and STM-N
> section layers) the interface relation is to be determined independent
> of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> as at the HOVC layer entwork only reachability information is available
> in the MPLS router (HOVC-E-NNI).
> 
> The MPLS router should not be concerned at all about the routing of the
> HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> link between is needed between MPLS router A and MPLS router B, router A
> needs to have knowledge of router B's address/name only to request a
> VC-4-16c/STS-48c connection through the transport network. The switched
> HOVC (transport) network will take care of the connection setup.
> 
> And even if two diverse routed connections are required (e.g. to support
> VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> needs to request only the creation of 2 VC-4-16c connections with the
> constraint of being diversely routed. The switched HOVC network will be
> able to provide these two connections diversely routed between A and B
> routers.
> 
> At the moment, I recognise two connection types in a layer network:
>         - native connections and
>         - client connections.
> Example: within a HOVC layer network a STS1 or VC-4 connection is a
> native connection, and a DS3 connection or a LOVC link is a client
> connection. A client connection is supported by the HOVC layer network
> after adapting it to the layer network signal type (i.e. STS1 (to
> support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> can have a
>         - 1:1,
>         - 1:n,
>         - n:1
> relationship with the underlying layer network signal.
> Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> relationship.
> 
> With client connections, an I-NNI is almost per definition not possible
> (you go outside the layer network). Nevertheless, some people consider
> the special 1:1 case as an area where an I-NNI could be deployed; of
> course not for the case of DS3 -> STS1, but for the case of
> STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> HOVC layer network and a client signal to the OCh and ODU1 layer
> networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> wavelenght it is easy to think to be within one and the same layer
> network. Personally, I believe that such very special case looks much
> brighter than it is in the long term. I.e. don't declare very special
> cases to be the common ones; keep those as very special cases, best even
> keep those as regular cases obeying to the generic rules.
> 
> Client connections as such have UNI or E-NNI interface relationships
> over which reachability information is offered at best. This is the case
> for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> layer entwork) as well as "vertical client connections" (e.g. a LOVC
> link over a HOVC/STS layer network).
> 
> Regards,
> 
> Maarten
> 
> Diego Caviglia wrote:
> >
> > Maarten,
> >                     I agree in principle with you but this means it would
> be
> > necessary to have a routing protocol for each layer doesn't it?
> >
> > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> plane, your
> > layered view of the network implies again the separation of the control
> planes.
> >
> > The  Transport  Network is very different from a flat IP network and
> layering in
> > TN is implicit.
> >
> > If  I  understood your model correctly the MPLS Router only views, Access
> Groups
> > and  links  to  other  MPLS Routers. If there are free resources between
> the two
> > routers  the TE process calculates, accordingly to some rules, the best
> path.
> 
> Agree.
> 
> > If
> > there are no resources a call to the Network Engineering agent is
> performed, the
> > NE  makes a call to the TE of the SONET layer in order to provide a trail
> to the
> > MPLS layer (this procedure is repeated until available resources are
> created for
> > the MPLS router connection). This trail modifies the topology at the MPLS
> layer.
> 
> Agree. One note however, operators have indicated that they would like
> to deploy policies in the NE agent which may include some thresholds,
> before it decides to change the topology of the layer network. E.g.
> topology is not extended unless X calls failed. On the other hand, the
> NE agent may have scheduled topology changes; e.g. at the begin of busy
> hour extra links are added or bandwidth of existing link is extended,
> and at the end of busy hour the reverse is happening.
> 
> >
> > If  my  understanding is correct and we want to implement an automated TN
> a sort
> > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> 
> UNI or E-NNI.
> 
> >
> > Maybe this will create some problems, on the other hand, as Maarten
> pointed out,
> > flat  networks  won't  work due the huge amount of routing information
> that they
> > have to carry.
> >
> > Regards
> >
> > Diego
> >
> > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> >
> >
> >
> >
> >
> >
> >
> >  To:      Susumu Yoneda <[email-masked]>
> >
> >  cc:      [email-masked], Jimmy Gendron
> >           <[email-masked]>, [email-masked](bcc:
> >           Diego Caviglia/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: GMPLS Sonet extensions
> >
> >
> > Sharma,
> >
> > "flat" set up is the route to disaster... simply consider a switched
> > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > would get information of all these levels... an absolute disaster in a
> > world wide switched transport network would be the result.
> >
> > Therefore, there is this layering in which a server layer network
> > provides bandwidth to its client layer entworks. the client layer
> > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > can route their signals.
> >
> > A separate entity (I called it "network engineering") is looking over
> > the shoulder of the call setup process to see if more bandwidth is
> > needed and when it would be needed or not longer required. But today,
> > this separate entity is not part of the control plane; it is in the
> > management plane.
> >
> > Regards,
> >
> > Maarten
> >
> > Susumu Yoneda wrote:
> > >
> > > Sharma,
> > >
> > > Thank you for letting me know your presentation material which looks
> very
> > > interesting. It seems to me that a layered setup would make a sense.
> > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > would not be seen by users?
> > >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: Saturday, June 09, 2001 11:06 AM
> > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > Subject: RE: GMPLS Sonet extensions
> > >
> > > Jimmy, Susumu,
> > >
> > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > have the same view of the network, you could compute an ERO at the
> > > ingress router and have the PATH message follow the hop-by-hop route
> > > to the egress router.
> > > (Note, however, that the PATH message will travel
> > > on the out-of-band IP control network; therefore, it would be
> non-associated
> > > signaling.)
> > >
> > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > in fact, have to be shared by all nodes, since that is precisely what
> > > the "peer model" implies.
> > >
> > > But you do have to be careful about what "LSP" you are requesting, since
> the
> > > characteristics of the requested LSP are not interpreted in the same way
> by
> > > the
> > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > different
> > > way of defining a circuit than an IP router or an OXC.)
> > > Therefore, one possibility would be to do a "layered setup", where an
> LSP
> > > at the lower layer is setup before the PATH message at the higher layer
> > > is tunnelled over it or allowed to propagate further.
> > >
> > > For example, when the PATH message for the packet
> > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > a corresponding SONET circuit between themselves, and then either tunnel
> > > the PATH message for the packet LSP over this circuit, or (assuming your
> > > out-of-band network), at that time, allow the PATH message for the
> packet
> > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > channel, likewise, would be a recursive process, with the OXC first
> setting
> > > up an optical lightpath between themselves, and tunneling the request to
> > > set up the SONET channel over it, once that lightpath is setup.)
> > >
> > > A more detailed discussion of this subject, with corresponding
> animations
> > > and figures, that you may also find helpful is available in a talk I
> gave at
> > > MPLSCon'01, and can be found at:
> > > http://www.mplscon.com/missing_presentations.htm
> > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > >
> > > -Vishal
> > >
> > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Hi,
> > > >
> > > > I also assume that there would be an out-of-band signalling network
> based
> > > on
> > > > a suite of GMPLS protocols including LMP. I think there will be issues
> to
> > > > address whether all messages will be shared by all nodes, i.e router,
> > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > -------------------------------
> > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > Japan Telecom    fax +81 3 5540 8485
> > > > Information & Communication Labs.
> > > > e-mail  [email-masked]
> > > > -------------------------------
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> Behalf
> > > Of
> > > > Jimmy Gendron
> > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > To: [email-masked]'
> > > > Subject: GMPLS Sonet extensions
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I used to read almost all stuff regarding GMPLS since a week. I
> understand
> > > > most of the architecture, but I still have a question since the
> beginning;
> > > > as an unified control plane, how do the routing/signaling protocols
> > > exchange
> > > > informations on a configuration like this:
> > > >
> > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > (Ingress)
> > > >
> > > > Its a basic point to point configuration, but it will allow me to
> > > understand
> > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> the
> > > two
> > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > (Assuming
> > > > that we have an out-of-band IP control network running LMP)
> > > >
> > > > My guess is that the PATH message will leave the ingress router with a
> > > PATH
> > > > message with a calculated ERO. It assumes that the network is in
> respect
> > > > with the peer model...everyone have the same routing table and know
> the
> > > > actual network topology. So, my PATH message will follow the CSPF
> (ERO)
> > > and
> > > > go to the egress router. Am I right?
> > > >
> > > > Best regards,
> > > >
> > > > Jimmy Gendron
> > > >
--------------0A9E3D8D94ED6A15EFAB5D30
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------0A9E3D8D94ED6A15EFAB5D30--

Delivery-date: Mon, 11 Jun 2001 15:38:36 -0700
From: "Raju Venkatraman" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Fwd: GMPLS Questions, Doubts
Date: Mon, 11 Jun 2001 22:36:50 -0000

>From: "Raju Venkatraman" <[email-masked]>
>To: [email-masked]
>Subject: GMPLS Questions, Doubts
>Date: Sat, 09 Jun 2001 21:09:39 -0000
>
>Hi,
>
>I was just going through GMPLS drafts and I've some questions. Actually not
>able to understand few things. Any help would be greatly appreciated.
>
>* Should the signalling module (control plane) be aware of all the data
>channels/links under its control? In GMPLS, as it would be used in optical
>networks and a no. of interfaces would be present [not all carrying the
>signalling information] between GMPLS-enabled optical nodes, I don't feel
>it's required. The association of signalling link/channel(s) to data
>links/channels could be mainatained outside the sigannling module.
>
>* Where one would like to maintain the diffserv related intelligence while
>setting up L-LSP and E-LSPs - would it would be assumed to be with routing
>module or signalling module?
>
>I know, these things vary from implementation to implmentation, but just
>wanted to hear your thoughts in this regard.
>
>Thanks in advance.
>Raju
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>

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

Delivery-date: Mon, 11 Jun 2001 13:35:00 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, Susumu Yoneda <[email-masked]>, "'Diego Caviglia'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Jimmy Gendron <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Mon, 11 Jun 2001 13:35:16 -0700

Hi Maarten,

Thanks for your note and clarification.

Just to clarify, however, I was not proposing that route setup be done in
a "flat" way. I was merely outlining how signaling could work
in a multi-layer network.

The issue of whether the network is "flat" or not is mainly a routing
issue (how many instances of the route protocol, how those instances
may interact, etc.), with signaling coming in when one wants a UNI
(which would be needed in a non-flat network, as Diego already
pointed out in one of his recent emails.)

So I am not a proponet of any particular routing approach. In fact,
quite a bit of prior work on the SDH/SONET signaling that I've been
involved with has alluded
to the layered nature of the transport network, and to the fact
that routing would have to be appropriately designed for multi-layer
circuit setup to work.

Thanks,
-Vishal

On Monday, June 11, 2001 4:17 AM, Maarten Vissers [SMTP:[email-masked]] 
wrote:
> Sharma,
>
> "flat" set up is the route to disaster... simply consider a switched
> transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> would get information of all these levels... an absolute disaster in a
> world wide switched transport network would be the result.
>
> Therefore, there is this layering in which a server layer network
> provides bandwidth to its client layer entworks. the client layer
> networks see this bandwidth as kind of "fixed" bandwidth over which they
> can route their signals.
>
> A separate entity (I called it "network engineering") is looking over
> the shoulder of the call setup process to see if more bandwidth is
> needed and when it would be needed or not longer required. But today,
> this separate entity is not part of the control plane; it is in the
> management plane.
>
> Regards,
>
> Maarten
>
> Susumu Yoneda wrote:
> >
> > Sharma,
> >
> > Thank you for letting me know your presentation material which looks very
> > interesting. It seems to me that a layered setup would make a sense.
> > However, users may want to have a "flat" setup. Therefore, lower setups
> > would not be seen by users?
> >
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: Saturday, June 09, 2001 11:06 AM
> > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > Subject: RE: GMPLS Sonet extensions
> >
> > Jimmy, Susumu,
> >
> > Your idea (assuming a peer model) is basically correct. Since all nodes
> > have the same view of the network, you could compute an ERO at the
> > ingress router and have the PATH message follow the hop-by-hop route
> > to the egress router.
> > (Note, however, that the PATH message will travel
> > on the out-of-band IP control network; therefore, it would be non-
> > associated
> > signaling.)
> >
> > Also, Susumu, if the peer model is in effect, then all messges will,
> > in fact, have to be shared by all nodes, since that is precisely what
> > the "peer model" implies.
> >
> > But you do have to be careful about what "LSP" you are requesting, since
> > the
> > characteristics of the requested LSP are not interpreted in the same way by
> > the
> > various pieces of equipment in your figure. (A SONET ADM requires a
> > different
> > way of defining a circuit than an IP router or an OXC.)
> > Therefore, one possibility would be to do a "layered setup", where an LSP
> > at the lower layer is setup before the PATH message at the higher layer
> > is tunnelled over it or allowed to propagate further.
> >
> > For example, when the PATH message for the packet
> > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > a corresponding SONET circuit between themselves, and then either tunnel
> > the PATH message for the packet LSP over this circuit, or (assuming your
> > out-of-band network), at that time, allow the PATH message for the packet
> > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > channel, likewise, would be a recursive process, with the OXC first setting
> > up an optical lightpath between themselves, and tunneling the request to
> > set up the SONET channel over it, once that lightpath is setup.)
> >
> > A more detailed discussion of this subject, with corresponding animations
> > and figures, that you may also find helpful is available in a talk I gave
> > at
> > MPLSCon'01, and can be found at:
> > http://www.mplscon.com/missing_presentations.htm
> > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> >
> > -Vishal
> >
> > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > [SMTP:[email-masked]]
> > wrote:
> > > Hi,
> > >
> > > I also assume that there would be an out-of-band signalling network based
> > on
> > > a suite of GMPLS protocols including LMP. I think there will be issues to
> > > address whether all messages will be shared by all nodes, i.e router,
> > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > -------------------------------
> > > Susumu Yoneda   tel +81 3 5540 8493
> > > Japan Telecom    fax +81 3 5540 8485
> > > Information & Communication Labs.
> > > e-mail  [email-masked]
> > > -------------------------------
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of
> > > Jimmy Gendron
> > > Sent: Friday, June 08, 2001 10:01 PM
> > > To: [email-masked]'
> > > Subject: GMPLS Sonet extensions
> > >
> > >
> > > Hi,
> > >
> > > I used to read almost all stuff regarding GMPLS since a week. I
> > > understand
> > > most of the architecture, but I still have a question since the 
beginning;
> > >
> > > as an unified control plane, how do the routing/signaling protocols
> > exchange
> > > informations on a configuration like this:
> > >
> > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > (Ingress)
> > >
> > > Its a basic point to point configuration, but it will allow me to
> > understand
> > > the basic features of GMPLS. If I want to create an MPLS LSP between the
> > two
> > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > (Assuming
> > > that we have an out-of-band IP control network running LMP)
> > >
> > > My guess is that the PATH message will leave the ingress router with a
> > PATH
> > > message with a calculated ERO. It assumes that the network is in respect
> > > with the peer model...everyone have the same routing table and know the
> > > actual network topology. So, my PATH message will follow the CSPF (ERO)
> > and
> > > go to the egress router. Am I right?
> > >
> > > Best regards,
> > >
> > > Jimmy Gendron
> > > << File: mvissers.vcf >> 

Delivery-date: Mon, 11 Jun 2001 13:31:43 -0700
From: Wenjing Chu <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, 'Maarten Vissers' <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Susumu Yoneda <[email-masked]>, [email-masked],  Jimmy Gendron <[email-masked]>, [email-masked]
Subject: RE: GMPLS Sonet extensions
Date: Mon, 11 Jun 2001 12:41:09 -0700

> 
> With the signaling protocol things are really separated by 
> who is involved
> in the signaling transaction.  In the routing case things are 
> less clear,
> i.e., who wants/needs to know information about other layers 
> and what burden
> does this present to the NEs and scalability.  Which layers 
> can benefit by
> integration...  I'll be updating the Optical inter-domain 
> route requirements
> draft soon (with others) and will be exploring some of these 
> items in more
> depth.
> 

Very much to the point. Routing integration is the interesting part. Whether
and how much to integrate different layers become critical in maintaining
scalability and bringing about the benefit of layer integration. Flexibility
is needed in various trade-off points between "overlay" and "peer".

Wenjing
Turin Networks 

Delivery-date: Mon, 11 Jun 2001 11:59:44 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: GMPLS Sonet extensions
Date: Mon, 11 Jun 2001 19:58:12 +0100

Hi Greg.....you might find re-visting the 'Freeland' draft BT submitted to
the 12/00 San Diego mtg helpful when reviewing the OTN inter-domain routing
work you mentioned below.

Some other observations on this discussion are:

-	there is vertical layering between technologies and horizontal
partitioning within/per (single technology) layer networks.  The latter is a
very important aspect, since it is usually associated with commercial
management domains (and can also involve different vendor interworking).  So
we can have a single management domain at technology/layer N served by
several different disjoint/tandemmed commercial domains at layer
N-1......clearly these relationships can recurse.

-	as we get closer to the duct layer network (yes it is a real layer
network) the trail holding times must increase for stability.....so the need
for SVC-like services decreases as we move to the duct.

-	I find it hard to understand how any operator will be able to make a
valid business case for large BW L1 SVC services;  SVCs need a 'law of large
numbers' environment such that any single instance of a demand is almost
unoticable on the network....so as we get closer to the duct:- S-PVCs yes,
SVCs no;  so we really don't need UNIs, but we do need NNIs (and different
interior and exterior NNIs);

-	unless one has total control of all layer networks to the duct then
one cannot even contemplate an accurate view of resources (including
resilience design.....since disjoint connectivity in all client layers is
defined/inherited from the duct layer).  The immediate corrolary of this is
that if any operator wishes to serve a global customer base then:
(i) that operator must accept peering with other operators and
virtualisation of server layers......and note that in such a relationship
each peering operator will demand isolation of what is/is-not allowed to be
advertised/controlled across that (exterior) NNI....which usually means this
reduces to simple reachability; OR
(ii) that operator must build out (to the duct) globally.
Guess which model has more chance of obtaining acceptance with operators
(especially their finance people!)?

-	SDH will be a client of the OTN......and there will be several
client layers of SDH.  These layer networks are commercially important to
operators and cannot be discounted.  It is also an interesting exercise to
find out just what a sizeable business peer (or as Maarten calls them
'native') managed BW demands are on the L1 networks.....probably bigger than
most non-operators realise.

-	we (I am speaking as BT here) can set-up L1 trails in SDH very fast
now using management tools....introducing a control-plane is not going to
speed up the process by any significant degree unless it can also dig
trenches, lay ducts, install equipment and do order processing, link to
billing (and all our other OSS), etc!

As I said, the Freeland draft from BT has additional pointers as to what we,
as at least one operator, need for the L1 networks if a control-plane is
introduced.  But as to the choice of the the most *appropriate*
control-plane facets, that is a different question ;-).  But one thing is
for sure......there will have to be hard decoupling between client layers
and the SDH/OTN server layers.  This is not really a technical issue for
argument, it is commercial necessity.

regards, Neil

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: 11 June 2001 17:14
> To: 'Maarten Vissers'; Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; 
> [email-masked]
> Subject: RE: GMPLS Sonet extensions
> 
> 
> Hi Maarten, Diego, et. al.
> what's interesting here is the question of what do we mean by "its own
> instance of a control plane"?  Obviously if we are setting up 
> a LOVC (in
> SONET, say a VT1.5 capable of carrying a DS1 signal) we will 
> be signaling to
> those switches that are LOVC capable.  Other switches need 
> not be involved.
> If it turns out that the LOVC capable switches are not 
> interconnected by a
> HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> appropriate HOVC interconnecting the LOVC needs to be setup 
> first.  In GMPLS
> speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> switches before we set up the LOVC LSPs.
> 
> Since we have to (a) be able to set up connects at the 
> appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run 
> fewer protocol
> instances than network layers.  Well actually as Maarten 
> wrote in a recent
> ITU document that we would be primarily interested in those 
> layers involved
> in dynamic switching/multiplexing.  Note that we've started 
> to bring in
> non-dynamic layer information via other mechanisms, e.g., the 
> SRLG concept
> (the WDM--SONET example I always give).
> 
> With the signaling protocol things are really separated by 
> who is involved
> in the signaling transaction.  In the routing case things are 
> less clear,
> i.e., who wants/needs to know information about other layers 
> and what burden
> does this present to the NEs and scalability.  Which layers 
> can benefit by
> integration...  I'll be updating the Optical inter-domain 
> route requirements
> draft soon (with others) and will be exploring some of these 
> items in more
> depth.
> 
> (Terminology: LOVC := Lower order virtual container, SDH term 
> that includes
> signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := 
> Higher order
> virtual container, SDH terms that includes signals between 
> 50Mbps-40Gbps in
> the SDH hierarchy).
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation 
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 7:46 AM
> To: Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; 
> [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> 
> Diego,
> 
> Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> and OCh) will have its own (instance of) control plane. 
> 
> Each switched layer network runs a copy of the generic 
> routing protocol;
> it does so within the boundaries of the switched layer network.
> 
> Within each switched layer network you will find UNI, E-NNI and I-NNI
> interfaces due to partitioning of a switched layer network. Topology
> information is exchanged only via I-NNI interfaces. E-NNI 
> interfaces on
> the other hand only provide reachability information.
> 
> For the case an MPLS router is from a different organisation than the
> transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> the interface will be an MPLS-I-NNI.
> For the server layers within the MPLS router (e.g. HOVC and STM-N
> section layers) the interface relation is to be determined independent
> of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it 
> migth be that
> at MPLS level full topology information is exchanged 
> (MPLS-I-NNI), where
> as at the HOVC layer entwork only reachability information is 
> available
> in the MPLS router (HOVC-E-NNI).
> 
> The MPLS router should not be concerned at all about the 
> routing of the
> HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> between two adjacent MPLS routers. For the case an additional 
> 2.5G MPLS
> link between is needed between MPLS router A and MPLS router 
> B, router A
> needs to have knowledge of router B's address/name only to request a
> VC-4-16c/STS-48c connection through the transport network. 
> The switched
> HOVC (transport) network will take care of the connection setup.
> 
> And even if two diverse routed connections are required (e.g. 
> to support
> VC-4-16c SNC protection within the A and B MPLS routers), 
> MPLS router A
> needs to request only the creation of 2 VC-4-16c connections with the
> constraint of being diversely routed. The switched HOVC 
> network will be
> able to provide these two connections diversely routed between A and B
> routers.
> 
> 
> 
> At the moment, I recognise two connection types in a layer network: 
> 	- native connections and 
> 	- client connections. 
> Example: within a HOVC layer network a STS1 or VC-4 connection is a
> native connection, and a DS3 connection or a LOVC link is a client
> connection. A client connection is supported by the HOVC layer network
> after adapting it to the layer network signal type (i.e. STS1 (to
> support DS3), STS1 or VC4 (to support LOVC link)). The client 
> connection
> can have a
> 	- 1:1,
> 	- 1:n, 
> 	- n:1 
> relationship with the underlying layer network signal.
> Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> relationship.
> 
> With client connections, an I-NNI is almost per definition 
> not possible
> (you go outside the layer network). Nevertheless, some people consider
> the special 1:1 case as an area where an I-NNI could be deployed; of
> course not for the case of DS3 -> STS1, but for the case of
> STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and 
> STS-192c/VC-4-64c
> -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> HOVC layer network and a client signal to the OCh and ODU1 layer
> networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> wavelenght it is easy to think to be within one and the same layer
> network. Personally, I believe that such very special case looks much
> brighter than it is in the long term. I.e. don't declare very special
> cases to be the common ones; keep those as very special 
> cases, best even
> keep those as regular cases obeying to the generic rules.
> 
> Client connections as such have UNI or E-NNI interface relationships
> over which reachability information is offered at best. This 
> is the case
> for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> layer entwork) as well as "vertical client connections" (e.g. a LOVC
> link over a HOVC/STS layer network).
> 
> Regards,
> 
> Maarten
> 
> 
> Diego Caviglia wrote:
> > 
> > Maarten,
> >                     I agree in principle with you but this 
> means it would
> be
> > necessary to have a routing protocol for each layer doesn't it?
> > 
> > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> plane, your
> > layered view of the network implies again the separation of 
> the control
> planes.
> > 
> > The  Transport  Network is very different from a flat IP network and
> layering in
> > TN is implicit.
> > 
> > If  I  understood your model correctly the MPLS Router only 
> views, Access
> Groups
> > and  links  to  other  MPLS Routers. If there are free 
> resources between
> the two
> > routers  the TE process calculates, accordingly to some 
> rules, the best
> path. 
> 
> Agree.
> 
> > If
> > there are no resources a call to the Network Engineering agent is
> performed, the
> > NE  makes a call to the TE of the SONET layer in order to 
> provide a trail
> to the
> > MPLS layer (this procedure is repeated until available resources are
> created for
> > the MPLS router connection). This trail modifies the 
> topology at the MPLS
> layer.
> 
> Agree. One note however, operators have indicated that they would like
> to deploy policies in the NE agent which may include some thresholds,
> before it decides to change the topology of the layer network. E.g.
> topology is not extended unless X calls failed. On the other hand, the
> NE agent may have scheduled topology changes; e.g. at the 
> begin of busy
> hour extra links are added or bandwidth of existing link is extended,
> and at the end of busy hour the reverse is happening.
> 
> > 
> > If  my  understanding is correct and we want to implement 
> an automated TN
> a sort
> > of UNI has to be put between the NE at layer N and the TE 
> at layer N-1.
> 
> UNI or E-NNI.
> 
> > 
> > Maybe this will create some problems, on the other hand, as Maarten
> pointed out,
> > flat  networks  won't  work due the huge amount of routing 
> information
> that they
> > have to carry.
> > 
> > Regards
> > 
> > Diego
> > 
> > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  To:      Susumu Yoneda <[email-masked]>
> > 
> >  cc:      [email-masked], Jimmy Gendron
> >           <[email-masked]>, [email-masked](bcc:
> >           Diego Caviglia/MAIN/MC1)
> > 
> > 
> > 
> >  Subject: Re: GMPLS Sonet extensions
> > 
> > 
> > Sharma,
> > 
> > "flat" set up is the route to disaster... simply consider a switched
> > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and 
> perhaps also DS0,
> > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > would get information of all these levels... an absolute 
> disaster in a
> > world wide switched transport network would be the result.
> > 
> > Therefore, there is this layering in which a server layer network
> > provides bandwidth to its client layer entworks. the client layer
> > networks see this bandwidth as kind of "fixed" bandwidth 
> over which they
> > can route their signals.
> > 
> > A separate entity (I called it "network engineering") is 
> looking over
> > the shoulder of the call setup process to see if more bandwidth is
> > needed and when it would be needed or not longer required. 
> But today,
> > this separate entity is not part of the control plane; it is in the
> > management plane.
> > 
> > Regards,
> > 
> > Maarten
> > 
> > Susumu Yoneda wrote:
> > >
> > > Sharma,
> > >
> > > Thank you for letting me know your presentation material 
> which looks
> very
> > > interesting. It seems to me that a layered setup would 
> make a sense.
> > > However, users may want to have a "flat" setup. 
> Therefore, lower setups
> > > would not be seen by users?
> > >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: Saturday, June 09, 2001 11:06 AM
> > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > Subject: RE: GMPLS Sonet extensions
> > >
> > > Jimmy, Susumu,
> > >
> > > Your idea (assuming a peer model) is basically correct. 
> Since all nodes
> > > have the same view of the network, you could compute an ERO at the
> > > ingress router and have the PATH message follow the 
> hop-by-hop route
> > > to the egress router.
> > > (Note, however, that the PATH message will travel
> > > on the out-of-band IP control network; therefore, it would be
> non-associated
> > > signaling.)
> > >
> > > Also, Susumu, if the peer model is in effect, then all 
> messges will,
> > > in fact, have to be shared by all nodes, since that is 
> precisely what
> > > the "peer model" implies.
> > >
> > > But you do have to be careful about what "LSP" you are 
> requesting, since
> the
> > > characteristics of the requested LSP are not interpreted 
> in the same way
> by
> > > the
> > > various pieces of equipment in your figure. (A SONET ADM 
> requires a
> > > different
> > > way of defining a circuit than an IP router or an OXC.)
> > > Therefore, one possibility would be to do a "layered 
> setup", where an
> LSP
> > > at the lower layer is setup before the PATH message at 
> the higher layer
> > > is tunnelled over it or allowed to propagate further.
> > >
> > > For example, when the PATH message for the packet
> > > LSP arrives at the SONET ADM, the peer SONET ADMs would 
> have to setup
> > > a corresponding SONET circuit between themselves, and 
> then either tunnel
> > > the PATH message for the packet LSP over this circuit, or 
> (assuming your
> > > out-of-band network), at that time, allow the PATH message for the
> packet
> > > LSP to propagate to the next MPLS router. (The setting up 
> of the SONET
> > > channel, likewise, would be a recursive process, with the 
> OXC first
> setting
> > > up an optical lightpath between themselves, and tunneling 
> the request to
> > > set up the SONET channel over it, once that lightpath is setup.)
> > >
> > > A more detailed discussion of this subject, with corresponding
> animations
> > > and figures, that you may also find helpful is available 
> in a talk I
> gave at
> > > MPLSCon'01, and can be found at:
> > > http://www.mplscon.com/missing_presentations.htm
> > > (Dynamic path establishment in MPLS-controlled 
> multi-service networks.)
> > >
> > > -Vishal
> > >
> > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Hi,
> > > >
> > > > I also assume that there would be an out-of-band 
> signalling network
> based
> > > on
> > > > a suite of GMPLS protocols including LMP. I think there 
> will be issues
> to
> > > > address whether all messages will be shared by all 
> nodes, i.e router,
> > > > SDH/SONET, and OXC or not. This will be a part of 
> security issues.
> > > > -------------------------------
> > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > Japan Telecom    fax +81 3 5540 8485
> > > > Information & Communication Labs.
> > > > e-mail  [email-masked]
> > > > -------------------------------
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf
> > > Of
> > > > Jimmy Gendron
> > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > To: [email-masked]'
> > > > Subject: GMPLS Sonet extensions
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I used to read almost all stuff regarding GMPLS since a week. I
> understand
> > > > most of the architecture, but I still have a question since the
> beginning;
> > > > as an unified control plane, how do the 
> routing/signaling protocols
> > > exchange
> > > > informations on a configuration like this:
> > > >
> > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM 
> ----------- WDM
> > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > (Ingress)
> > > >
> > > > Its a basic point to point configuration, but it will 
> allow me to
> > > understand
> > > > the basic features of GMPLS. If I want to create an 
> MPLS LSP between
> the
> > > two
> > > > MPLS routers, how do the RSVP PATH message is sent to 
> the network?
> > > (Assuming
> > > > that we have an out-of-band IP control network running LMP)
> > > >
> > > > My guess is that the PATH message will leave the 
> ingress router with a
> > > PATH
> > > > message with a calculated ERO. It assumes that the network is in
> respect
> > > > with the peer model...everyone have the same routing 
> table and know
> the
> > > > actual network topology. So, my PATH message will 
> follow the CSPF
> (ERO)
> > > and
> > > > go to the egress router. Am I right?
> > > >
> > > > Best regards,
> > > >
> > > > Jimmy Gendron
> > > >
> 

Delivery-date: Mon, 11 Jun 2001 11:10:37 -0700
Date: Mon, 11 Jun 2001 14:09:24 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, Diego Caviglia <[email-masked]>, Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

Hi all,

I think there are multiple ways that control plane can be realized:

* single control plane for all layers (single protocol, single process)
* single control plane for each layer (single protocol, single process,
multiple databases for each layer)
* multiple control plane for each layer (single protocol, multiple
processes)
* multiple control plane for each layer (multiple protocol, multiple
processes)

I think it's an implementation issue which one is chosen. The standards,
both GMPLS and ASTN, allows for any combinations. Of course, each
implementation will have it's own domain of use where it is better than
other implementations...

But I think that architecturally/functionally speaking, these can be
viewed as separate control planes controlling separate layers.

Or am I mistaken?

Zhi

"Bernstein, Greg" wrote:
> 
> Hi Maarten, Diego, et. al.
> what's interesting here is the question of what do we mean by "its own
> instance of a control plane"?  Obviously if we are setting up a LOVC (in
> SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
> those switches that are LOVC capable.  Other switches need not be involved.
> If it turns out that the LOVC capable switches are not interconnected by a
> HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
> appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
> speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
> switches before we set up the LOVC LSPs.
> 
> Since we have to (a) be able to set up connects at the appropriate layers,
> (b) understand the topology at each layer, to me this sounds like an
> instance of a control plane at each layer.
> However, it doesn't necessarily tell me whether I'd want to (or not)
> integrate multiple layer information into a protocol and run fewer protocol
> instances than network layers.  Well actually as Maarten wrote in a recent
> ITU document that we would be primarily interested in those layers involved
> in dynamic switching/multiplexing.  Note that we've started to bring in
> non-dynamic layer information via other mechanisms, e.g., the SRLG concept
> (the WDM--SONET example I always give).
> 
> With the signaling protocol things are really separated by who is involved
> in the signaling transaction.  In the routing case things are less clear,
> i.e., who wants/needs to know information about other layers and what burden
> does this present to the NEs and scalability.  Which layers can benefit by
> integration...  I'll be updating the Optical inter-domain route requirements
> draft soon (with others) and will be exploring some of these items in more
> depth.
> 
> (Terminology: LOVC := Lower order virtual container, SDH term that includes
> signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
> virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
> the SDH hierarchy).
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 7:46 AM
> To: Diego Caviglia
> Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
> Subject: Re: GMPLS Sonet extensions
> 
> Diego,
> 
> Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
> and OCh) will have its own (instance of) control plane.
> 
> Each switched layer network runs a copy of the generic routing protocol;
> it does so within the boundaries of the switched layer network.
> 
> Within each switched layer network you will find UNI, E-NNI and I-NNI
> interfaces due to partitioning of a switched layer network. Topology
> information is exchanged only via I-NNI interfaces. E-NNI interfaces on
> the other hand only provide reachability information.
> 
> For the case an MPLS router is from a different organisation than the
> transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
> interface. For the case the MPLS router is at the edge of a MPLS-VPN,
> the interface will be an MPLS-I-NNI.
> For the server layers within the MPLS router (e.g. HOVC and STM-N
> section layers) the interface relation is to be determined independent
> of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
> (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
> at MPLS level full topology information is exchanged (MPLS-I-NNI), where
> as at the HOVC layer entwork only reachability information is available
> in the MPLS router (HOVC-E-NNI).
> 
> The MPLS router should not be concerned at all about the routing of the
> HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
> between two adjacent MPLS routers. For the case an additional 2.5G MPLS
> link between is needed between MPLS router A and MPLS router B, router A
> needs to have knowledge of router B's address/name only to request a
> VC-4-16c/STS-48c connection through the transport network. The switched
> HOVC (transport) network will take care of the connection setup.
> 
> And even if two diverse routed connections are required (e.g. to support
> VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
> needs to request only the creation of 2 VC-4-16c connections with the
> constraint of being diversely routed. The switched HOVC network will be
> able to provide these two connections diversely routed between A and B
> routers.
> 
> At the moment, I recognise two connection types in a layer network:
>         - native connections and
>         - client connections.
> Example: within a HOVC layer network a STS1 or VC-4 connection is a
> native connection, and a DS3 connection or a LOVC link is a client
> connection. A client connection is supported by the HOVC layer network
> after adapting it to the layer network signal type (i.e. STS1 (to
> support DS3), STS1 or VC4 (to support LOVC link)). The client connection
> can have a
>         - 1:1,
>         - 1:n,
>         - n:1
> relationship with the underlying layer network signal.
> Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
> relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
> relationship.
> 
> With client connections, an I-NNI is almost per definition not possible
> (you go outside the layer network). Nevertheless, some people consider
> the special 1:1 case as an area where an I-NNI could be deployed; of
> course not for the case of DS3 -> STS1, but for the case of
> STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
> -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
> HOVC layer network and a client signal to the OCh and ODU1 layer
> networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
> wavelenght it is easy to think to be within one and the same layer
> network. Personally, I believe that such very special case looks much
> brighter than it is in the long term. I.e. don't declare very special
> cases to be the common ones; keep those as very special cases, best even
> keep those as regular cases obeying to the generic rules.
> 
> Client connections as such have UNI or E-NNI interface relationships
> over which reachability information is offered at best. This is the case
> for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
> layer entwork) as well as "vertical client connections" (e.g. a LOVC
> link over a HOVC/STS layer network).
> 
> Regards,
> 
> Maarten
> 
> Diego Caviglia wrote:
> >
> > Maarten,
> >                     I agree in principle with you but this means it would
> be
> > necessary to have a routing protocol for each layer doesn't it?
> >
> > One  of  the  initial  reasons  for  (G)MPLS is to unify the control
> plane, your
> > layered view of the network implies again the separation of the control
> planes.
> >
> > The  Transport  Network is very different from a flat IP network and
> layering in
> > TN is implicit.
> >
> > If  I  understood your model correctly the MPLS Router only views, Access
> Groups
> > and  links  to  other  MPLS Routers. If there are free resources between
> the two
> > routers  the TE process calculates, accordingly to some rules, the best
> path.
> 
> Agree.
> 
> > If
> > there are no resources a call to the Network Engineering agent is
> performed, the
> > NE  makes a call to the TE of the SONET layer in order to provide a trail
> to the
> > MPLS layer (this procedure is repeated until available resources are
> created for
> > the MPLS router connection). This trail modifies the topology at the MPLS
> layer.
> 
> Agree. One note however, operators have indicated that they would like
> to deploy policies in the NE agent which may include some thresholds,
> before it decides to change the topology of the layer network. E.g.
> topology is not extended unless X calls failed. On the other hand, the
> NE agent may have scheduled topology changes; e.g. at the begin of busy
> hour extra links are added or bandwidth of existing link is extended,
> and at the end of busy hour the reverse is happening.
> 
> >
> > If  my  understanding is correct and we want to implement an automated TN
> a sort
> > of UNI has to be put between the NE at layer N and the TE at layer N-1.
> 
> UNI or E-NNI.
> 
> >
> > Maybe this will create some problems, on the other hand, as Maarten
> pointed out,
> > flat  networks  won't  work due the huge amount of routing information
> that they
> > have to carry.
> >
> > Regards
> >
> > Diego
> >
> > Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> >
> >
> >
> >
> >
> >
> >
> >  To:      Susumu Yoneda <[email-masked]>
> >
> >  cc:      [email-masked], Jimmy Gendron
> >           <[email-masked]>, [email-masked](bcc:
> >           Diego Caviglia/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: GMPLS Sonet extensions
> >
> >
> > Sharma,
> >
> > "flat" set up is the route to disaster... simply consider a switched
> > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> > would get information of all these levels... an absolute disaster in a
> > world wide switched transport network would be the result.
> >
> > Therefore, there is this layering in which a server layer network
> > provides bandwidth to its client layer entworks. the client layer
> > networks see this bandwidth as kind of "fixed" bandwidth over which they
> > can route their signals.
> >
> > A separate entity (I called it "network engineering") is looking over
> > the shoulder of the call setup process to see if more bandwidth is
> > needed and when it would be needed or not longer required. But today,
> > this separate entity is not part of the control plane; it is in the
> > management plane.
> >
> > Regards,
> >
> > Maarten
> >
> > Susumu Yoneda wrote:
> > >
> > > Sharma,
> > >
> > > Thank you for letting me know your presentation material which looks
> very
> > > interesting. It seems to me that a layered setup would make a sense.
> > > However, users may want to have a "flat" setup. Therefore, lower setups
> > > would not be seen by users?
> > >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: Saturday, June 09, 2001 11:06 AM
> > > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > > Subject: RE: GMPLS Sonet extensions
> > >
> > > Jimmy, Susumu,
> > >
> > > Your idea (assuming a peer model) is basically correct. Since all nodes
> > > have the same view of the network, you could compute an ERO at the
> > > ingress router and have the PATH message follow the hop-by-hop route
> > > to the egress router.
> > > (Note, however, that the PATH message will travel
> > > on the out-of-band IP control network; therefore, it would be
> non-associated
> > > signaling.)
> > >
> > > Also, Susumu, if the peer model is in effect, then all messges will,
> > > in fact, have to be shared by all nodes, since that is precisely what
> > > the "peer model" implies.
> > >
> > > But you do have to be careful about what "LSP" you are requesting, since
> the
> > > characteristics of the requested LSP are not interpreted in the same way
> by
> > > the
> > > various pieces of equipment in your figure. (A SONET ADM requires a
> > > different
> > > way of defining a circuit than an IP router or an OXC.)
> > > Therefore, one possibility would be to do a "layered setup", where an
> LSP
> > > at the lower layer is setup before the PATH message at the higher layer
> > > is tunnelled over it or allowed to propagate further.
> > >
> > > For example, when the PATH message for the packet
> > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > > a corresponding SONET circuit between themselves, and then either tunnel
> > > the PATH message for the packet LSP over this circuit, or (assuming your
> > > out-of-band network), at that time, allow the PATH message for the
> packet
> > > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > > channel, likewise, would be a recursive process, with the OXC first
> setting
> > > up an optical lightpath between themselves, and tunneling the request to
> > > set up the SONET channel over it, once that lightpath is setup.)
> > >
> > > A more detailed discussion of this subject, with corresponding
> animations
> > > and figures, that you may also find helpful is available in a talk I
> gave at
> > > MPLSCon'01, and can be found at:
> > > http://www.mplscon.com/missing_presentations.htm
> > > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> > >
> > > -Vishal
> > >
> > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Hi,
> > > >
> > > > I also assume that there would be an out-of-band signalling network
> based
> > > on
> > > > a suite of GMPLS protocols including LMP. I think there will be issues
> to
> > > > address whether all messages will be shared by all nodes, i.e router,
> > > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > > -------------------------------
> > > > Susumu Yoneda   tel +81 3 5540 8493
> > > > Japan Telecom    fax +81 3 5540 8485
> > > > Information & Communication Labs.
> > > > e-mail  [email-masked]
> > > > -------------------------------
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> Behalf
> > > Of
> > > > Jimmy Gendron
> > > > Sent: Friday, June 08, 2001 10:01 PM
> > > > To: [email-masked]'
> > > > Subject: GMPLS Sonet extensions
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I used to read almost all stuff regarding GMPLS since a week. I
> understand
> > > > most of the architecture, but I still have a question since the
> beginning;
> > > > as an unified control plane, how do the routing/signaling protocols
> > > exchange
> > > > informations on a configuration like this:
> > > >
> > > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > > (Ingress)
> > > >
> > > > Its a basic point to point configuration, but it will allow me to
> > > understand
> > > > the basic features of GMPLS. If I want to create an MPLS LSP between
> the
> > > two
> > > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > > (Assuming
> > > > that we have an out-of-band IP control network running LMP)
> > > >
> > > > My guess is that the PATH message will leave the ingress router with a
> > > PATH
> > > > message with a calculated ERO. It assumes that the network is in
> respect
> > > > with the peer model...everyone have the same routing table and know
> the
> > > > actual network topology. So, my PATH message will follow the CSPF
> (ERO)
> > > and
> > > > go to the egress router. Am I right?
> > > >
> > > > Best regards,
> > > >
> > > > Jimmy Gendron
> > > >

Delivery-date: Mon, 11 Jun 2001 09:15:14 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Diego Caviglia <[email-masked]>
Cc: Susumu Yoneda <[email-masked]>, [email-masked],  Jimmy Gendron <[email-masked]>, [email-masked]
Subject: RE: GMPLS Sonet extensions
Date: Mon, 11 Jun 2001 09:13:35 -0700

Hi Maarten, Diego, et. al.
what's interesting here is the question of what do we mean by "its own
instance of a control plane"?  Obviously if we are setting up a LOVC (in
SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to
those switches that are LOVC capable.  Other switches need not be involved.
If it turns out that the LOVC capable switches are not interconnected by a
HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the
appropriate HOVC interconnecting the LOVC needs to be setup first.  In GMPLS
speak we first setup the HOVC LSP tunnel(s) between the LOVC capable
switches before we set up the LOVC LSPs.

Since we have to (a) be able to set up connects at the appropriate layers,
(b) understand the topology at each layer, to me this sounds like an
instance of a control plane at each layer.
However, it doesn't necessarily tell me whether I'd want to (or not)
integrate multiple layer information into a protocol and run fewer protocol
instances than network layers.  Well actually as Maarten wrote in a recent
ITU document that we would be primarily interested in those layers involved
in dynamic switching/multiplexing.  Note that we've started to bring in
non-dynamic layer information via other mechanisms, e.g., the SRLG concept
(the WDM--SONET example I always give).

With the signaling protocol things are really separated by who is involved
in the signaling transaction.  In the routing case things are less clear,
i.e., who wants/needs to know information about other layers and what burden
does this present to the NEs and scalability.  Which layers can benefit by
integration...  I'll be updating the Optical inter-domain route requirements
draft soon (with others) and will be exploring some of these items in more
depth.

(Terminology: LOVC := Lower order virtual container, SDH term that includes
signals between 1.5 and 6Mbps in the SDH hierarchy.  HOVC := Higher order
virtual container, SDH terms that includes signals between 50Mbps-40Gbps in
the SDH hierarchy).

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, June 11, 2001 7:46 AM
To: Diego Caviglia
Cc: Susumu Yoneda; [email-masked]; Jimmy Gendron; [email-masked]
Subject: Re: GMPLS Sonet extensions

Diego,

Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
and OCh) will have its own (instance of) control plane. 

Each switched layer network runs a copy of the generic routing protocol;
it does so within the boundaries of the switched layer network.

Within each switched layer network you will find UNI, E-NNI and I-NNI
interfaces due to partitioning of a switched layer network. Topology
information is exchanged only via I-NNI interfaces. E-NNI interfaces on
the other hand only provide reachability information.

For the case an MPLS router is from a different organisation than the
transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
interface. For the case the MPLS router is at the edge of a MPLS-VPN,
the interface will be an MPLS-I-NNI.
For the server layers within the MPLS router (e.g. HOVC and STM-N
section layers) the interface relation is to be determined independent
of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
(on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
at MPLS level full topology information is exchanged (MPLS-I-NNI), where
as at the HOVC layer entwork only reachability information is available
in the MPLS router (HOVC-E-NNI).

The MPLS router should not be concerned at all about the routing of the
HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
between two adjacent MPLS routers. For the case an additional 2.5G MPLS
link between is needed between MPLS router A and MPLS router B, router A
needs to have knowledge of router B's address/name only to request a
VC-4-16c/STS-48c connection through the transport network. The switched
HOVC (transport) network will take care of the connection setup.

And even if two diverse routed connections are required (e.g. to support
VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
needs to request only the creation of 2 VC-4-16c connections with the
constraint of being diversely routed. The switched HOVC network will be
able to provide these two connections diversely routed between A and B
routers.

At the moment, I recognise two connection types in a layer network: 
	- native connections and 
	- client connections. 
Example: within a HOVC layer network a STS1 or VC-4 connection is a
native connection, and a DS3 connection or a LOVC link is a client
connection. A client connection is supported by the HOVC layer network
after adapting it to the layer network signal type (i.e. STS1 (to
support DS3), STS1 or VC4 (to support LOVC link)). The client connection
can have a
	- 1:1,
	- 1:n, 
	- n:1 
relationship with the underlying layer network signal.
Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
relationship.

With client connections, an I-NNI is almost per definition not possible
(you go outside the layer network). Nevertheless, some people consider
the special 1:1 case as an area where an I-NNI could be deployed; of
course not for the case of DS3 -> STS1, but for the case of
STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
-> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
HOVC layer network and a client signal to the OCh and ODU1 layer
networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
wavelenght it is easy to think to be within one and the same layer
network. Personally, I believe that such very special case looks much
brighter than it is in the long term. I.e. don't declare very special
cases to be the common ones; keep those as very special cases, best even
keep those as regular cases obeying to the generic rules.

Client connections as such have UNI or E-NNI interface relationships
over which reachability information is offered at best. This is the case
for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
layer entwork) as well as "vertical client connections" (e.g. a LOVC
link over a HOVC/STS layer network).

Regards,

Maarten

Diego Caviglia wrote:
> 
> Maarten,
>                     I agree in principle with you but this means it would
be
> necessary to have a routing protocol for each layer doesn't it?
> 
> One  of  the  initial  reasons  for  (G)MPLS is to unify the control
plane, your
> layered view of the network implies again the separation of the control
planes.
> 
> The  Transport  Network is very different from a flat IP network and
layering in
> TN is implicit.
> 
> If  I  understood your model correctly the MPLS Router only views, Access
Groups
> and  links  to  other  MPLS Routers. If there are free resources between
the two
> routers  the TE process calculates, accordingly to some rules, the best
path. 

Agree.

> If
> there are no resources a call to the Network Engineering agent is
performed, the
> NE  makes a call to the TE of the SONET layer in order to provide a trail
to the
> MPLS layer (this procedure is repeated until available resources are
created for
> the MPLS router connection). This trail modifies the topology at the MPLS
layer.

Agree. One note however, operators have indicated that they would like
to deploy policies in the NE agent which may include some thresholds,
before it decides to change the topology of the layer network. E.g.
topology is not extended unless X calls failed. On the other hand, the
NE agent may have scheduled topology changes; e.g. at the begin of busy
hour extra links are added or bandwidth of existing link is extended,
and at the end of busy hour the reverse is happening.

> 
> If  my  understanding is correct and we want to implement an automated TN
a sort
> of UNI has to be put between the NE at layer N and the TE at layer N-1.

UNI or E-NNI.

> 
> Maybe this will create some problems, on the other hand, as Maarten
pointed out,
> flat  networks  won't  work due the huge amount of routing information
that they
> have to carry.
> 
> Regards
> 
> Diego
> 
> Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> 
> 
> 
> 
> 
> 
> 
>  To:      Susumu Yoneda <[email-masked]>
> 
>  cc:      [email-masked], Jimmy Gendron
>           <[email-masked]>, [email-masked](bcc:
>           Diego Caviglia/MAIN/MC1)
> 
> 
> 
>  Subject: Re: GMPLS Sonet extensions
> 
> 
> Sharma,
> 
> "flat" set up is the route to disaster... simply consider a switched
> transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> would get information of all these levels... an absolute disaster in a
> world wide switched transport network would be the result.
> 
> Therefore, there is this layering in which a server layer network
> provides bandwidth to its client layer entworks. the client layer
> networks see this bandwidth as kind of "fixed" bandwidth over which they
> can route their signals.
> 
> A separate entity (I called it "network engineering") is looking over
> the shoulder of the call setup process to see if more bandwidth is
> needed and when it would be needed or not longer required. But today,
> this separate entity is not part of the control plane; it is in the
> management plane.
> 
> Regards,
> 
> Maarten
> 
> Susumu Yoneda wrote:
> >
> > Sharma,
> >
> > Thank you for letting me know your presentation material which looks
very
> > interesting. It seems to me that a layered setup would make a sense.
> > However, users may want to have a "flat" setup. Therefore, lower setups
> > would not be seen by users?
> >
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: Saturday, June 09, 2001 11:06 AM
> > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > Subject: RE: GMPLS Sonet extensions
> >
> > Jimmy, Susumu,
> >
> > Your idea (assuming a peer model) is basically correct. Since all nodes
> > have the same view of the network, you could compute an ERO at the
> > ingress router and have the PATH message follow the hop-by-hop route
> > to the egress router.
> > (Note, however, that the PATH message will travel
> > on the out-of-band IP control network; therefore, it would be
non-associated
> > signaling.)
> >
> > Also, Susumu, if the peer model is in effect, then all messges will,
> > in fact, have to be shared by all nodes, since that is precisely what
> > the "peer model" implies.
> >
> > But you do have to be careful about what "LSP" you are requesting, since
the
> > characteristics of the requested LSP are not interpreted in the same way
by
> > the
> > various pieces of equipment in your figure. (A SONET ADM requires a
> > different
> > way of defining a circuit than an IP router or an OXC.)
> > Therefore, one possibility would be to do a "layered setup", where an
LSP
> > at the lower layer is setup before the PATH message at the higher layer
> > is tunnelled over it or allowed to propagate further.
> >
> > For example, when the PATH message for the packet
> > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > a corresponding SONET circuit between themselves, and then either tunnel
> > the PATH message for the packet LSP over this circuit, or (assuming your
> > out-of-band network), at that time, allow the PATH message for the
packet
> > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > channel, likewise, would be a recursive process, with the OXC first
setting
> > up an optical lightpath between themselves, and tunneling the request to
> > set up the SONET channel over it, once that lightpath is setup.)
> >
> > A more detailed discussion of this subject, with corresponding
animations
> > and figures, that you may also find helpful is available in a talk I
gave at
> > MPLSCon'01, and can be found at:
> > http://www.mplscon.com/missing_presentations.htm
> > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> >
> > -Vishal
> >
> > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > [SMTP:[email-masked]]
> > wrote:
> > > Hi,
> > >
> > > I also assume that there would be an out-of-band signalling network
based
> > on
> > > a suite of GMPLS protocols including LMP. I think there will be issues
to
> > > address whether all messages will be shared by all nodes, i.e router,
> > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > -------------------------------
> > > Susumu Yoneda   tel +81 3 5540 8493
> > > Japan Telecom    fax +81 3 5540 8485
> > > Information & Communication Labs.
> > > e-mail  [email-masked]
> > > -------------------------------
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
Behalf
> > Of
> > > Jimmy Gendron
> > > Sent: Friday, June 08, 2001 10:01 PM
> > > To: [email-masked]'
> > > Subject: GMPLS Sonet extensions
> > >
> > >
> > > Hi,
> > >
> > > I used to read almost all stuff regarding GMPLS since a week. I
understand
> > > most of the architecture, but I still have a question since the
beginning;
> > > as an unified control plane, how do the routing/signaling protocols
> > exchange
> > > informations on a configuration like this:
> > >
> > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > (Ingress)
> > >
> > > Its a basic point to point configuration, but it will allow me to
> > understand
> > > the basic features of GMPLS. If I want to create an MPLS LSP between
the
> > two
> > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > (Assuming
> > > that we have an out-of-band IP control network running LMP)
> > >
> > > My guess is that the PATH message will leave the ingress router with a
> > PATH
> > > message with a calculated ERO. It assumes that the network is in
respect
> > > with the peer model...everyone have the same routing table and know
the
> > > actual network topology. So, my PATH message will follow the CSPF
(ERO)
> > and
> > > go to the egress router. Am I right?
> > >
> > > Best regards,
> > >
> > > Jimmy Gendron
> > >

Delivery-date: Mon, 11 Jun 2001 07:47:07 -0700
Cc: Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Mon, 11 Jun 2001 16:46:28 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Diego Caviglia <[email-masked]>
Original-CC: Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------3D38327E2429B1C9D7893F5C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Diego,

Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
and OCh) will have its own (instance of) control plane. 

Each switched layer network runs a copy of the generic routing protocol;
it does so within the boundaries of the switched layer network.

Within each switched layer network you will find UNI, E-NNI and I-NNI
interfaces due to partitioning of a switched layer network. Topology
information is exchanged only via I-NNI interfaces. E-NNI interfaces on
the other hand only provide reachability information.

For the case an MPLS router is from a different organisation than the
transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
interface. For the case the MPLS router is at the edge of a MPLS-VPN,
the interface will be an MPLS-I-NNI.
For the server layers within the MPLS router (e.g. HOVC and STM-N
section layers) the interface relation is to be determined independent
of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
(on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
at MPLS level full topology information is exchanged (MPLS-I-NNI), where
as at the HOVC layer entwork only reachability information is available
in the MPLS router (HOVC-E-NNI).

The MPLS router should not be concerned at all about the routing of the
HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
between two adjacent MPLS routers. For the case an additional 2.5G MPLS
link between is needed between MPLS router A and MPLS router B, router A
needs to have knowledge of router B's address/name only to request a
VC-4-16c/STS-48c connection through the transport network. The switched
HOVC (transport) network will take care of the connection setup.

And even if two diverse routed connections are required (e.g. to support
VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
needs to request only the creation of 2 VC-4-16c connections with the
constraint of being diversely routed. The switched HOVC network will be
able to provide these two connections diversely routed between A and B
routers.

At the moment, I recognise two connection types in a layer network: 
	- native connections and 
	- client connections. 
Example: within a HOVC layer network a STS1 or VC-4 connection is a
native connection, and a DS3 connection or a LOVC link is a client
connection. A client connection is supported by the HOVC layer network
after adapting it to the layer network signal type (i.e. STS1 (to
support DS3), STS1 or VC4 (to support LOVC link)). The client connection
can have a
	- 1:1,
	- 1:n, 
	- n:1 
relationship with the underlying layer network signal.
Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
relationship.

With client connections, an I-NNI is almost per definition not possible
(you go outside the layer network). Nevertheless, some people consider
the special 1:1 case as an area where an I-NNI could be deployed; of
course not for the case of DS3 -> STS1, but for the case of
STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
-> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
HOVC layer network and a client signal to the OCh and ODU1 layer
networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
wavelenght it is easy to think to be within one and the same layer
network. Personally, I believe that such very special case looks much
brighter than it is in the long term. I.e. don't declare very special
cases to be the common ones; keep those as very special cases, best even
keep those as regular cases obeying to the generic rules.

Client connections as such have UNI or E-NNI interface relationships
over which reachability information is offered at best. This is the case
for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
layer entwork) as well as "vertical client connections" (e.g. a LOVC
link over a HOVC/STS layer network).

Regards,

Maarten

Diego Caviglia wrote:
> 
> Maarten,
>                     I agree in principle with you but this means it would be
> necessary to have a routing protocol for each layer doesn't it?
> 
> One  of  the  initial  reasons  for  (G)MPLS is to unify the control plane, your
> layered view of the network implies again the separation of the control planes.
> 
> The  Transport  Network is very different from a flat IP network and layering in
> TN is implicit.
> 
> If  I  understood your model correctly the MPLS Router only views, Access Groups
> and  links  to  other  MPLS Routers. If there are free resources between the two
> routers  the TE process calculates, accordingly to some rules, the best path. 

Agree.

> If
> there are no resources a call to the Network Engineering agent is performed, the
> NE  makes a call to the TE of the SONET layer in order to provide a trail to the
> MPLS layer (this procedure is repeated until available resources are created for
> the MPLS router connection). This trail modifies the topology at the MPLS layer.

Agree. One note however, operators have indicated that they would like
to deploy policies in the NE agent which may include some thresholds,
before it decides to change the topology of the layer network. E.g.
topology is not extended unless X calls failed. On the other hand, the
NE agent may have scheduled topology changes; e.g. at the begin of busy
hour extra links are added or bandwidth of existing link is extended,
and at the end of busy hour the reverse is happening.

> 
> If  my  understanding is correct and we want to implement an automated TN a sort
> of UNI has to be put between the NE at layer N and the TE at layer N-1.

UNI or E-NNI.

> 
> Maybe this will create some problems, on the other hand, as Maarten pointed out,
> flat  networks  won't  work due the huge amount of routing information that they
> have to carry.
> 
> Regards
> 
> Diego
> 
> Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52
> 
> 
> 
> 
> 
> 
> 
>  To:      Susumu Yoneda <[email-masked]>
> 
>  cc:      [email-masked], Jimmy Gendron
>           <[email-masked]>, [email-masked](bcc:
>           Diego Caviglia/MAIN/MC1)
> 
> 
> 
>  Subject: Re: GMPLS Sonet extensions
> 
> 
> Sharma,
> 
> "flat" set up is the route to disaster... simply consider a switched
> transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
> VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
> MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
> would get information of all these levels... an absolute disaster in a
> world wide switched transport network would be the result.
> 
> Therefore, there is this layering in which a server layer network
> provides bandwidth to its client layer entworks. the client layer
> networks see this bandwidth as kind of "fixed" bandwidth over which they
> can route their signals.
> 
> A separate entity (I called it "network engineering") is looking over
> the shoulder of the call setup process to see if more bandwidth is
> needed and when it would be needed or not longer required. But today,
> this separate entity is not part of the control plane; it is in the
> management plane.
> 
> Regards,
> 
> Maarten
> 
> Susumu Yoneda wrote:
> >
> > Sharma,
> >
> > Thank you for letting me know your presentation material which looks very
> > interesting. It seems to me that a layered setup would make a sense.
> > However, users may want to have a "flat" setup. Therefore, lower setups
> > would not be seen by users?
> >
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: Saturday, June 09, 2001 11:06 AM
> > To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> > Subject: RE: GMPLS Sonet extensions
> >
> > Jimmy, Susumu,
> >
> > Your idea (assuming a peer model) is basically correct. Since all nodes
> > have the same view of the network, you could compute an ERO at the
> > ingress router and have the PATH message follow the hop-by-hop route
> > to the egress router.
> > (Note, however, that the PATH message will travel
> > on the out-of-band IP control network; therefore, it would be non-associated
> > signaling.)
> >
> > Also, Susumu, if the peer model is in effect, then all messges will,
> > in fact, have to be shared by all nodes, since that is precisely what
> > the "peer model" implies.
> >
> > But you do have to be careful about what "LSP" you are requesting, since the
> > characteristics of the requested LSP are not interpreted in the same way by
> > the
> > various pieces of equipment in your figure. (A SONET ADM requires a
> > different
> > way of defining a circuit than an IP router or an OXC.)
> > Therefore, one possibility would be to do a "layered setup", where an LSP
> > at the lower layer is setup before the PATH message at the higher layer
> > is tunnelled over it or allowed to propagate further.
> >
> > For example, when the PATH message for the packet
> > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> > a corresponding SONET circuit between themselves, and then either tunnel
> > the PATH message for the packet LSP over this circuit, or (assuming your
> > out-of-band network), at that time, allow the PATH message for the packet
> > LSP to propagate to the next MPLS router. (The setting up of the SONET
> > channel, likewise, would be a recursive process, with the OXC first setting
> > up an optical lightpath between themselves, and tunneling the request to
> > set up the SONET channel over it, once that lightpath is setup.)
> >
> > A more detailed discussion of this subject, with corresponding animations
> > and figures, that you may also find helpful is available in a talk I gave at
> > MPLSCon'01, and can be found at:
> > http://www.mplscon.com/missing_presentations.htm
> > (Dynamic path establishment in MPLS-controlled multi-service networks.)
> >
> > -Vishal
> >
> > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> > [SMTP:[email-masked]]
> > wrote:
> > > Hi,
> > >
> > > I also assume that there would be an out-of-band signalling network based
> > on
> > > a suite of GMPLS protocols including LMP. I think there will be issues to
> > > address whether all messages will be shared by all nodes, i.e router,
> > > SDH/SONET, and OXC or not. This will be a part of security issues.
> > > -------------------------------
> > > Susumu Yoneda   tel +81 3 5540 8493
> > > Japan Telecom    fax +81 3 5540 8485
> > > Information & Communication Labs.
> > > e-mail  [email-masked]
> > > -------------------------------
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of
> > > Jimmy Gendron
> > > Sent: Friday, June 08, 2001 10:01 PM
> > > To: [email-masked]'
> > > Subject: GMPLS Sonet extensions
> > >
> > >
> > > Hi,
> > >
> > > I used to read almost all stuff regarding GMPLS since a week. I understand
> > > most of the architecture, but I still have a question since the beginning;
> > > as an unified control plane, how do the routing/signaling protocols
> > exchange
> > > informations on a configuration like this:
> > >
> > > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > > -------> OXC --------> SONET ADM --------> MPLS Router
> > > (Ingress)
> > >
> > > Its a basic point to point configuration, but it will allow me to
> > understand
> > > the basic features of GMPLS. If I want to create an MPLS LSP between the
> > two
> > > MPLS routers, how do the RSVP PATH message is sent to the network?
> > (Assuming
> > > that we have an out-of-band IP control network running LMP)
> > >
> > > My guess is that the PATH message will leave the ingress router with a
> > PATH
> > > message with a calculated ERO. It assumes that the network is in respect
> > > with the peer model...everyone have the same routing table and know the
> > > actual network topology. So, my PATH message will follow the CSPF (ERO)
> > and
> > > go to the egress router. Am I right?
> > >
> > > Best regards,
> > >
> > > Jimmy Gendron
> > >
--------------3D38327E2429B1C9D7893F5C
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3D38327E2429B1C9D7893F5C--

Delivery-date: Mon, 11 Jun 2001 06:27:11 -0700
Reply-To: <[email-masked]>
From: "Srikanth" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Doubt in mpls-generalized-cr-ldp-03.txt
Date: Mon, 11 Jun 2001 18:55:24 +0530

Hi all,

I have a doubt in Explicit Label Control

In section 5.1 (Procedures),

"........If the U-bit of the ER-Hop being examined is clear (0), then value
of the label is copied into a new Label_Set TLV.  This Label_Set TLV MUST be
included on the corresponding outgoing MAPPING message..........."

Topology :

              LSR X   --------------   LSR Y

Consider the scenario, LSR X is processing the Label ER-Hop ( LSR X is a
part of the ER-Hop preceding the Label ER-Hop in the Hop List ). This label
ER-Hop specifies the Label to be assigned by LSR Y ( not in the case of
splicing ). To achieve this, LSR X has to construct the Label Set ( with
just this label ) and send it to LSR Y.

So the MAPPING in section 5.1 should be REQUEST.

Please correct if i am wrong.

Thanks in advance,
Srikanth Narayanan.

Delivery-date: Mon, 11 Jun 2001 05:59:08 -0700
From: "Diego Caviglia" <[email-masked]>
To: Maarten Vissers <[email-masked]>
cc: Susumu Yoneda <[email-masked]>, [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Mon, 11 Jun 2001 14:29:26 +0200
Subject: Re: GMPLS Sonet extensions

--0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Maarten,
                    I agree in principle with you but this means it would be
necessary to have a routing protocol for each layer doesn't it?

One  of  the  initial  reasons  for  (G)MPLS is to unify the control plane, your
layered view of the network implies again the separation of the control planes.

The  Transport  Network is very different from a flat IP network and layering in
TN is implicit.

If  I  understood your model correctly the MPLS Router only views, Access Groups
and  links  to  other  MPLS Routers. If there are free resources between the two
routers  the TE process calculates, accordingly to some rules, the best path. If
there are no resources a call to the Network Engineering agent is performed, the
NE  makes a call to the TE of the SONET layer in order to provide a trail to the
MPLS layer (this procedure is repeated until available resources are created for
the MPLS router connection). This trail modifies the topology at the MPLS layer.

If  my  understanding is correct and we want to implement an automated TN a sort
of UNI has to be put between the NE at layer N and the TE at layer N-1.

Maybe this will create some problems, on the other hand, as Maarten pointed out,
flat  networks  won't  work due the huge amount of routing information that they
have to carry.

Regards

Diego

Maarten Vissers <[email-masked]> on 11/06/2001 13.16.52

                                                                                

                                                              

 To:      Susumu Yoneda <[email-masked]>            
                                                              
 cc:      [email-masked], Jimmy Gendron                    
          <[email-masked]>, [email-masked](bcc:   
          Diego Caviglia/MAIN/MC1)                            

                                                              
 Subject: Re: GMPLS Sonet extensions                          

Sharma,

"flat" set up is the route to disaster... simply consider a switched
transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
would get information of all these levels... an absolute disaster in a
world wide switched transport network would be the result.

Therefore, there is this layering in which a server layer network
provides bandwidth to its client layer entworks. the client layer
networks see this bandwidth as kind of "fixed" bandwidth over which they
can route their signals.

A separate entity (I called it "network engineering") is looking over
the shoulder of the call setup process to see if more bandwidth is
needed and when it would be needed or not longer required. But today,
this separate entity is not part of the control plane; it is in the
management plane.

Regards,

Maarten

Susumu Yoneda wrote:
>
> Sharma,
>
> Thank you for letting me know your presentation material which looks very
> interesting. It seems to me that a layered setup would make a sense.
> However, users may want to have a "flat" setup. Therefore, lower setups
> would not be seen by users?
>
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Saturday, June 09, 2001 11:06 AM
> To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> Subject: RE: GMPLS Sonet extensions
>
> Jimmy, Susumu,
>
> Your idea (assuming a peer model) is basically correct. Since all nodes
> have the same view of the network, you could compute an ERO at the
> ingress router and have the PATH message follow the hop-by-hop route
> to the egress router.
> (Note, however, that the PATH message will travel
> on the out-of-band IP control network; therefore, it would be non-associated
> signaling.)
>
> Also, Susumu, if the peer model is in effect, then all messges will,
> in fact, have to be shared by all nodes, since that is precisely what
> the "peer model" implies.
>
> But you do have to be careful about what "LSP" you are requesting, since the
> characteristics of the requested LSP are not interpreted in the same way by
> the
> various pieces of equipment in your figure. (A SONET ADM requires a
> different
> way of defining a circuit than an IP router or an OXC.)
> Therefore, one possibility would be to do a "layered setup", where an LSP
> at the lower layer is setup before the PATH message at the higher layer
> is tunnelled over it or allowed to propagate further.
>
> For example, when the PATH message for the packet
> LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> a corresponding SONET circuit between themselves, and then either tunnel
> the PATH message for the packet LSP over this circuit, or (assuming your
> out-of-band network), at that time, allow the PATH message for the packet
> LSP to propagate to the next MPLS router. (The setting up of the SONET
> channel, likewise, would be a recursive process, with the OXC first setting
> up an optical lightpath between themselves, and tunneling the request to
> set up the SONET channel over it, once that lightpath is setup.)
>
> A more detailed discussion of this subject, with corresponding animations
> and figures, that you may also find helpful is available in a talk I gave at
> MPLSCon'01, and can be found at:
> http://www.mplscon.com/missing_presentations.htm
> (Dynamic path establishment in MPLS-controlled multi-service networks.)
>
> -Vishal
>
> On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> [SMTP:[email-masked]]
> wrote:
> > Hi,
> >
> > I also assume that there would be an out-of-band signalling network based
> on
> > a suite of GMPLS protocols including LMP. I think there will be issues to
> > address whether all messages will be shared by all nodes, i.e router,
> > SDH/SONET, and OXC or not. This will be a part of security issues.
> > -------------------------------
> > Susumu Yoneda   tel +81 3 5540 8493
> > Japan Telecom    fax +81 3 5540 8485
> > Information & Communication Labs.
> > e-mail  [email-masked]
> > -------------------------------
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> Of
> > Jimmy Gendron
> > Sent: Friday, June 08, 2001 10:01 PM
> > To: [email-masked]'
> > Subject: GMPLS Sonet extensions
> >
> >
> > Hi,
> >
> > I used to read almost all stuff regarding GMPLS since a week. I understand
> > most of the architecture, but I still have a question since the beginning;
> > as an unified control plane, how do the routing/signaling protocols
> exchange
> > informations on a configuration like this:
> >
> > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > -------> OXC --------> SONET ADM --------> MPLS Router
> > (Ingress)
> >
> > Its a basic point to point configuration, but it will allow me to
> understand
> > the basic features of GMPLS. If I want to create an MPLS LSP between the
> two
> > MPLS routers, how do the RSVP PATH message is sent to the network?
> (Assuming
> > that we have an out-of-band IP control network running LMP)
> >
> > My guess is that the PATH message will leave the ingress router with a
> PATH
> > message with a calculated ERO. It assumes that the network is in respect
> > with the peer model...everyone have the same routing table and know the
> > actual network topology. So, my PATH message will follow the CSPF (ERO)
> and
> > go to the egress router. Am I right?
> >
> > Best regards,
> >
> > Jimmy Gendron
> >

--0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM
Content-type: application/octet-stream; 
	name="mvissers.vcf"
Content-Disposition: attachment; filename="mvissers.vcf"
Content-transfer-encoding: base64

YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1
DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7
d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO
ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K
ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i
ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh
dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh
cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K

--0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM--

Delivery-date: Mon, 11 Jun 2001 04:17:21 -0700
Cc: [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Date: Mon, 11 Jun 2001 13:16:52 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Susumu Yoneda <[email-masked]>
Original-CC: [email-masked], Jimmy Gendron <[email-masked]>, [email-masked]
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------2ECF57E1524E9CA8E27A523F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sharma,

"flat" set up is the route to disaster... simply consider a switched
transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
would get information of all these levels... an absolute disaster in a
world wide switched transport network would be the result.

Therefore, there is this layering in which a server layer network
provides bandwidth to its client layer entworks. the client layer
networks see this bandwidth as kind of "fixed" bandwidth over which they
can route their signals.

A separate entity (I called it "network engineering") is looking over
the shoulder of the call setup process to see if more bandwidth is
needed and when it would be needed or not longer required. But today,
this separate entity is not part of the control plane; it is in the
management plane.

Regards,

Maarten

Susumu Yoneda wrote:
> 
> Sharma,
> 
> Thank you for letting me know your presentation material which looks very
> interesting. It seems to me that a layered setup would make a sense.
> However, users may want to have a "flat" setup. Therefore, lower setups
> would not be seen by users?
> 
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Saturday, June 09, 2001 11:06 AM
> To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> Subject: RE: GMPLS Sonet extensions
> 
> Jimmy, Susumu,
> 
> Your idea (assuming a peer model) is basically correct. Since all nodes
> have the same view of the network, you could compute an ERO at the
> ingress router and have the PATH message follow the hop-by-hop route
> to the egress router.
> (Note, however, that the PATH message will travel
> on the out-of-band IP control network; therefore, it would be non-associated
> signaling.)
> 
> Also, Susumu, if the peer model is in effect, then all messges will,
> in fact, have to be shared by all nodes, since that is precisely what
> the "peer model" implies.
> 
> But you do have to be careful about what "LSP" you are requesting, since the
> characteristics of the requested LSP are not interpreted in the same way by
> the
> various pieces of equipment in your figure. (A SONET ADM requires a
> different
> way of defining a circuit than an IP router or an OXC.)
> Therefore, one possibility would be to do a "layered setup", where an LSP
> at the lower layer is setup before the PATH message at the higher layer
> is tunnelled over it or allowed to propagate further.
> 
> For example, when the PATH message for the packet
> LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> a corresponding SONET circuit between themselves, and then either tunnel
> the PATH message for the packet LSP over this circuit, or (assuming your
> out-of-band network), at that time, allow the PATH message for the packet
> LSP to propagate to the next MPLS router. (The setting up of the SONET
> channel, likewise, would be a recursive process, with the OXC first setting
> up an optical lightpath between themselves, and tunneling the request to
> set up the SONET channel over it, once that lightpath is setup.)
> 
> A more detailed discussion of this subject, with corresponding animations
> and figures, that you may also find helpful is available in a talk I gave at
> MPLSCon'01, and can be found at:
> http://www.mplscon.com/missing_presentations.htm
> (Dynamic path establishment in MPLS-controlled multi-service networks.)
> 
> -Vishal
> 
> On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> [SMTP:[email-masked]]
> wrote:
> > Hi,
> >
> > I also assume that there would be an out-of-band signalling network based
> on
> > a suite of GMPLS protocols including LMP. I think there will be issues to
> > address whether all messages will be shared by all nodes, i.e router,
> > SDH/SONET, and OXC or not. This will be a part of security issues.
> > -------------------------------
> > Susumu Yoneda   tel +81 3 5540 8493
> > Japan Telecom    fax +81 3 5540 8485
> > Information & Communication Labs.
> > e-mail  [email-masked]
> > -------------------------------
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> Of
> > Jimmy Gendron
> > Sent: Friday, June 08, 2001 10:01 PM
> > To: [email-masked]'
> > Subject: GMPLS Sonet extensions
> >
> >
> > Hi,
> >
> > I used to read almost all stuff regarding GMPLS since a week. I understand
> > most of the architecture, but I still have a question since the beginning;
> > as an unified control plane, how do the routing/signaling protocols
> exchange
> > informations on a configuration like this:
> >
> > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > -------> OXC --------> SONET ADM --------> MPLS Router
> > (Ingress)
> >
> > Its a basic point to point configuration, but it will allow me to
> understand
> > the basic features of GMPLS. If I want to create an MPLS LSP between the
> two
> > MPLS routers, how do the RSVP PATH message is sent to the network?
> (Assuming
> > that we have an out-of-band IP control network running LMP)
> >
> > My guess is that the PATH message will leave the ingress router with a
> PATH
> > message with a calculated ERO. It assumes that the network is in respect
> > with the peer model...everyone have the same routing table and know the
> > actual network topology. So, my PATH message will follow the CSPF (ERO)
> and
> > go to the egress router. Am I right?
> >
> > Best regards,
> >
> > Jimmy Gendron
> >
--------------2ECF57E1524E9CA8E27A523F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------2ECF57E1524E9CA8E27A523F--

Delivery-date: Mon, 11 Jun 2001 04:11:32 -0700
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Mon, 11 Jun 2001 13:09:46 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Jimmy Gendron <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: GMPLS Sonet extensions

This is a multi-part message in MIME format.
--------------D446BB46687226DBF93CB3F6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jimmy,

Connection set-up is performed on a per layer network basis. For its
purpose of setting up a connection, the layer network uses available
bandwidth to that layer network. For the case a protected connection is
to be set up, it is important to know at what level the protection is
required. I.e. this layer network or a server layer network. If it is
the former, the layer network has to create two unprotected connections
starting/ending at bridge/selector functions; e.g. a 1+1 SNC protected
VC-4 connection would be dealt with this way within the HOVC layer
entwork. 
However, if it is the latter (server layer network contains protection),
the layer network which sets up the connection doesn't care at all about
protection; e.g. case of a VC-4 connection running over a 1+1 MS
protected line or over a MS SPring protected ring - the HOVC layer
entwork doesn't care about the protection.

Regards,

Maarten

Jimmy Gendron wrote:
> 
> Vishal,
> 
> thank you for the details. How the protection type is managed? Is it the
> SONET LSP that set up an optical LSP with, for example, 1+1 protection?
> Which entity is responsible to deal with protection at first when we try to
> set up an MPLS LSP with 1+1 prot through SONET?
> 
> Thank you,
> 
> Jimmy
> 
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 10:06 PM
> To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
> Subject: RE: GMPLS Sonet extensions
> 
> Jimmy, Susumu,
> 
> Your idea (assuming a peer model) is basically correct. Since all nodes
> have the same view of the network, you could compute an ERO at the
> ingress router and have the PATH message follow the hop-by-hop route
> to the egress router.
> (Note, however, that the PATH message will travel
> on the out-of-band IP control network; therefore, it would be non-associated
> 
> signaling.)
> 
> Also, Susumu, if the peer model is in effect, then all messges will,
> in fact, have to be shared by all nodes, since that is precisely what
> the "peer model" implies.
> 
> But you do have to be careful about what "LSP" you are requesting, since the
> characteristics of the requested LSP are not interpreted in the same way by
> the
> various pieces of equipment in your figure. (A SONET ADM requires a
> different
> way of defining a circuit than an IP router or an OXC.)
> Therefore, one possibility would be to do a "layered setup", where an LSP
> at the lower layer is setup before the PATH message at the higher layer
> is tunnelled over it or allowed to propagate further.
> 
> For example, when the PATH message for the packet
> LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> a corresponding SONET circuit between themselves, and then either tunnel
> the PATH message for the packet LSP over this circuit, or (assuming your
> out-of-band network), at that time, allow the PATH message for the packet
> LSP to propagate to the next MPLS router. (The setting up of the SONET
> channel, likewise, would be a recursive process, with the OXC first setting
> up an optical lightpath between themselves, and tunneling the request to
> set up the SONET channel over it, once that lightpath is setup.)
> 
> A more detailed discussion of this subject, with corresponding animations
> and figures, that you may also find helpful is available in a talk I gave at
> MPLSCon'01, and can be found at:
> http://www.mplscon.com/missing_presentations.htm
> (Dynamic path establishment in MPLS-controlled multi-service networks.)
> 
> -Vishal
> 
> On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> [SMTP:[email-masked]]
> wrote:
> > Hi,
> >
> > I also assume that there would be an out-of-band signalling network based
> on
> > a suite of GMPLS protocols including LMP. I think there will be issues to
> > address whether all messages will be shared by all nodes, i.e router,
> > SDH/SONET, and OXC or not. This will be a part of security issues.
> > -------------------------------
> > Susumu Yoneda   tel +81 3 5540 8493
> > Japan Telecom    fax +81 3 5540 8485
> > Information & Communication Labs.
> > e-mail  [email-masked]
> > -------------------------------
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> Of
> > Jimmy Gendron
> > Sent: Friday, June 08, 2001 10:01 PM
> > To: [email-masked]'
> > Subject: GMPLS Sonet extensions
> >
> >
> > Hi,
> >
> > I used to read almost all stuff regarding GMPLS since a week. I understand
> > most of the architecture, but I still have a question since the beginning;
> > as an unified control plane, how do the routing/signaling protocols
> exchange
> > informations on a configuration like this:
> >
> > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > -------> OXC --------> SONET ADM --------> MPLS Router
> > (Ingress)
> >
> > Its a basic point to point configuration, but it will allow me to
> understand
> > the basic features of GMPLS. If I want to create an MPLS LSP between the
> two
> > MPLS routers, how do the RSVP PATH message is sent to the network?
> (Assuming
> > that we have an out-of-band IP control network running LMP)
> >
> > My guess is that the PATH message will leave the ingress router with a
> PATH
> > message with a calculated ERO. It assumes that the network is in respect
> > with the peer model...everyone have the same routing table and know the
> > actual network topology. So, my PATH message will follow the CSPF (ERO)
> and
> > go to the egress router. Am I right?
> >
> > Best regards,
> >
> > Jimmy Gendron
> >
--------------D446BB46687226DBF93CB3F6
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D446BB46687226DBF93CB3F6--

Delivery-date: Sat, 09 Jun 2001 17:29:57 -0700
From: "Susumu Yoneda" <[email-masked]>
To: <[email-masked]>, "Jimmy Gendron" <[email-masked]>, <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Sun, 10 Jun 2001 09:34:01 +0900

Sharma,

Thank you for letting me know your presentation material which looks very
interesting. It seems to me that a layered setup would make a sense.
However, users may want to have a "flat" setup. Therefore, lower setups
would not be seen by users?

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Saturday, June 09, 2001 11:06 AM
To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
Subject: RE: GMPLS Sonet extensions

Jimmy, Susumu,

Your idea (assuming a peer model) is basically correct. Since all nodes
have the same view of the network, you could compute an ERO at the
ingress router and have the PATH message follow the hop-by-hop route
to the egress router.
(Note, however, that the PATH message will travel
on the out-of-band IP control network; therefore, it would be non-associated
signaling.)

Also, Susumu, if the peer model is in effect, then all messges will,
in fact, have to be shared by all nodes, since that is precisely what
the "peer model" implies.

But you do have to be careful about what "LSP" you are requesting, since the
characteristics of the requested LSP are not interpreted in the same way by
the
various pieces of equipment in your figure. (A SONET ADM requires a
different
way of defining a circuit than an IP router or an OXC.)
Therefore, one possibility would be to do a "layered setup", where an LSP
at the lower layer is setup before the PATH message at the higher layer
is tunnelled over it or allowed to propagate further.

For example, when the PATH message for the packet
LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
a corresponding SONET circuit between themselves, and then either tunnel
the PATH message for the packet LSP over this circuit, or (assuming your
out-of-band network), at that time, allow the PATH message for the packet
LSP to propagate to the next MPLS router. (The setting up of the SONET
channel, likewise, would be a recursive process, with the OXC first setting
up an optical lightpath between themselves, and tunneling the request to
set up the SONET channel over it, once that lightpath is setup.)

A more detailed discussion of this subject, with corresponding animations
and figures, that you may also find helpful is available in a talk I gave at
MPLSCon'01, and can be found at:
http://www.mplscon.com/missing_presentations.htm
(Dynamic path establishment in MPLS-controlled multi-service networks.)

-Vishal

On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
[SMTP:[email-masked]]
wrote:
> Hi,
>
> I also assume that there would be an out-of-band signalling network based
on
> a suite of GMPLS protocols including LMP. I think there will be issues to
> address whether all messages will be shared by all nodes, i.e router,
> SDH/SONET, and OXC or not. This will be a part of security issues.
> -------------------------------
> Susumu Yoneda   tel +81 3 5540 8493
> Japan Telecom    fax +81 3 5540 8485
> Information & Communication Labs.
> e-mail  [email-masked]
> -------------------------------
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> Jimmy Gendron
> Sent: Friday, June 08, 2001 10:01 PM
> To: [email-masked]'
> Subject: GMPLS Sonet extensions
>
>
> Hi,
>
> I used to read almost all stuff regarding GMPLS since a week. I understand
> most of the architecture, but I still have a question since the beginning;
> as an unified control plane, how do the routing/signaling protocols
exchange
> informations on a configuration like this:
>
> MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> -------> OXC --------> SONET ADM --------> MPLS Router
> (Ingress)
>
> Its a basic point to point configuration, but it will allow me to
understand
> the basic features of GMPLS. If I want to create an MPLS LSP between the
two
> MPLS routers, how do the RSVP PATH message is sent to the network?
(Assuming
> that we have an out-of-band IP control network running LMP)
>
> My guess is that the PATH message will leave the ingress router with a
PATH
> message with a calculated ERO. It assumes that the network is in respect
> with the peer model...everyone have the same routing table and know the
> actual network topology. So, my PATH message will follow the CSPF (ERO)
and
> go to the egress router. Am I right?
>
> Best regards,
>
> Jimmy Gendron
>

Delivery-date: Sat, 09 Jun 2001 14:12:10 -0700
From: "Raju Venkatraman" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: GMPLS Questions, Doubts
Date: Sat, 09 Jun 2001 21:09:39 -0000

Hi,

I was just going through GMPLS drafts and I've some questions. Actually not 
able to understand few things. Any help would be greatly appreciated.

* Should the signalling module (control plane) be aware of all the data
channels/links under its control? In GMPLS, as it would be used in optical 
networks and a no. of interfaces would be present [not all carrying the 
signalling information] between GMPLS-enabled optical nodes, I don't feel 
it's required. The association of signalling link/channel(s) to data 
links/channels could be mainatained outside the sigannling module.

* Where one would like to maintain the diffserv related intelligence while 
setting up L-LSP and E-LSPs - would it would be assumed to be with routing 
module or signalling module?

I know, these things vary from implementation to implmentation, but just
wanted to hear your thoughts in this regard.

Thanks in advance.
Raju

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

Delivery-date: Sat, 09 Jun 2001 07:57:36 -0700
From: Jimmy Gendron <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Sat, 9 Jun 2001 10:49:47 -0400 

Vishal,

thank you for the details. How the protection type is managed? Is it the
SONET LSP that set up an optical LSP with, for example, 1+1 protection?
Which entity is responsible to deal with protection at first when we try to
set up an MPLS LSP with 1+1 prot through SONET?

Thank you,

Jimmy

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Friday, June 08, 2001 10:06 PM
To: 'Susumu Yoneda'; Jimmy Gendron; [email-masked]
Subject: RE: GMPLS Sonet extensions

Jimmy, Susumu,

Your idea (assuming a peer model) is basically correct. Since all nodes
have the same view of the network, you could compute an ERO at the
ingress router and have the PATH message follow the hop-by-hop route
to the egress router.
(Note, however, that the PATH message will travel
on the out-of-band IP control network; therefore, it would be non-associated

signaling.)

Also, Susumu, if the peer model is in effect, then all messges will,
in fact, have to be shared by all nodes, since that is precisely what
the "peer model" implies.

But you do have to be careful about what "LSP" you are requesting, since the
characteristics of the requested LSP are not interpreted in the same way by
the
various pieces of equipment in your figure. (A SONET ADM requires a
different
way of defining a circuit than an IP router or an OXC.)
Therefore, one possibility would be to do a "layered setup", where an LSP
at the lower layer is setup before the PATH message at the higher layer
is tunnelled over it or allowed to propagate further.

For example, when the PATH message for the packet
LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
a corresponding SONET circuit between themselves, and then either tunnel
the PATH message for the packet LSP over this circuit, or (assuming your
out-of-band network), at that time, allow the PATH message for the packet
LSP to propagate to the next MPLS router. (The setting up of the SONET
channel, likewise, would be a recursive process, with the OXC first setting
up an optical lightpath between themselves, and tunneling the request to
set up the SONET channel over it, once that lightpath is setup.)

A more detailed discussion of this subject, with corresponding animations
and figures, that you may also find helpful is available in a talk I gave at
MPLSCon'01, and can be found at:
http://www.mplscon.com/missing_presentations.htm
(Dynamic path establishment in MPLS-controlled multi-service networks.)

-Vishal

On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
[SMTP:[email-masked]] 
wrote:
> Hi,
>
> I also assume that there would be an out-of-band signalling network based
on
> a suite of GMPLS protocols including LMP. I think there will be issues to
> address whether all messages will be shared by all nodes, i.e router,
> SDH/SONET, and OXC or not. This will be a part of security issues.
> -------------------------------
> Susumu Yoneda   tel +81 3 5540 8493
> Japan Telecom    fax +81 3 5540 8485
> Information & Communication Labs.
> e-mail  [email-masked]
> -------------------------------
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> Jimmy Gendron
> Sent: Friday, June 08, 2001 10:01 PM
> To: [email-masked]'
> Subject: GMPLS Sonet extensions
>
>
> Hi,
>
> I used to read almost all stuff regarding GMPLS since a week. I understand
> most of the architecture, but I still have a question since the beginning;
> as an unified control plane, how do the routing/signaling protocols
exchange
> informations on a configuration like this:
>
> MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> -------> OXC --------> SONET ADM --------> MPLS Router
> (Ingress)
>
> Its a basic point to point configuration, but it will allow me to
understand
> the basic features of GMPLS. If I want to create an MPLS LSP between the
two
> MPLS routers, how do the RSVP PATH message is sent to the network?
(Assuming
> that we have an out-of-band IP control network running LMP)
>
> My guess is that the PATH message will leave the ingress router with a
PATH
> message with a calculated ERO. It assumes that the network is in respect
> with the peer model...everyone have the same routing table and know the
> actual network topology. So, my PATH message will follow the CSPF (ERO)
and
> go to the egress router. Am I right?
>
> Best regards,
>
> Jimmy Gendron
>

Delivery-date: Fri, 08 Jun 2001 19:07:34 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Susumu Yoneda'" <[email-masked]>, Jimmy Gendron <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Fri, 8 Jun 2001 19:05:45 -0700

Jimmy, Susumu,

Your idea (assuming a peer model) is basically correct. Since all nodes
have the same view of the network, you could compute an ERO at the
ingress router and have the PATH message follow the hop-by-hop route
to the egress router.
(Note, however, that the PATH message will travel
on the out-of-band IP control network; therefore, it would be non-associated 
signaling.)

Also, Susumu, if the peer model is in effect, then all messges will,
in fact, have to be shared by all nodes, since that is precisely what
the "peer model" implies.

But you do have to be careful about what "LSP" you are requesting, since the
characteristics of the requested LSP are not interpreted in the same way by the
various pieces of equipment in your figure. (A SONET ADM requires a different
way of defining a circuit than an IP router or an OXC.)
Therefore, one possibility would be to do a "layered setup", where an LSP
at the lower layer is setup before the PATH message at the higher layer
is tunnelled over it or allowed to propagate further.

For example, when the PATH message for the packet
LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
a corresponding SONET circuit between themselves, and then either tunnel
the PATH message for the packet LSP over this circuit, or (assuming your
out-of-band network), at that time, allow the PATH message for the packet
LSP to propagate to the next MPLS router. (The setting up of the SONET
channel, likewise, would be a recursive process, with the OXC first setting
up an optical lightpath between themselves, and tunneling the request to
set up the SONET channel over it, once that lightpath is setup.)

A more detailed discussion of this subject, with corresponding animations
and figures, that you may also find helpful is available in a talk I gave at
MPLSCon'01, and can be found at:
http://www.mplscon.com/missing_presentations.htm
(Dynamic path establishment in MPLS-controlled multi-service networks.)

-Vishal

On Friday, June 08, 2001 6:00 PM, Susumu Yoneda [SMTP:[email-masked]] 
wrote:
> Hi,
>
> I also assume that there would be an out-of-band signalling network based on
> a suite of GMPLS protocols including LMP. I think there will be issues to
> address whether all messages will be shared by all nodes, i.e router,
> SDH/SONET, and OXC or not. This will be a part of security issues.
> -------------------------------
> Susumu Yoneda   tel +81 3 5540 8493
> Japan Telecom    fax +81 3 5540 8485
> Information & Communication Labs.
> e-mail  [email-masked]
> -------------------------------
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jimmy Gendron
> Sent: Friday, June 08, 2001 10:01 PM
> To: [email-masked]'
> Subject: GMPLS Sonet extensions
>
>
> Hi,
>
> I used to read almost all stuff regarding GMPLS since a week. I understand
> most of the architecture, but I still have a question since the beginning;
> as an unified control plane, how do the routing/signaling protocols exchange
> informations on a configuration like this:
>
> MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> -------> OXC --------> SONET ADM --------> MPLS Router
> (Ingress)
>
> Its a basic point to point configuration, but it will allow me to understand
> the basic features of GMPLS. If I want to create an MPLS LSP between the two
> MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming
> that we have an out-of-band IP control network running LMP)
>
> My guess is that the PATH message will leave the ingress router with a PATH
> message with a calculated ERO. It assumes that the network is in respect
> with the peer model...everyone have the same routing table and know the
> actual network topology. So, my PATH message will follow the CSPF (ERO) and
> go to the egress router. Am I right?
>
> Best regards,
>
> Jimmy Gendron
>

Delivery-date: Fri, 08 Jun 2001 17:56:17 -0700
From: "Susumu Yoneda" <[email-masked]>
To: "Jimmy Gendron" <[email-masked]>, <[email-masked]>
Subject: RE: GMPLS Sonet extensions
Date: Sat, 9 Jun 2001 10:00:13 +0900

Hi,

I also assume that there would be an out-of-band signalling network based on
a suite of GMPLS protocols including LMP. I think there will be issues to
address whether all messages will be shared by all nodes, i.e router,
SDH/SONET, and OXC or not. This will be a part of security issues.
-------------------------------
Susumu Yoneda   tel +81 3 5540 8493
Japan Telecom    fax +81 3 5540 8485
Information & Communication Labs.
e-mail  [email-masked]
-------------------------------
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jimmy Gendron
Sent: Friday, June 08, 2001 10:01 PM
To: [email-masked]'
Subject: GMPLS Sonet extensions

Hi,

I used to read almost all stuff regarding GMPLS since a week. I understand
most of the architecture, but I still have a question since the beginning;
as an unified control plane, how do the routing/signaling protocols exchange
informations on a configuration like this:

MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
-------> OXC --------> SONET ADM --------> MPLS Router
(Ingress)

Its a basic point to point configuration, but it will allow me to understand
the basic features of GMPLS. If I want to create an MPLS LSP between the two
MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming
that we have an out-of-band IP control network running LMP)

My guess is that the PATH message will leave the ingress router with a PATH
message with a calculated ERO. It assumes that the network is in respect
with the peer model...everyone have the same routing table and know the
actual network topology. So, my PATH message will follow the CSPF (ERO) and
go to the egress router. Am I right?

Best regards,

Jimmy Gendron

Delivery-date: Fri, 08 Jun 2001 10:37:18 -0700
From: Jonathan Lang <[email-masked]>
To: 'Jimmy Gendron' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: GMPLS recovery and SRLG
Date: Fri, 8 Jun 2001 10:32:03 -0700 

Jimmy,
  Yes.  The SRLGs are used to determine disjoint paths and are included in
the gmpls routing drafts (draft-kompella-ospf-gmpls-extensions-01.txt and
draft-ietf-isis-gmpls-extensions-02.txt).  The SRLGs are then used for
determining routes for backup LSPs and link protection.

Thanks,
Jonathan

> -----Original Message-----
> From: Jimmy Gendron [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 10:46 AM
> To: [email-masked]'
> Subject: GMPLS recovery and SRLG
> 
> 
> Hi,
> 
> after reading the draft-lang-ccamp-recovery-oo.txt document 
> related to GMPLS
> protection/recovery mechanisms, I would like to know if the proposed
> mechanisms supports the SRLG enhancements as proposed before?
> 

Delivery-date: Fri, 08 Jun 2001 06:03:37 -0700
From: Jimmy Gendron <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: GMPLS Sonet extensions
Date: Fri, 8 Jun 2001 09:01:18 -0400 

Hi,

I used to read almost all stuff regarding GMPLS since a week. I understand
most of the architecture, but I still have a question since the beginning;
as an unified control plane, how do the routing/signaling protocols exchange
informations on a configuration like this:

MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
-------> OXC --------> SONET ADM --------> MPLS Router 
(Ingress)

Its a basic point to point configuration, but it will allow me to understand
the basic features of GMPLS. If I want to create an MPLS LSP between the two
MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming
that we have an out-of-band IP control network running LMP)

My guess is that the PATH message will leave the ingress router with a PATH
message with a calculated ERO. It assumes that the network is in respect
with the peer model...everyone have the same routing table and know the
actual network topology. So, my PATH message will follow the CSPF (ERO) and
go to the egress router. Am I right?

Best regards,

Jimmy Gendron

Delivery-date: Thu, 07 Jun 2001 18:11:02 -0700
From: "Tissa Senevirathne" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 .tx
Date: Fri, 08 Jun 2001 01:09:44 

The information were emailed to idsummary tody. In addition the I-D has all 
the requested information included after "Status of This Memo"

Thanks

Tissa

>From: "Wijnen, Bert (Bert)" <[email-masked]>
>To: ccamp-wg <[email-masked]>, Tissa Senevirathne  
><[email-masked]>
>Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 
>.tx
>Date: Thu, 7 Jun 2001 02:02:48 +0200
>
>New I-Ds that are targeted to a WG should be summaried and such
>a summary should be send to the idsummary mailing list (as we
>asked all existing I-D authors to do a few weeks ago).
>
>Bert
>
> > ----------
> > From: 	Tissa Senevirathne[SMTP:[email-masked]]
> > Sent: 	Wednesday, June 06, 2001 4:54 AM
> > To: 	[email-masked]
> > Subject: 	Please could you comment on I-D
> > draft-tsenevir-l2vpn-pmesh-00.tx
> >
> > Below is ID that explain use of partial mesh tunnels to achieve 
>forwarding
> >
> > behavior of full mesh tunnels. The discussion in the ID is manily 
>targeted
> >
> > towards Layer 2 NBVPN.
> >
> > The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest
> > Path
> > Algorithm (Dijkstra) to derive required forwarding tunnels.
> >
> > http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt
> >
> > Please could you comment
> >
> > Thanks
> >
> > Tissa
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >
>

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

Delivery-date: Thu, 07 Jun 2001 10:48:36 -0700
From: Jimmy Gendron <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: GMPLS recovery and SRLG
Date: Thu, 7 Jun 2001 13:46:09 -0400 

Hi,

after reading the draft-lang-ccamp-recovery-oo.txt document related to GMPLS
protection/recovery mechanisms, I would like to know if the proposed
mechanisms supports the SRLG enhancements as proposed before?

Delivery-date: Thu, 07 Jun 2001 09:36:29 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: GMPLS Last Calls
Date: Thu, 7 Jun 2001 17:34:44 +0100 

Hi Dave.....I know exactly what you are saying and its something Andy Reid
and I have chewed over once or twice when considering a functional
architecture description of MPLS.

I was certainly not exhaustive nor precise in my description and
definitions....I was more interested in trying to emphasise the 'no free
lunch' point that making one aspect simpler usually makes some aspect more
complex (normal engineering trade-off).

I see 2 basic forms of MPLS LSPs:

1	One that is a close adjunct function of the IGP.....this is LDP
LSPs, and LDP is required since one cannot easily distribute labels
piggy-backed on a link-state routing protocol like OSPF (though you can with
BGP).

2	One that is not a close adjunct function of the IGP, and requires to
be signalled....this is RSVP-TE and CR-LDP LSPs.

The 'no free lunch' bit here means the former gives an operator more
headaches when considering fault-management and the definition of SLAs for
VPN services for example, whilst potentially getting some gains in
scalability......so that's the trade off I was inferring.

Its a bit like the polarised CO vs CNLS transfer mode view of the
world.....in reality technologies fall some-way between the 2 pure extremes,
and its knowing where the compromises should occur for a given (service)
case.....since neither alone can yield an optimum solution for all cases.
Indeed, one could say this is exactly why we have/need MPLS to augment IP.

Neil
-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: 07 June 2001 16:37
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: GMPLS Last Calls

Neil, you wrote 
-       LDP induced LSPs do not really create a layer network.....since they

allow merging, and this in itself causes some hard QoS problems....like how 
does one define availability in a mpt-pt tree?  [Its the old issue of 'no 
free lunch'...if you push down a problem in 1 dimension (eg scalability), it

creates a problem somewhere else (eg measuing availability in VPNs say)]; 
-       Explicitly routed LSPs on the other hand do form true layer 
networks....since they need to be signalled they exist as true trail objects

in their own right. 
I'm not sure the existence of merging or QoS is necessarily a criteria for
excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for
the purposes of MPLS a layer can exist independently of which subset of
topological constructs in the architecture toolkit it subscribes to. ER-LSPs
overlaid on an LDP infrastructre using integrated routing to me would
constitute a useful definition of a "layer". It is only when I ruthlessly
exclude absolutely everything but the elemental  p2p undirectional trail
from the discussion that such a hard definition applies, unfortunatley much
of the value statements around MPLS disappear at roughly the same time.
cheers 
Dave 

Delivery-date: Thu, 07 Jun 2001 08:38:37 -0700
From: "David Allan" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: GMPLS Last Calls
Date: Thu, 7 Jun 2001 11:36:43 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EF67.A7998520
Content-Type: text/plain;
	charset="ISO-8859-1"

Neil, you wrote

-	LDP induced LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard QoS problems....like how
does one define availability in a mpt-pt tree?  [Its the old issue of 'no
free lunch'...if you push down a problem in 1 dimension (eg scalability), it
creates a problem somewhere else (eg measuing availability in VPNs say)];
-	Explicitly routed LSPs on the other hand do form true layer
networks....since they need to be signalled they exist as true trail objects
in their own right.

I'm not sure the existence of merging or QoS is necessarily a criteria for
excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for
the purposes of MPLS a layer can exist independently of which subset of
topological constructs in the architecture toolkit it subscribes to. ER-LSPs
overlaid on an LDP infrastructre using integrated routing to me would
constitute a useful definition of a "layer". It is only when I ruthlessly
exclude absolutely everything but the elemental  p2p undirectional trail
from the discussion that such a hard definition applies, unfortunatley much
of the value statements around MPLS disappear at roughly the same time.

cheers
Dave

------_=_NextPart_001_01C0EF67.A7998520
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: GMPLS Last Calls</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Neil, you wrote</FONT>
</P>

<P><FONT SIZE=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LDP induced =
LSPs do not really create a layer network.....since they</FONT>
<BR><FONT SIZE=3D2>allow merging, and this in itself causes some hard =
QoS problems....like how</FONT>
<BR><FONT SIZE=3D2>does one define availability in a mpt-pt tree?&nbsp; =
[Its the old issue of 'no</FONT>
<BR><FONT SIZE=3D2>free lunch'...if you push down a problem in 1 =
dimension (eg scalability), it</FONT>
<BR><FONT SIZE=3D2>creates a problem somewhere else (eg measuing =
availability in VPNs say)];</FONT>
<BR><FONT SIZE=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Explicitly =
routed LSPs on the other hand do form true layer</FONT>
<BR><FONT SIZE=3D2>networks....since they need to be signalled they =
exist as true trail objects</FONT>
<BR><FONT SIZE=3D2>in their own right.</FONT>
</P>

<P><FONT SIZE=3D2>I'm not sure the existence of merging or QoS is =
necessarily a criteria for excluding LDP &quot;induced&quot; LSPs as a =
layer. Intuitively it strikes me that for the purposes of MPLS a layer =
can exist independently of which subset of topological constructs in =
the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP =
infrastructre using integrated routing to me would constitute a useful =
definition of a &quot;layer&quot;. It is only when I ruthlessly exclude =
absolutely everything but the elemental&nbsp; p2p undirectional trail =
from the discussion that such a hard definition applies, unfortunatley =
much of the value statements around MPLS disappear at roughly the same =
time.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EF67.A7998520--

Delivery-date: Wed, 06 Jun 2001 17:06:36 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, Tissa Senevirathne <[email-masked]>
Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 .tx
Date: Thu, 7 Jun 2001 02:02:48 +0200 

New I-Ds that are targeted to a WG should be summaried and such
a summary should be send to the idsummary mailing list (as we
asked all existing I-D authors to do a few weeks ago).

Bert

> ----------
> From: 	Tissa Senevirathne[SMTP:[email-masked]]
> Sent: 	Wednesday, June 06, 2001 4:54 AM
> To: 	[email-masked]
> Subject: 	Please could you comment on I-D
> draft-tsenevir-l2vpn-pmesh-00.tx
> 
> Below is ID that explain use of partial mesh tunnels to achieve forwarding
> 
> behavior of full mesh tunnels. The discussion in the ID is manily targeted
> 
> towards Layer 2 NBVPN.
> 
> The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest
> Path 
> Algorithm (Dijkstra) to derive required forwarding tunnels.
> 
> http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt
> 
> Please could you comment
> 
> Thanks
> 
> Tissa
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 

Delivery-date: Wed, 06 Jun 2001 06:07:36 -0700
From: Andre Fredette <[email-masked]>
To: [email-masked]
Cc: Martin Dubuc <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>,  Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>,  "Evan McGinnis (E-mail)" <[email-masked]>, George Swallow <[email-masked]>
Date: Wed, 06 Jun 2001 09:02:29 -0400
Subject: Re: Proposed Addition to CCAMP Charter 

I second George's statement.

Also, as Osama mentioned in a previous note, I will be submitting an I-D on 
requirements for an interface to WDM transmission systems in the next 
couple of days.

This I-D was co-authored by the LMP-WDM and NTIP co-authors, together with 
a few other individuals who expressed an interest during the last meeting.

Andre

At 03:19 PM 6/5/2001 -0400, George Swallow wrote:
>Martin  -
>
> > Looking back at the minutes, there seems to have been quite a debate during
> > the CCAMP session between LMP and NTIP proponents. I do not know how we 
> move
> > forward though. The debate has not been happening on the mailing list. Even
> > though Andre has asked a question to NTIP authors to stir the debate to the
> > mailing, no response has come back. Otherwise, I have only seen some
> > discussions on LMP-WDM vs. funiculus.
>
>Don't confuse LMP with LMP-WDM.  There is no major controversy over
>LMP.  The debate was how to add some functionality to extract
>information from WDMs.  One proposal, LMP-WDM, extends LMP to do
>this.  NTIP proposes a new protocol.  Just because there is a debate
>over where this new functionality goes, we shouldn't let that affect
>the progress of LMP.
>
>...George
>
>
>==================================================================
>George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Jun 2001 20:46:02 -0700
Date: Tue, 5 Jun 2001 20:44:56 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls

Hi Don,

> I have followed this thread and think that there is something more 
> fundamental going on here. The last call for RFC is a milestone for 
> any draft. The issue is that GMPLS is so large the only way we can 
> tackle it is to have interim RFCs that begin to point the way to 
> solving the problem.

Actually, GMPLS has been broken up: there are now 3 major sets of
docs: the "base" GMPLS docs, GMPLS for SONET/SDH, and the upcoming
GMPLS doc for G.709 networks.  The base GMPLS docs are in pretty good
shape; most of the issues (some would say pseudo-issues) being raised
are for the SONET/SDH doc.

BTW, another important factor is that the number of folks (from both
carriers and vendors) that are interested in GMPLS is very high;
CCAMP and IPO have become magnets much the way MPLS was over the
past four years (and still is).  While this is in general great news,
the number of divergent opinions, alternative drafts and proposals,
and issues raised has skyrocketed, as well as, sad to say, the degree
of, how should I put it, "highly charged non-technical discussion".
This means that progress will of necessity be slower, but hopefully,
it also means that GMPLS will be more wide-ranging, and meet a
broader range of carrier needs.

Perhaps this increased number of participants is the "something more
fundamental" that's going on.  I'll leave it to the IESG to figure
it out, and if needed, propose remedies for the "growing pains"
which seem concommitant with success.

Kireeti.

Delivery-date: Tue, 05 Jun 2001 19:55:14 -0700
From: "Tissa Senevirathne" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00.tx
Date: Wed, 06 Jun 2001 02:54:15 

Below is ID that explain use of partial mesh tunnels to achieve forwarding 
behavior of full mesh tunnels. The discussion in the ID is manily targeted 
towards Layer 2 NBVPN.

The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest Path 
Algorithm (Dijkstra) to derive required forwarding tunnels.

http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt

Please could you comment

Thanks

Tissa

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

Delivery-date: Tue, 05 Jun 2001 17:15:39 -0700
From: "Don Fedyk" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Tue, 5 Jun 2001 20:13:47 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EE1D.8E124C40
Content-Type: text/plain;
	charset="ISO-8859-1"

Ananth, Kireeti

I have followed this thread and think that there is something more 
fundamental going on here. The last call for RFC is a milestone for 
any draft. The issue is that GMPLS is so large the only way we can 
tackle it is to have interim RFCs that begin to point the way to 
solving the problem. I don't view them as all encompassing 
specifications just a step in the right direction towards common 
mechanisms. 

One thing that I would have hoped we would achieve with GMPLS was a
forward looking architecture that could be extended. The immediate 
question we must answer is: Have we provided this? 

The longer term question is: 
Will we follow through and cover the other aspects? When will the 
set of GMPLS RFCs become complete? For that we have to stay tuned.

Don

------_=_NextPart_001_01C0EE1D.8E124C40
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: GMPLS Last Calls</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Ananth, Kireeti</FONT>
</P>

<P><FONT SIZE=2>I have followed this thread and think that there is something more </FONT>
<BR><FONT SIZE=2>fundamental going on here. The last call for RFC is a milestone for </FONT>
<BR><FONT SIZE=2>any draft. The issue is that GMPLS is so large the only way we can </FONT>
<BR><FONT SIZE=2>tackle it is to have interim RFCs that begin to point the way to </FONT>
<BR><FONT SIZE=2>solving the problem. I don't view them as all encompassing </FONT>
<BR><FONT SIZE=2>specifications just a step in the right direction towards common </FONT>
<BR><FONT SIZE=2>mechanisms. </FONT>
</P>

<P><FONT SIZE=2>One thing that I would have hoped we would achieve with GMPLS was a</FONT>
<BR><FONT SIZE=2>forward looking architecture that could be extended. The immediate </FONT>
<BR><FONT SIZE=2>question we must answer is: Have we provided this? </FONT>
</P>

<P><FONT SIZE=2>The longer term question is: </FONT>
<BR><FONT SIZE=2>Will we follow through and cover the other aspects? When will the </FONT>
<BR><FONT SIZE=2>set of GMPLS RFCs become complete? For that we have to stay tuned.</FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EE1D.8E124C40--

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Jun 2001 12:22:21 -0700
Message-Id: <[email-masked]>
To: Martin Dubuc <[email-masked]>
cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed Addition to CCAMP Charter 
Date: Tue, 05 Jun 2001 15:19:42 -0400
From: George Swallow <[email-masked]>

Martin  -

> Looking back at the minutes, there seems to have been quite a debate during
> the CCAMP session between LMP and NTIP proponents. I do not know how we move
> forward though. The debate has not been happening on the mailing list. Even
> though Andre has asked a question to NTIP authors to stir the debate to the
> mailing, no response has come back. Otherwise, I have only seen some
> discussions on LMP-WDM vs. funiculus.

Don't confuse LMP with LMP-WDM.  There is no major controversy over
LMP.  The debate was how to add some functionality to extract
information from WDMs.  One proposal, LMP-WDM, extends LMP to do
this.  NTIP proposes a new protocol.  Just because there is a debate
over where this new functionality goes, we shouldn't let that affect
the progress of LMP.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Tue, 05 Jun 2001 12:18:27 -0700
From: "Osama Aboul-Magd" <[email-masked]>
To: Martin Dubuc <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter
Date: Tue, 5 Jun 2001 15:15:11 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0EDF3.D7609200
Content-Type: text/plain;
	charset="ISO-8859-1"

A few clarifications are due. First the debate is between NTIP and LMP-WDM.
The debate is NOT between NTIP and LMP. Secondly, people interested in the
subject have agreed on a set of requirements for that interface. The
requirements have been presented at the last OIF, and are being discussed at
an ITU meeting this week. I think Andre have already submitted a draft to
IETF on those requirements (or he is in the process of doing so).

What I don't understand is why NTIP and LMP-WDM debate has been brought into
this discussion? It seems to me that this discussion is related to setting
WG charter, and to what extent certain items fit or don't fit into a
charter, or IETF in general. It is a wider discussion than just a debate
between two proposals.

Regards;

Osama.
 -----Original Message-----
From: 	Martin Dubuc [mailto:[email-masked]] 
Sent:	Tuesday, June 05, 2001 2:47 PM
To:	'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau
Cc:	Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
Evan McGinnis (E-mail)
Subject:	RE: Proposed Addition to CCAMP Charter

Bert,

Looking back at the minutes, there seems to have been quite a debate during
the CCAMP session between LMP and NTIP proponents. I do not know how we move
forward though. The debate has not been happening on the mailing list. Even
though Andre has asked a question to NTIP authors to stir the debate to the
mailing, no response has come back. Otherwise, I have only seen some
discussions on LMP-WDM vs. funiculus.

What should be the next step to get LMP on the CCAMP WG charter?

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 2:01 PM
To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc
Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
Evan McGinnis (E-mail)
Subject: RE: Proposed Addition to CCAMP Charter
Importance: High

Inline

> ----------
> From: 	Martin Dubuc[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 6:45 PM
> To: 	'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau
> Cc: 	Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: 	RE: Proposed Addition to CCAMP Charter
> 
> Bert,
> 
> Can you tell us when you expect to complete evaluation of all I-D
> summaries?
> Is it a matter of days, weeks, months?
> 
> Who decides whether LMP should be a CCAMP WG charter item? I am quite a
> bit
> surprised that someone is considering putting G-MPLS and LMP in different
> WGs. Is there a rationale for this?
Nope no plans for that... but I believe I did see in some WG minutes that
your WG chairs were considering to merge the LMP and NTIP proposals.
I think it mentioned that requirements would be written down first... and
then one would see what the next steps would be... I would need to dig in
to archives to find what the exact statement was.

In any event, we wanted all I-Ds, also those that were already WG I-Ds
to send in a summary. The WG chairs are the first to assess that input.
as soon as we hear from them, we'll know more.

Bert

> Regards,
> 
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 11:58 AM
> To: ccamp-wg; Thomas D. Nadeau
> Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: RE: Proposed Addition to CCAMP Charter
> Importance: High
> 
> 
> Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
> that have been submitted with CCAMP as the target WG.
> Once we have gone through those, we will also address the work item
> of an LMP MIB (that is if LMP is still also a WG charter item by then).
> 
> Bert
> 
> > ----------
> > From: 	Thomas D. Nadeau[SMTP:[email-masked]]
> > Sent: 	Tuesday, June 05, 2001 5:08 PM
> > To: 	[email-masked]
> > Cc: 	[email-masked]; Scott Bradner; Sudheer Dharanikota
> (E-mail);
> > Jonathan Lang (E-mail); Evan McGinnis (E-mail)
> > Subject: 	Proposed Addition to CCAMP Charter
> > 
> > 
> > 	Hello,
> > 
> > 	It has been brought to my attention recently
> > that despite the WG voting to adopt the LMP-MIB
> > during the Minneapolis meeting, that the adoption of
> > this document is not possible because there is no mention
> > of network management in the CCAMP WG charter. Therefore
> > I propose that since the features we are working
> > on in the WG are not very useful unless they are
> > manageable, that where appropriate,
> > marriageability (or at least SNMP MIBs) of things
> > developed in CCAMP be added to the charter.
> > 
> > 	--Tom
> > 
> > 
> 

------_=_NextPart_001_01C0EDF3.D7609200
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: Proposed Addition to CCAMP Charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A few clarifications are due. First the debate is =
between NTIP and LMP-WDM. The debate is NOT between NTIP and LMP. =
Secondly, people interested in the subject have agreed on a set of =
requirements for that interface. The requirements have been presented =
at the last OIF, and are being discussed at an ITU meeting this week. I =
think Andre have already submitted a draft to IETF on those =
requirements (or he is in the process of doing so).</FONT></P>

<P><FONT SIZE=3D2>What I don't understand is why NTIP and LMP-WDM =
debate has been brought into this discussion? It seems to me that this =
discussion is related to setting WG charter, and to what extent certain =
items fit or don't fit into a charter, or IETF in general. It is a =
wider discussion than just a debate between two proposals.</FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama.</FONT>
<BR><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Martin Dubuc [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
om</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Tuesday, June 05, 2001 2:47 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; 'Wijnen, Bert (Bert)'; =
ccamp-wg; Thomas D. Nadeau</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Scott Bradner; Sudheer =
Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis =
(E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: Proposed Addition to CCAMP Charter</FONT>
</P>

<P><FONT SIZE=3D2>Bert,</FONT>
</P>

<P><FONT SIZE=3D2>Looking back at the minutes, there seems to have been =
quite a debate during</FONT>
<BR><FONT SIZE=3D2>the CCAMP session between LMP and NTIP proponents. I =
do not know how we move</FONT>
<BR><FONT SIZE=3D2>forward though. The debate has not been happening on =
the mailing list. Even</FONT>
<BR><FONT SIZE=3D2>though Andre has asked a question to NTIP authors to =
stir the debate to the</FONT>
<BR><FONT SIZE=3D2>mailing, no response has come back. Otherwise, I =
have only seen some</FONT>
<BR><FONT SIZE=3D2>discussions on LMP-WDM vs. funiculus.</FONT>
</P>

<P><FONT SIZE=3D2>What should be the next step to get LMP on the CCAMP =
WG charter?</FONT>
</P>

<P><FONT SIZE=3D2>Martin</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Wijnen, Bert (Bert) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, June 05, 2001 2:01 PM</FONT>
<BR><FONT SIZE=3D2>To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc</FONT>
<BR><FONT SIZE=3D2>Cc: Scott Bradner; Sudheer Dharanikota (E-mail); =
Jonathan Lang (E-mail);</FONT>
<BR><FONT SIZE=3D2>Evan McGinnis (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Proposed Addition to CCAMP =
Charter</FONT>
<BR><FONT SIZE=3D2>Importance: High</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Inline</FONT>
</P>

<P><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; From: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Martin =
Dubuc[SMTP:[email-masked]]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tuesday, June 05, 2001 6:45 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: &nbsp; 'Wijnen, Bert (Bert)'; ccamp-wg; =
Thomas D. Nadeau</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &nbsp; Scott Bradner; Sudheer Dharanikota =
(E-mail); Jonathan Lang (E-mail);</FONT>
<BR><FONT SIZE=3D2>&gt; Evan McGinnis (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: &nbsp;&nbsp;&nbsp;&nbsp; RE: Proposed =
Addition to CCAMP Charter</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bert,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Can you tell us when you expect to complete =
evaluation of all I-D</FONT>
<BR><FONT SIZE=3D2>&gt; summaries?</FONT>
<BR><FONT SIZE=3D2>&gt; Is it a matter of days, weeks, months?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Who decides whether LMP should be a CCAMP WG =
charter item? I am quite a</FONT>
<BR><FONT SIZE=3D2>&gt; bit</FONT>
<BR><FONT SIZE=3D2>&gt; surprised that someone is considering putting =
G-MPLS and LMP in different</FONT>
<BR><FONT SIZE=3D2>&gt; WGs. Is there a rationale for this?</FONT>
<BR><FONT SIZE=3D2>Nope no plans for that... but I believe I did see in =
some WG minutes that</FONT>
<BR><FONT SIZE=3D2>your WG chairs were considering to merge the LMP and =
NTIP proposals.</FONT>
<BR><FONT SIZE=3D2>I think it mentioned that requirements would be =
written down first... and</FONT>
<BR><FONT SIZE=3D2>then one would see what the next steps would be... I =
would need to dig in</FONT>
<BR><FONT SIZE=3D2>to archives to find what the exact statement =
was.</FONT>
</P>

<P><FONT SIZE=3D2>In any event, we wanted all I-Ds, also those that =
were already WG I-Ds</FONT>
<BR><FONT SIZE=3D2>to send in a summary. The WG chairs are the first to =
assess that input.</FONT>
<BR><FONT SIZE=3D2>as soon as we hear from them, we'll know =
more.</FONT>
</P>

<P><FONT SIZE=3D2>Bert</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Martin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Wijnen, Bert (Bert) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 05, 2001 11:58 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: ccamp-wg; Thomas D. Nadeau</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Scott Bradner; Sudheer Dharanikota =
(E-mail); Jonathan Lang (E-mail);</FONT>
<BR><FONT SIZE=3D2>&gt; Evan McGinnis (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Proposed Addition to CCAMP =
Charter</FONT>
<BR><FONT SIZE=3D2>&gt; Importance: High</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Your WG chairs with the ADs and TAs are =
evaluating all the I-D summaries</FONT>
<BR><FONT SIZE=3D2>&gt; that have been submitted with CCAMP as the =
target WG.</FONT>
<BR><FONT SIZE=3D2>&gt; Once we have gone through those, we will also =
address the work item</FONT>
<BR><FONT SIZE=3D2>&gt; of an LMP MIB (that is if LMP is still also a =
WG charter item by then).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bert</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Thomas D. Nadeau[SMTP:[email-masked]]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Tuesday, June 05, 2001 5:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]; Scott =
Bradner; Sudheer Dharanikota</FONT>
<BR><FONT SIZE=3D2>&gt; (E-mail);</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Jonathan Lang (E-mail); Evan McGinnis =
(E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: &nbsp;&nbsp; Proposed Addition to =
CCAMP Charter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; It has been brought to =
my attention recently</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that despite the WG voting to adopt the =
LMP-MIB</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; during the Minneapolis meeting, that the =
adoption of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this document is not possible because =
there is no mention</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of network management in the CCAMP WG =
charter. Therefore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I propose that since the features we are =
working</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; on in the WG are not very useful unless =
they are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; manageable, that where appropriate,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; marriageability (or at least SNMP MIBs) of =
things</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; developed in CCAMP be added to the =
charter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0EDF3.D7609200--

Delivery-date: Tue, 05 Jun 2001 11:48:01 -0700
From: Martin Dubuc <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter
Date:  Tue, 5 Jun 2001 14:47:01 -0400 

Bert,

Looking back at the minutes, there seems to have been quite a debate during
the CCAMP session between LMP and NTIP proponents. I do not know how we move
forward though. The debate has not been happening on the mailing list. Even
though Andre has asked a question to NTIP authors to stir the debate to the
mailing, no response has come back. Otherwise, I have only seen some
discussions on LMP-WDM vs. funiculus.

What should be the next step to get LMP on the CCAMP WG charter?

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 2:01 PM
To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc
Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
Evan McGinnis (E-mail)
Subject: RE: Proposed Addition to CCAMP Charter
Importance: High

Inline

> ----------
> From: 	Martin Dubuc[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 6:45 PM
> To: 	'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau
> Cc: 	Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: 	RE: Proposed Addition to CCAMP Charter
> 
> Bert,
> 
> Can you tell us when you expect to complete evaluation of all I-D
> summaries?
> Is it a matter of days, weeks, months?
> 
> Who decides whether LMP should be a CCAMP WG charter item? I am quite a
> bit
> surprised that someone is considering putting G-MPLS and LMP in different
> WGs. Is there a rationale for this?
Nope no plans for that... but I believe I did see in some WG minutes that
your WG chairs were considering to merge the LMP and NTIP proposals.
I think it mentioned that requirements would be written down first... and
then one would see what the next steps would be... I would need to dig in
to archives to find what the exact statement was.

In any event, we wanted all I-Ds, also those that were already WG I-Ds
to send in a summary. The WG chairs are the first to assess that input.
as soon as we hear from them, we'll know more.

Bert

> Regards,
> 
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 11:58 AM
> To: ccamp-wg; Thomas D. Nadeau
> Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: RE: Proposed Addition to CCAMP Charter
> Importance: High
> 
> 
> Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
> that have been submitted with CCAMP as the target WG.
> Once we have gone through those, we will also address the work item
> of an LMP MIB (that is if LMP is still also a WG charter item by then).
> 
> Bert
> 
> > ----------
> > From: 	Thomas D. Nadeau[SMTP:[email-masked]]
> > Sent: 	Tuesday, June 05, 2001 5:08 PM
> > To: 	[email-masked]
> > Cc: 	[email-masked]; Scott Bradner; Sudheer Dharanikota
> (E-mail);
> > Jonathan Lang (E-mail); Evan McGinnis (E-mail)
> > Subject: 	Proposed Addition to CCAMP Charter
> > 
> > 
> > 	Hello,
> > 
> > 	It has been brought to my attention recently
> > that despite the WG voting to adopt the LMP-MIB
> > during the Minneapolis meeting, that the adoption of
> > this document is not possible because there is no mention
> > of network management in the CCAMP WG charter. Therefore
> > I propose that since the features we are working
> > on in the WG are not very useful unless they are
> > manageable, that where appropriate,
> > marriageability (or at least SNMP MIBs) of things
> > developed in CCAMP be added to the charter.
> > 
> > 	--Tom
> > 
> > 
> 

Delivery-date: Tue, 05 Jun 2001 11:24:38 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: George Swallow <[email-masked]>
Cc: ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter 
Date: Tue, 5 Jun 2001 20:22:33 +0200 

George... in principle we want all protocols to also define a MIB
such that the protocol is manageable. We DO WANT such an item 
on the WG charter as a work item though.

So... I think things are REAL EASY.
Once we decide on the final I-Ds that are in CCAMP, then if LMP
is part of it, then it seems logical to also do a MIB. We should
then pass that through IESG/IAB as explained by Scott.

Bert

> ----------
> From: 	George Swallow[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 6:49 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	ccamp-wg; Thomas D. Nadeau; Scott Bradner; Sudheer Dharanikota
> (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail);
> [email-masked]
> Subject: 	Re: Proposed Addition to CCAMP Charter 
> 
> Bert -
> 
> > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
> > that have been submitted with CCAMP as the target WG.
> > Once we have gone through those, we will also address the work item
> > of an LMP MIB (that is if LMP is still also a WG charter item by then).
> 
> It is my understanding that the IESG is actively encouraging MIB work
> to be done along with (i.e. in the same WG) as the protocols they
> manage.  In that regard no explicit mention of a MIB for a protocol is
> necessary in the charter (just like an applicability statement).  Has
> that changed?
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 

Delivery-date: Tue, 05 Jun 2001 11:03:07 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Martin Dubuc <[email-masked]>
Cc: Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter
Date: Tue, 5 Jun 2001 20:01:29 +0200 

Inline

> ----------
> From: 	Martin Dubuc[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 6:45 PM
> To: 	'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau
> Cc: 	Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: 	RE: Proposed Addition to CCAMP Charter
> 
> Bert,
> 
> Can you tell us when you expect to complete evaluation of all I-D
> summaries?
> Is it a matter of days, weeks, months?
> 
> Who decides whether LMP should be a CCAMP WG charter item? I am quite a
> bit
> surprised that someone is considering putting G-MPLS and LMP in different
> WGs. Is there a rationale for this?
Nope no plans for that... but I believe I did see in some WG minutes that
your WG chairs were considering to merge the LMP and NTIP proposals.
I think it mentioned that requirements would be written down first... and
then one would see what the next steps would be... I would need to dig in
to archives to find what the exact statement was.

In any event, we wanted all I-Ds, also those that were already WG I-Ds
to send in a summary. The WG chairs are the first to assess that input.
as soon as we hear from them, we'll know more.

Bert

> Regards,
> 
> Martin
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 11:58 AM
> To: ccamp-wg; Thomas D. Nadeau
> Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: RE: Proposed Addition to CCAMP Charter
> Importance: High
> 
> 
> Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
> that have been submitted with CCAMP as the target WG.
> Once we have gone through those, we will also address the work item
> of an LMP MIB (that is if LMP is still also a WG charter item by then).
> 
> Bert
> 
> > ----------
> > From: 	Thomas D. Nadeau[SMTP:[email-masked]]
> > Sent: 	Tuesday, June 05, 2001 5:08 PM
> > To: 	[email-masked]
> > Cc: 	[email-masked]; Scott Bradner; Sudheer Dharanikota
> (E-mail);
> > Jonathan Lang (E-mail); Evan McGinnis (E-mail)
> > Subject: 	Proposed Addition to CCAMP Charter
> > 
> > 
> > 	Hello,
> > 
> > 	It has been brought to my attention recently
> > that despite the WG voting to adopt the LMP-MIB
> > during the Minneapolis meeting, that the adoption of
> > this document is not possible because there is no mention
> > of network management in the CCAMP WG charter. Therefore
> > I propose that since the features we are working
> > on in the WG are not very useful unless they are
> > manageable, that where appropriate,
> > marriageability (or at least SNMP MIBs) of things
> > developed in CCAMP be added to the charter.
> > 
> > 	--Tom
> > 
> > 
> 

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Jun 2001 10:52:25 -0700
Message-Id: <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed Addition to CCAMP Charter 
Date: Tue, 05 Jun 2001 12:49:10 -0400
From: George Swallow <[email-masked]>

Bert -

> Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
> that have been submitted with CCAMP as the target WG.
> Once we have gone through those, we will also address the work item
> of an LMP MIB (that is if LMP is still also a WG charter item by then).

It is my understanding that the IESG is actively encouraging MIB work
to be done along with (i.e. in the same WG) as the protocols they
manage.  In that regard no explicit mention of a MIB for a protocol is
necessary in the charter (just like an applicability statement).  Has
that changed?

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Jun 2001 10:43:52 -0700
Date: Tue, 5 Jun 2001 13:42:19 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Proposed Addition to CCAMP Charter
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

>     It was rather pointedly implied by Bert's comment in which he
> said - "(that is if LMP is still also a WG charter item by then)".
> Admittedly, this could mean that the group (also known as 'them'*)
> is thinking that LMP would be a charter item in no WG at all.  

Bert made no mention of any other working group

just to be clear nothing in this or any of Bert's messages makes any
value judgements about LMP or an LMP MIB - 

IETF working group charters specify what a working group is to work on -
if a topic is not in the charter then it can not be a formal WG task

changes to IETF WG charetrs are worked out between teh WG chairs
and the ADs (and in this case TA) - if the ADs are convinced then they
will take the proposed changes to the IESG.  The IESG (with advice from the
IAB) must approve all changes to charters.  Note that the IESG is generally
reluctant to add work to a WG charter until the WG has shown that it
can get work done.

Scott

Delivery-date: Tue, 05 Jun 2001 10:28:44 -0700
Date: Tue, 05 Jun 2001 13:26:04 -0400
From: Eric Gray <[email-masked]>
To: Scott Bradner <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Addition to CCAMP Charter

Scott,

    It was rather pointedly implied by Bert's comment in which he
said - "(that is if LMP is still also a WG charter item by then)".
Admittedly, this could mean that the group (also known as 'them'*)
is thinking that LMP would be a charter item in no WG at all.

*    'they' are composed of WG chairs (which WGs?), Area Directors
(presumably you and Bert) and the technical advisors (Rob Coltun and
Dave Oran, still?).

--
Eric Gray

You wrote:

> > I am quite a bit
> > surprised that someone is considering putting G-MPLS and LMP in different
>
> > WGs.
>
> where did you here this?
>
> Scott

Envelope-to: [email-masked]
Delivery-date: Tue, 05 Jun 2001 09:53:55 -0700
Date: Tue, 5 Jun 2001 12:52:05 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Proposed Addition to CCAMP Charter
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

> I am quite a bit
> surprised that someone is considering putting G-MPLS and LMP in different

> WGs.

where did you here this?

Scott

Delivery-date: Tue, 05 Jun 2001 09:46:39 -0700
From: Martin Dubuc <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter
Date:  Tue, 5 Jun 2001 12:45:05 -0400 

Bert,

Can you tell us when you expect to complete evaluation of all I-D summaries?
Is it a matter of days, weeks, months?

Who decides whether LMP should be a CCAMP WG charter item? I am quite a bit
surprised that someone is considering putting G-MPLS and LMP in different
WGs. Is there a rationale for this?

Regards,

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 11:58 AM
To: ccamp-wg; Thomas D. Nadeau
Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail);
Evan McGinnis (E-mail)
Subject: RE: Proposed Addition to CCAMP Charter
Importance: High

Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
that have been submitted with CCAMP as the target WG.
Once we have gone through those, we will also address the work item
of an LMP MIB (that is if LMP is still also a WG charter item by then).

Bert

> ----------
> From: 	Thomas D. Nadeau[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 5:08 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; Scott Bradner; Sudheer Dharanikota (E-mail);
> Jonathan Lang (E-mail); Evan McGinnis (E-mail)
> Subject: 	Proposed Addition to CCAMP Charter
> 
> 
> 	Hello,
> 
> 	It has been brought to my attention recently
> that despite the WG voting to adopt the LMP-MIB
> during the Minneapolis meeting, that the adoption of
> this document is not possible because there is no mention
> of network management in the CCAMP WG charter. Therefore
> I propose that since the features we are working
> on in the WG are not very useful unless they are
> manageable, that where appropriate,
> marriageability (or at least SNMP MIBs) of things
> developed in CCAMP be added to the charter.
> 
> 	--Tom
> 
> 

Delivery-date: Tue, 05 Jun 2001 08:59:17 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>
Subject: RE: Proposed Addition to CCAMP Charter
Date: Tue, 5 Jun 2001 17:57:50 +0200 

Your WG chairs with the ADs and TAs are evaluating all the I-D summaries
that have been submitted with CCAMP as the target WG.
Once we have gone through those, we will also address the work item
of an LMP MIB (that is if LMP is still also a WG charter item by then).

Bert

> ----------
> From: 	Thomas D. Nadeau[SMTP:[email-masked]]
> Sent: 	Tuesday, June 05, 2001 5:08 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; Scott Bradner; Sudheer Dharanikota (E-mail);
> Jonathan Lang (E-mail); Evan McGinnis (E-mail)
> Subject: 	Proposed Addition to CCAMP Charter
> 
> 
> 	Hello,
> 
> 	It has been brought to my attention recently
> that despite the WG voting to adopt the LMP-MIB
> during the Minneapolis meeting, that the adoption of
> this document is not possible because there is no mention
> of network management in the CCAMP WG charter. Therefore
> I propose that since the features we are working
> on in the WG are not very useful unless they are
> manageable, that where appropriate,
> marriageability (or at least SNMP MIBs) of things
> developed in CCAMP be added to the charter.
> 
> 	--Tom
> 
> 

Delivery-date: Tue, 05 Jun 2001 08:49:51 -0700
Date: Tue, 05 Jun 2001 11:48:08 -0400
From: Eric Gray <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: Common Control and Measurement Protocols <[email-masked]>
Subject: Re: Proposed Addition to CCAMP Charter

Tom,

    I thought that management work is now an implied part of
all working group charters.  I agree with you that a specific
WG charter should include specific manageability goals.

--
Eric Gray

You wrote:

>         Hello,
>
>         It has been brought to my attention recently
> that despite the WG voting to adopt the LMP-MIB
> during the Minneapolis meeting, that the adoption of
> this document is not possible because there is no mention
> of network management in the CCAMP WG charter. Therefore
> I propose that since the features we are working
> on in the WG are not very useful unless they are
> manageable, that where appropriate,
> marriageability (or at least SNMP MIBs) of things
> developed in CCAMP be added to the charter.
>
>         --Tom

Delivery-date: Tue, 05 Jun 2001 08:49:18 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>, ipo-wg <[email-masked]>, [email-masked]
Cc: Scott Bradner <[email-masked]>
Subject: RE: [IP-Optical] RE: Arbitrary concatenation proposals
Date: Tue, 5 Jun 2001 17:47:16 +0200 

> We want their personal input based on their personal experience with
> a data network operator or based on direct discussions with people who
> work for data network operators.  We do not need assertions based
> on suppositions or marketing hopes.
> 
> Scott and Bert
> 
> ----------
> >
> > 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
> 

Delivery-date: Tue, 05 Jun 2001 08:11:11 -0700
Date: Tue, 05 Jun 2001 11:08:31 -0400
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Proposed Addition to CCAMP Charter
Cc: [email-masked], Scott Bradner <[email-masked]>, "Sudheer Dharanikota (E-mail)" <[email-masked]>, "Jonathan Lang (E-mail)" <[email-masked]>, "Evan McGinnis (E-mail)" <[email-masked]>

	Hello,

	It has been brought to my attention recently
that despite the WG voting to adopt the LMP-MIB
during the Minneapolis meeting, that the adoption of
this document is not possible because there is no mention
of network management in the CCAMP WG charter. Therefore
I propose that since the features we are working
on in the WG are not very useful unless they are
manageable, that where appropriate,
marriageability (or at least SNMP MIBs) of things
developed in CCAMP be added to the charter.

	--Tom

Delivery-date: Mon, 04 Jun 2001 12:37:52 -0700
From: [email-masked]
Date: Mon, 4 Jun 2001 13:42:53 -0500
Subject: RE: Re: GMPLS Last Calls
TO: [email-masked], [email-masked]

--openmail-part-408bcd0a-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Mon, 4 Jun 2001 13:42:53 -0500"
Content-Transfer-Encoding: 7bit

Kireeti,

>However, any attempt to say "I work for such-and-and company, hence
>you should listen to me", or "I speak for such-and-such company as
>a whole" goes in my bitbucket -- in Randy's words, "is irrelevant".
>If a suggestion or argument cannot stand on its own, throwing the
>weight of one's company's name behind it won't help hold it up.  I
>am sure that that was not the intent in the email that started this
>thread, but invoking company names raises doubts.

I don't know if this email was intended for me or for "anonymous".  
Would like to reiterate that it was not my intention to "throw the 
weight of my company's name" (as you've correctly pointed out).  
Unfortunately, the group of individuals that I work with that 
contributed to my email are not very familiar with the "IETF culture" 
and would rather see the company name being quoted (as they see in the 
standards fora that they go to).  I am hoping that the innocent 
misdemeanor of quoting my company's name be ignored (far too much has 
been said on this already).  We're thankful to the few folks who have 
continued the technical discussion in spite of all the entertainment 
that's floating around, and will concentrate on addressing those 
technical comments/questions.

Thanks,
Ananth

--openmail-part-408bcd0a-00000001--

Envelope-to: [email-masked]
Delivery-date: Mon, 04 Jun 2001 12:00:38 -0700
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls 
Date: Mon, 04 Jun 2001 14:59:22 -0400
From: George Swallow <[email-masked]>

All, and especially anonimous,

Since we are an organization of individuals, anyone not revealing
their individual identity should be ignored.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Mon, 04 Jun 2001 11:09:26 -0700
From: Randy Bush <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: MPLS Mailing List <[email-masked]>, Common Control and Measurement Protocols <[email-masked]>
Subject: Re: GMPLS Last Calls
Date: Mon, 04 Jun 2001 11:07:51 -0700

> Also, in spite of Randy's comments, people DO want to hear from members of
> companies.

you may be misunderstanding my comment.  it is understood that almost all
of us still are employed, despite the economy.  but the ietf is explicitly,
not accidentally, composed of individuals, not companies.  and, as we have
had unfortunate incidents of attempts at company block pressure for and
against some work, many of us have become quite sensitized to this, and try
to make the issue clear before entering any slippery slope.

please excuse that i am too often overly sensitive to such process issues,
and too often insufficiently patient in explaining.

randy

Envelope-to: [email-masked]
Delivery-date: Mon, 04 Jun 2001 10:59:28 -0700
Date: Mon, 4 Jun 2001 10:56:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: GMPLS Last Calls

Hi Anonymous,

> > I agree with you whole heartedly.  We must have the inputs from the carriers
> > and not from the vendors alone.

First off, there is an explicit request for input from *carriers* and
*service providers* (same beast, different color), especially for
requirements and in requirements-oriented design teams.  It's a simple
distinction: carriers use the technology; vendors build the technology.
Speaking as a contributor to the IETF, I have no desire to build
technology (or define protocols) that won't be used; and if carriers
don't have input into requirements, they always have the ultimate
vote: not to buy/put into production the various new technologies/
features.

So, prefacing emails to IETF lists by "I work for a carrier" or "I
work for a vendor" (or better yet, "I deploy the technology" or "I
build the technology") helps set the context, and is more than
acceptable, it is desirable (from my point of view).

However, any attempt to say "I work for such-and-and company, hence
you should listen to me", or "I speak for such-and-such company as
a whole" goes in my bitbucket -- in Randy's words, "is irrelevant".
If a suggestion or argument cannot stand on its own, throwing the
weight of one's company's name behind it won't help hold it up.  I
am sure that that was not the intent in the email that started this
thread, but invoking company names raises doubts.

Please don't interpret Randy's comment as a personal attack, or as
an aspersion on the value of carriers' input to the IETF -- remember
that Randy is an august member of that very same species.

Kireeti.

Delivery-date: Mon, 04 Jun 2001 08:58:42 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: GMPLS Last Calls 
Date: Mon, 4 Jun 2001 16:56:49 +0100 

Yakov Rekhter wrote 04 June 2001 15:48
<snipped>
> >
> > Issues that we have found relate to -
> >
> > 1.  MPLS is not for QoS (See first paragraph of Chapter 6 
> of Yakov Rekhter's
> > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), 
> Yakov says, " To
> > many people, QoS is the driving factor behind MPLS.  This 
> is actually
> > something of a misconception......QoS is not a very strong 
> reason to deploy
> > MPLS..."
> 
> The above seems like quoting out of context. To put it in the proper
> context here is the full sentence:
> 
>    Compared to other factors, such as traffic engineering and Virtual
>    Private Network support, QoS is not a very strong reason to deploy
>    MPLS.
> 
> So, what you seem to be missing is that it is *relative* to other
> applications, such as TE and VPN, that "QoS is not a very 
> strong reason
> to deploy MPLS".
> 
> And while on the subject of QoS and MPLS, further in the 
> first section 
> of Chapter 6 (page 148):
> 
>   ..there are some novel QoS capabilities that can be supported across
>   a provider network using MPLS that, while not being truly 
> end-to-end,
>   nevertheless may prove very useful. One of these, 
> guaranteed bandwidth
>   LSPs, is discussed in Section 7.5.2.

NH=> MPLS has the potential to become very important and have a key role on
QoS issues (and it should not be confused with GMPLS see 'note' at
end).....but to get there we need to recognise these points:
-	LDP is to me an IP routing adjunct.....its main role as I see it is
to provde address partitioning (or a 'hierachy of routing' as I think you
described it in your book Yakov....which, if anyone has not read it, I can
strongly recommend);
-	LDP induced LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard QoS problems....like how
does one define availability in a mpt-pt tree?  [Its the old issue of 'no
free lunch'...if you push down a problem in 1 dimension (eg scalability), it
creates a problem somewhere else (eg measuing availability in VPNs say)];
-	Explicitly routed LSPs on the other hand do form true layer
networks....since they need to be signalled they exist as true trail objects
in their own right.
And it was these apsects that our OAM paper tried to address for
MPLS....that is, to attack the QoS problem (wrt operational processes and
measurements) one needs to first define the defects (and MPLS does have the
potential to introduce new ones) and the consequent actions...and from this
we can define availability of the LSPs which in turn is a pre-requisite to
measuring QoS (since QoS is only relevant to the up-state of the LSP).

However.....we have had a 'hard time' from a few on this (maybe there is a
silent majority that support this work?)....and this relates to Eric Gray's
prior mail on why people don't speak up.....besides the fear of ridicule or
abuse, one can only try so many tmes before giving up and going elsewhere.
So maybe there is a deep-seated culture problem that needs addressing?

Note - MPLS introduces a new user-plane technology....the shim header.  By
definition, and as noted above, operators need to manage this in an
OAM/performance sense.  MPLS has the ability to be extended to end
systems....I know this is not currently on the agenda of many, but it has
that *potential* (ie so that applications could choose a priori the transfer
mode, co or cnls).  The arguments for a single control-plane across MPLS and
IP (or to be more precise the 'addressing facet' of the control-plane) is
important if ever MPLS was extended to end systems.....this was the real
problem with ATM and IP unification, ie disjoint addressing.
GMPLS on the other hand does not introduce a new user-plane.  It is about
re-using control-plane facets for different layer networks.  In principle
this is a laudable aim, but its actual embodiment has many technical and
commercial implications that are too deep to go into here and we (ie I and
colleagues in BT) are addressing these elsewhere.
So all I wanted to say here is that one should not compare MPLS and GMPLS
like they are same thing.
>
<snipped to end>

Delivery-date: Mon, 04 Jun 2001 08:14:31 -0700
To: MPLS Mailing List <[email-masked]>, Common Control and Measurement Protocols <[email-masked]>, Eric Gray <[email-masked]>
Subject: Re: GMPLS Last Calls 
Date: Mon, 04 Jun 2001 08:13:31 -0700
From: Yakov Rekhter <[email-masked]>

[minor typo...]

> Since you quoted from "MPLS: Technology and Application" before,
> I'd like to suggest to look at Section 7.6.2 of this book for the
                                         ^^^^^
                                         7.2.6
> discussion of alledged scalability problem with RSVP, when used in
> conjunction with MPLS Constraint-based routing. 

Yakov.

Delivery-date: Mon, 04 Jun 2001 07:48:26 -0700
To: MPLS Mailing List <[email-masked]>, Common Control and Measurement Protocols <[email-masked]>
cc: Eric Gray <[email-masked]>
Subject: Re: GMPLS Last Calls 
Date: Mon, 04 Jun 2001 07:47:39 -0700
From: Yakov Rekhter <[email-masked]>

Anonymous,

> I agree with you whole heartedly.  We must have the inputs from the carriers
> and not from the vendors alone.  Some vendors are pushing MPLS, GMPLS now,
> like this are the best ideas since sliced bread.  But others (Global
> Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the
> problems with MPLS.
>
> Issues that we have found relate to -
>
> 1.  MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's
> book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To
> many people, QoS is the driving factor behind MPLS.  This is actually
> something of a misconception......QoS is not a very strong reason to deploy
> MPLS..."

The above seems like quoting out of context. To put it in the proper
context here is the full sentence:

   Compared to other factors, such as traffic engineering and Virtual
   Private Network support, QoS is not a very strong reason to deploy
   MPLS.

So, what you seem to be missing is that it is *relative* to other
applications, such as TE and VPN, that "QoS is not a very strong reason
to deploy MPLS".

And while on the subject of QoS and MPLS, further in the first section 
of Chapter 6 (page 148):

  ..there are some novel QoS capabilities that can be supported across
  a provider network using MPLS that, while not being truly end-to-end,
  nevertheless may prove very useful. One of these, guaranteed bandwidth
  LSPs, is discussed in Section 7.5.2.
  
> 2.  To do VPN with MPLS with extensions is a bad idea also since BGP is a
> routing protocol that changes state quite often and to use it for VPN with
> MPLS tags is not really a very smart solution as a recent comm related
> magazine article points out (I don't have it here but I can provide it if 
> you are interested),

At best whether "to do VPN with MPLS with extensions" is "a bad idea"
is a matter of opinion. However, since at the beginning of you message
you suggested to get inputs from the carriers, you may look at the
list of authors of draft-rosen-rfc2547bis-03.txt, as this list may
give you a hint of what carriers think about this technology.
 
> 2.  If not for QoS, then is it for TE?  As others have said on this MPLS
> thread, you can easily do TE with a host of network management tools
> available out there - if not real-time, for sure, near-real-time.

First of all, there is a difference between "said" and "done". So,
while other "have said.. you can easily do TE with a host of network
management tools", one could ask whether they actually done this.
And if yes, then the next question would be to compare results with
TE based on MPLS Constraint-based routing.
 
> 3.  Other issues pertaining to MPLS are - scalability: explicit path, RSVP,
> CSFP, all found not scalable from the dawn of these technologies (see Nortel
> site slides on MPLS for one confirmation), and finally

Since you quoted from "MPLS: Technology and Application" before,
I'd like to suggest to look at Section 7.6.2 of this book for the
discussion of alledged scalability problem with RSVP, when used in
conjunction with MPLS Constraint-based routing. 

Yakov.

Delivery-date: Mon, 04 Jun 2001 07:45:49 -0700
From: [email-masked]
Date: Mon, 4 Jun 2001 09:45:11 -0500
Subject: RE: Re: GMPLS Last Calls
TO: [email-masked], [email-masked], [email-masked]

--openmail-part-407f3a21-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Mon, 4 Jun 2001 09:45:10 -0500"
Content-Transfer-Encoding: 7bit

This is to the same individual who sent me a private e-mail with 
similar content as was sent to Eric Gray:

Please don't misinterpret my GMPLS concerns as concerns about MPLS as a 
whole.  Please note that I am very supportive of MPLS, and in fact, I 
like the very aspects of MPLS that you point out as bad things (MPLS 
for TE, BGP-MPLS and Virtual Router-based VPNs etc.)  I also have no 
problem with GMPLS as the protocol of choice for the optical control 
plane (In fact i think it is a very logical idea).  My e-mail was to 
point out, what carriers may think as deficiencies with GMPLS for the 
optical control plane.  I welcome comments, like Bala's and others' 
clarifying the different features that address our concerns.  After 
all, voicing concerns and getting clarifications on a protocol is 
supposed to be an educational process as well.  (Doesn't mean that all 
the concerns that had been expressed in my e-mail have been resolved, 
but those will be addressed via a separate e-mail).

Cheers,
Ananth

-----Original Message-----
From: eric.gray [mailto:[email-masked]]
Sent: Monday, June 04, 2001 9:06 AM
To: mpls; ccamp
Subject: Re: GMPLS Last Calls

Anonymous,

    Look, I know that these IETF mailing lists are prone to flame wars
and that many people prefer to be silent 'lurkers' as a result.  But, 
unless
people are willing to come forward with their comments directly, it is 
not
very likely that they will be heard.  Also, in spite of Randy's 
comments,
people DO want to hear from members of companies.  It is easy to express
high sounding, but meaningless, opinions when posting as 'an 
individual' -
especially when posting from an anonymous free E-mail account (as so
many people do these days).

    Understand that - if you come forward with an opinion or idea that 
you
and your colleagues have come up with together - your opinion/idea will 
have
only the weight of an individual opinion.  In theory, your opinions and 
ideas
should be considered by IETF participants solely on their merit and not 
as a
result of who you work for (or what your position is in the IETF).  
Also, in
theory, it is understood that your individual opinions and ideas do not 
reflect
the opinions and ideas of your employer.  And most of us (wink, wink) 
believe
this too.

    Personally, I think there is entirely too much censure (read 
'flames') going

on.  If you and your colleagues each individually express the same 
opinion,
you will hear comments like 'well, one company heard from'.  On the 
other
hand, if one of you expresses a common opinion, he/she will be censured 
for
not expressing an individual opinion.  It may seem like you can't win, 
but you
have to try.   And - until some IETF 'king' decides to stoop to literal 
censure
- your opinions will be heard in spite of the flames... :-)

--
Eric Gray

'Anonymous' wrote:

> Eric,
>
> I agree with you whole heartedly.  We must have the inputs from the 
carriers
> and not from the vendors alone.  Some vendors are pushing MPLS, GMPLS 
now,
> like this are the best ideas since sliced bread.  But others (Global
> Crossing's Plonka, and Ananth, etc.) have pointed out in different 
forums the
> problems with MPLS.
>
> Issues that we have found relate to -
>
> 1.  MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov 
Rekhter's
> book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, 
" To
> many people, QoS is the driving factor behind MPLS.  This is actually
> something of a misconception......QoS is not a very strong reason to 
deploy
> MPLS..."
>
> 2.  To do VPN with MPLS with extensions is a bad idea also since BGP 
is a
> routing protocol that changes state quite often and to use it for VPN 
with
> MPLS tags is not really a very smart solution as a recent comm related
> magazine article points out (I don't have it here but I can provide 
it if you
> are interested),
>
> 2.  If not for QoS, then is it for TE?  As others have said on this 
MPLS
> thread, you can easily do TE with a host of network management tools
> available out there - if not real-time, for sure, near-real-time.
>
> 3.  Other issues pertaining to MPLS are - scalability: explicit path, 
RSVP,
> CSFP, all found not scalable from the dawn of these technologies (see 
Nortel
> site slides on MPLS for one confirmation), and finally
>
> 4. No one addresses the fact that tagging and variable packet sizing 
enroute
> for a packet is extremely high memory and processing hog (hardly 
acceptable
> for the hundreds and thousands of older routers out there) not to 
mention the
> issues of label explosion, TTL, and risk of MTU violation and 
subsequent
> fragmentation and retagging of packets.
>
> My colleagues and I wonder why no one speaks up.
>
> (Please feel free to use these items in the thread if you don't use 
my name.
> Thanks.)
>
> (Anonymous)
>
> Eric Gray wrote:
>
> > Randy,
> >
> >     Is this one of your usual insightful comments?  Let's see what 
our
> > studio audience has to say - Bzztzzt!  Apparently that was a wrong
> > answer.  :-)
> >
> >     Repeatedly we ask for input from carriers.  We get some and we
> > hear that we're only interested in hearing from individuals?  As 
Lloyd
> > said, interesting...
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > > These are the collective opinions of me and my colleagues
> > >
> > > as the ietf is composed of individuals, i have not read your 
irrelevant
> > > message.  should you have personal expertise you wish to share, i 
would
> > > be very inteested in hearing it.
> > >
> > > randy

--openmail-part-407f3a21-00000001--

Delivery-date: Mon, 04 Jun 2001 07:07:40 -0700
Date: Mon, 04 Jun 2001 10:05:57 -0400
From: Eric Gray <[email-masked]>
To: MPLS Mailing List <[email-masked]>, Common Control and Measurement Protocols <[email-masked]>
Subject: Re: GMPLS Last Calls

Anonymous,

    Look, I know that these IETF mailing lists are prone to flame wars
and that many people prefer to be silent 'lurkers' as a result.  But, unless
people are willing to come forward with their comments directly, it is not
very likely that they will be heard.  Also, in spite of Randy's comments,
people DO want to hear from members of companies.  It is easy to express
high sounding, but meaningless, opinions when posting as 'an individual' -
especially when posting from an anonymous free E-mail account (as so
many people do these days).

    Understand that - if you come forward with an opinion or idea that you
and your colleagues have come up with together - your opinion/idea will have
only the weight of an individual opinion.  In theory, your opinions and ideas
should be considered by IETF participants solely on their merit and not as a
result of who you work for (or what your position is in the IETF).  Also, in
theory, it is understood that your individual opinions and ideas do not reflect
the opinions and ideas of your employer.  And most of us (wink, wink) believe
this too.

    Personally, I think there is entirely too much censure (read 'flames') going

on.  If you and your colleagues each individually express the same opinion,
you will hear comments like 'well, one company heard from'.  On the other
hand, if one of you expresses a common opinion, he/she will be censured for
not expressing an individual opinion.  It may seem like you can't win, but you
have to try.   And - until some IETF 'king' decides to stoop to literal censure
- your opinions will be heard in spite of the flames... :-)

--
Eric Gray

'Anonymous' wrote:

> Eric,
>
> I agree with you whole heartedly.  We must have the inputs from the carriers
> and not from the vendors alone.  Some vendors are pushing MPLS, GMPLS now,
> like this are the best ideas since sliced bread.  But others (Global
> Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the
> problems with MPLS.
>
> Issues that we have found relate to -
>
> 1.  MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's
> book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To
> many people, QoS is the driving factor behind MPLS.  This is actually
> something of a misconception......QoS is not a very strong reason to deploy
> MPLS..."
>
> 2.  To do VPN with MPLS with extensions is a bad idea also since BGP is a
> routing protocol that changes state quite often and to use it for VPN with
> MPLS tags is not really a very smart solution as a recent comm related
> magazine article points out (I don't have it here but I can provide it if you
> are interested),
>
> 2.  If not for QoS, then is it for TE?  As others have said on this MPLS
> thread, you can easily do TE with a host of network management tools
> available out there - if not real-time, for sure, near-real-time.
>
> 3.  Other issues pertaining to MPLS are - scalability: explicit path, RSVP,
> CSFP, all found not scalable from the dawn of these technologies (see Nortel
> site slides on MPLS for one confirmation), and finally
>
> 4. No one addresses the fact that tagging and variable packet sizing enroute
> for a packet is extremely high memory and processing hog (hardly acceptable
> for the hundreds and thousands of older routers out there) not to mention the
> issues of label explosion, TTL, and risk of MTU violation and subsequent
> fragmentation and retagging of packets.
>
> My colleagues and I wonder why no one speaks up.
>
> (Please feel free to use these items in the thread if you don't use my name.
> Thanks.)
>
> (Anonymous)
>
> Eric Gray wrote:
>
> > Randy,
> >
> >     Is this one of your usual insightful comments?  Let's see what our
> > studio audience has to say - Bzztzzt!  Apparently that was a wrong
> > answer.  :-)
> >
> >     Repeatedly we ask for input from carriers.  We get some and we
> > hear that we're only interested in hearing from individuals?  As Lloyd
> > said, interesting...
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > > These are the collective opinions of me and my colleagues
> > >
> > > as the ietf is composed of individuals, i have not read your irrelevant
> > > message.  should you have personal expertise you wish to share, i would
> > > be very inteested in hearing it.
> > >
> > > randy

Delivery-date: Mon, 04 Jun 2001 02:44:00 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: Re: GMPLS Last Calls
Date: Mon, 4 Jun 2001 10:33:10 +0100 

Bala,

I am uncomfortable about talking about emails that were made in a different
forum, but I think some clarification to the OIF comments is required.

1. The email that Dan Spears sent to the OIF mailing list made it clear that
if there were no responses then the Paris Agreement that ONA Address shall
be capable of accommodating either of the IP or NSAP families would still
stand. It is wrong to assume that no responses meant that there was no need
to support NSAP.

2. It is unreasonable to expect unanimity between carriers given that they
have to support a diverse range of services and customers and legacy
equipment.  Though I'm sure that smart vendors will find ways of
accommodating the majority of their carrier customers requirements.

I do agree that the work has to continue to ensure that all issues are
addressed.

regards

Shehzad Mirza

> -----Original Message-----
> From:	Bala Rajagopalan [SMTP:[email-masked]]
> Sent:	01 June 2001 22:26
> To:	[email-masked]'
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: Re: GMPLS Last Calls
> 
> Ananth:
> 
> I see that some of the issues you bring up are
> not show stoppers. Others need some clarification
> from you (please see below). Also, if you
> have any suggestions on how to resolve (what you
> consider are) the issues, please post them/write
> some drafts. This is the most constructive way
> going forward.
> 
> With regard to NSAP, Dan Speers posted a note
> in the OIF mailing list soliciting response to the following:
> 
> > > 1) Type of legacy equipment needing NSAP addresses 
> > > (also, is
> > > this optical network element or client equipment?)
> > > 2) Rough estimate of number of UNI ports needing NSAP address 
> > > (2002, 2005, and 2010)
> > > 3) Description of application in which this legacy equipment 
> > > will use UNI
> > > signaling
> 
> I don't recall seeing any response. furthermore, the NSAP
> requirement was not unanimously endorsed by all carriers (at
> the OIF). 
> 
> It would also be nice if you can give some insight on
> the timeline in which you need various features, and whether
> the current GMPLS developments are inadequate within
> that timeline. (We can always have a progression of features).
> 
> Please see below. On the whole, I believe that there is no
> need for alarm or panic now (or even to be "very" concerned :-)).
> 
> 
> Regards,
> 
> Bala
> 
> 
> 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] 
> 
> > -----Original Message-----
> 1) GMPLS is being specified without clear requirements identified 
> first.  As such, there is no way to ensure all needed features have 
> been provided by the specification.  For example, control plane 
> management requirements have not adequately been identified and there 
> is concern that the addition of management requirements may cause 
> modifications to GMPLS functions/protocol.
> 
> BR: Please be more specific about what you need now that's missing, and
> how we can address this?
> 
> 2) GMPLS is being defined based on assumptions about proprietary 
> transmission planes without those assumptions being specified. How can 
> we be sure that the control plane support is correct? How can we be 
> sure that it can be combined with other features?  Assumptions 
> regarding the transmission plane that can affect the control plane must 
> be clearly documented. This creates the additional related problem that 
> there is not a clear inter-working defined for interaction between 
> standard/proprietary control planes/transmission planes.
> 
> BR: I get the feeling you're referring to the concatenation/transperency
> issues discussed recently. While the debate has been hot, there's
> no show stopper here. Several suggestions are being considered for
> clarifying standard/non-standard features supported.
> 
> 
> 3) Assuring separation of the control plane from the data plane 
> continues to arise.. When the control plane fails it should not affect 
> existing connections.  Also if connections in progress are affected 
> then they should not leave partially setup connections - they should 
> fail gracefully informing the initiator. The GMPLS architecture 
> document mentions this separation, but it's not clear how the GMPLS 
> signaling specifications reflect the implications of this decoupling.  
> 
> BR: This issue has been discussed for the OIF UNI signaling (GMPLS
> based, as you know), and solutions in the RSVP/LDP space have been
> proposed (some drafts may be written).
> This is also not a show stopper by any means.
> 
> 
> 4) Support for NSAP addresses and in general support such that control 
> plane addressing is independent of clients and vice versa.  Also 
> scalable naming/addressing scheme such as proposed in OIF.
> 
> BR: NSAP, see my initial comments. The OIF is not dealing with
> names/resolution, etc. This has been decided to be out of the
> scope of UNI signaling, and considered as a separate function.
> 
> 
> 5) Since the control plane may be supported via multiple protocols, 
> clear statement of what is - and isn't - covered in the GMPLS Signaling 
> Description, RSVP Extensions, LDP Extensions drafts is needed.
> 
> BR: Don't understand this, but doesn't look like a major issue from
> your phrasing.
> 
> 6) Terminology is an issue (e.g.waveband switching, link)
> 
> BR: Any inconsistencies can be taken care of easily.
> 
> 7) Transaction support for connection set-up and release is needed for 
> connection oriented networks (e.g. crankback capability).
> 
> BR: Internet drafts have already been written on crankback. I suggest
> that you please consider writing some drafts if there is something
> missing.
> 
> 8) Reliable message transfer 
> 
> BR: Very much a part of signaling. the OIF work has considered this
> aspect also. 
> 
> 9) 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. In 
> general, admission control issues need to be addressed.
> 
> BR: Please elaborate on these, specifically, what's new in the
> context of GMPLS.
> 
> 10) The definition of transparency may be overly simplified.  See 
> comments by Ben Mack-Crane:
> I think the debate on transparency indicates that the issue is not as 
> clear
> as we might think.  The OIF document you cite defines forms of 
> transparency
> that are very straightforward (flags 1,2) not the more complex forms in 
> the current GMPLS drafts (flags 3..10).  Also, these are easily 
> provided in
> O-E-O or O-O-O networks operating at the lambda level, but there is no
> standard for providing these over TDM multiplexed SONET/SDH links.
> 
> BR: This is an ongoing topic of discussion. Doesn't break down
> the rest of the proposal.
> 
> If two vendors implement the same signaling but different TDM 
> multiplexing, that 
> doesn't achieve interoperability.  Is there any way in the drafts to 
> determine the scope
> of application of the various signaling elements (that is, whether they 
> apply to UNI or NNI, whether they apply to specific network 
> layers/technologies)?
> 11) One summary of additional items with issues includes:
> - SDH/SONET transparency.
> - SDH/SONET arbitrary concatenation, flexible concatenation.
> - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> - All kinds of end-to-end protection/restoration for any layer, except 
> the IP layer.
> 
> BR: Restoration is not actually covered in the current set of drafts.
> An earlier thread discussed this, and my suggestion is that this
> feature be dealt with separately.
> 
> - The concept of LSC and FSC layers, i.e. concept of lambda and fiber 
> switching.
> 
> BR: What are the issues here?
> 
> - The label set object (only used for lambda issues).
> - LSP encoding type, bandwidth encoding and GPID have to be simplified 
> accordingly.
> - MPLS extensions to control G.709 (since multiplexing, etc is not yet 
> defined).
> 
> BR: A draft is forthcoming on this.
> 
> 12) Support for paths across SONET/SDH gateways
> 
> BR: Please clarify the issues/write drafts.
> 
> 13) Compatibility is required/desired with legacy SDH/SONET equipment 
> [and also legacy DWDM]
> 
> BR: Same as above.
> 
> 14) Just so that we don't stop at 13 :-)
> 
> 
> 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] 
> 

Delivery-date: Sat, 02 Jun 2001 17:13:54 -0700
Date: Sat, 02 Jun 2001 09:28:33 +0900
To: <[email-masked]>
From: Atsushi Iwata <[email-masked]>
Subject: RE: Re: GMPLS Last Calls
Cc: Bala Rajagopalan <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Gerald (Jerry) Ash <[email-masked]>, Adrian Farrel  <[email-masked]>, Norihito Fujita <[email-masked]>

Ananth,

As Bala suggested, I wrote the following I-D proposing the crankback 
routing capability for CR-LDP and RSVP-TE signaling. 

http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-00.txt

Please look at it and if you find any missing pieces for GMPLS signaling, 
please let me know. I would appreciate any constructive comments.

Thank you.

At 17:25 01/06/01 -0400, Bala Rajagopalan wrote:

>7) Transaction support for connection set-up and release is needed for 
>connection oriented networks (e.g. crankback capability).
>
>BR: Internet drafts have already been written on crankback. I suggest
>that you please consider writing some drafts if there is something
>missing.
----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Assistant Manager
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     [email-masked]
NEC-internal E-mail: [email-masked]

*** Organization has been a bit changed since Apr.2001 ***

Delivery-date: Fri, 01 Jun 2001 14:25:59 -0700
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Re: GMPLS Last Calls
Date: Fri, 1 Jun 2001 17:25:32 -0400 

Ananth:

I see that some of the issues you bring up are
not show stoppers. Others need some clarification
from you (please see below). Also, if you
have any suggestions on how to resolve (what you
consider are) the issues, please post them/write
some drafts. This is the most constructive way
going forward.

With regard to NSAP, Dan Speers posted a note
in the OIF mailing list soliciting response to the following:

> > 1) Type of legacy equipment needing NSAP addresses 
> > (also, is
> > this optical network element or client equipment?)
> > 2) Rough estimate of number of UNI ports needing NSAP address 
> > (2002, 2005, and 2010)
> > 3) Description of application in which this legacy equipment 
> > will use UNI
> > signaling

I don't recall seeing any response. furthermore, the NSAP
requirement was not unanimously endorsed by all carriers (at
the OIF). 

It would also be nice if you can give some insight on
the timeline in which you need various features, and whether
the current GMPLS developments are inadequate within
that timeline. (We can always have a progression of features).

Please see below. On the whole, I believe that there is no
need for alarm or panic now (or even to be "very" concerned :-)).

Regards,

Bala

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] 

> -----Original Message-----
1) GMPLS is being specified without clear requirements identified 
first.  As such, there is no way to ensure all needed features have 
been provided by the specification.  For example, control plane 
management requirements have not adequately been identified and there 
is concern that the addition of management requirements may cause 
modifications to GMPLS functions/protocol.

BR: Please be more specific about what you need now that's missing, and
how we can address this?

2) GMPLS is being defined based on assumptions about proprietary 
transmission planes without those assumptions being specified. How can 
we be sure that the control plane support is correct? How can we be 
sure that it can be combined with other features?  Assumptions 
regarding the transmission plane that can affect the control plane must 
be clearly documented. This creates the additional related problem that 
there is not a clear inter-working defined for interaction between 
standard/proprietary control planes/transmission planes.

BR: I get the feeling you're referring to the concatenation/transperency
issues discussed recently. While the debate has been hot, there's
no show stopper here. Several suggestions are being considered for
clarifying standard/non-standard features supported.

3) Assuring separation of the control plane from the data plane 
continues to arise.. When the control plane fails it should not affect 
existing connections.  Also if connections in progress are affected 
then they should not leave partially setup connections - they should 
fail gracefully informing the initiator. The GMPLS architecture 
document mentions this separation, but it's not clear how the GMPLS 
signaling specifications reflect the implications of this decoupling.  

BR: This issue has been discussed for the OIF UNI signaling (GMPLS
based, as you know), and solutions in the RSVP/LDP space have been
proposed (some drafts may be written).
This is also not a show stopper by any means.

4) Support for NSAP addresses and in general support such that control 
plane addressing is independent of clients and vice versa.  Also 
scalable naming/addressing scheme such as proposed in OIF.

BR: NSAP, see my initial comments. The OIF is not dealing with
names/resolution, etc. This has been decided to be out of the
scope of UNI signaling, and considered as a separate function.

5) Since the control plane may be supported via multiple protocols, 
clear statement of what is - and isn't - covered in the GMPLS Signaling 
Description, RSVP Extensions, LDP Extensions drafts is needed.

BR: Don't understand this, but doesn't look like a major issue from
your phrasing.

6) Terminology is an issue (e.g.waveband switching, link)

BR: Any inconsistencies can be taken care of easily.

7) Transaction support for connection set-up and release is needed for 
connection oriented networks (e.g. crankback capability).

BR: Internet drafts have already been written on crankback. I suggest
that you please consider writing some drafts if there is something
missing.

8) Reliable message transfer 

BR: Very much a part of signaling. the OIF work has considered this
aspect also. 

9) 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. In 
general, admission control issues need to be addressed.

BR: Please elaborate on these, specifically, what's new in the
context of GMPLS.

10) The definition of transparency may be overly simplified.  See 
comments by Ben Mack-Crane:
I think the debate on transparency indicates that the issue is not as 
clear
as we might think.  The OIF document you cite defines forms of 
transparency
that are very straightforward (flags 1,2) not the more complex forms in 
the current GMPLS drafts (flags 3..10).  Also, these are easily 
provided in
O-E-O or O-O-O networks operating at the lambda level, but there is no
standard for providing these over TDM multiplexed SONET/SDH links.

BR: This is an ongoing topic of discussion. Doesn't break down
the rest of the proposal.

If two vendors implement the same signaling but different TDM 
multiplexing, that 
doesn't achieve interoperability.  Is there any way in the drafts to 
determine the scope
of application of the various signaling elements (that is, whether they 
apply to UNI or NNI, whether they apply to specific network 
layers/technologies)?
11) One summary of additional items with issues includes:
- SDH/SONET transparency.
- SDH/SONET arbitrary concatenation, flexible concatenation.
- AUG-X, TUG, STS Groups signal types and LSP capabilities.
- All kinds of end-to-end protection/restoration for any layer, except 
the IP layer.

BR: Restoration is not actually covered in the current set of drafts.
An earlier thread discussed this, and my suggestion is that this
feature be dealt with separately.

- The concept of LSC and FSC layers, i.e. concept of lambda and fiber 
switching.

BR: What are the issues here?

- The label set object (only used for lambda issues).
- LSP encoding type, bandwidth encoding and GPID have to be simplified 
accordingly.
- MPLS extensions to control G.709 (since multiplexing, etc is not yet 
defined).

BR: A draft is forthcoming on this.

12) Support for paths across SONET/SDH gateways

BR: Please clarify the issues/write drafts.

13) Compatibility is required/desired with legacy SDH/SONET equipment 
[and also legacy DWDM]

BR: Same as above.

14) Just so that we don't stop at 13 :-)

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] 

Delivery-date: Fri, 01 Jun 2001 13:31:17 -0700
From: [email-masked]
Date: Fri, 1 Jun 2001 15:30:34 -0500
Subject: RE: Re: GMPLS Last Calls
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

--openmail-part-406a2320-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Fri, 1 Jun 2001 15:30:34 -0500"
Content-Transfer-Encoding: 7bit

Eric, Lloyd and other "individuals",
Thanks for being so understanding :-)  I am sorry this thread is going 
on in a direction it was not intended to.  I apologize for offending 
"IETF culture".  As a group of individuals interested in getting 
technical responses to our technical concerns, can we re-focus on the 
technical issues raised collectively by individuals that I work with (I 
hope this description is acceptable)?  Let us get a technical 
discussion going, please!

Ananth

-----Original Message-----
From: eric.gray [mailto:[email-masked]]
Sent: Friday, June 01, 2001 3:19 PM
To: randy
Cc: eric.gray; Nagarajan, Ananth; ccamp; mpls; Alanqar, Wesam; Ferris,
Tammy; Jones, Mark L.; Neir, Lynn
Subject: Re: GMPLS Last Calls

Randy,

    Thanks.  As an individual, I am interested in hearing from other
individuals who can help me to understand what is useful work and
what is not.  I am so interested in hearing this, that I will go to some
lengths to discourage others from censuring them.  I believe it is even
possible that I am not alone among the many individuals participating 
in,
or listening to, this discussion in feeling this way.

    But I could be wrong, and you're certainly entitled to express your 
own
opinion.

--
Eric Gray

You wrote:

> > Is this one of your usual insightful comments?
>
> nope.  a statement of ietf culture and policy.
>
> randy

--openmail-part-406a2320-00000001--

Delivery-date: Fri, 01 Jun 2001 13:19:59 -0700
Date: Fri, 01 Jun 2001 16:18:57 -0400
From: Eric Gray <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

Randy,

    Thanks.  As an individual, I am interested in hearing from other
individuals who can help me to understand what is useful work and
what is not.  I am so interested in hearing this, that I will go to some
lengths to discourage others from censuring them.  I believe it is even
possible that I am not alone among the many individuals participating in,
or listening to, this discussion in feeling this way.

    But I could be wrong, and you're certainly entitled to express your own
opinion.

--
Eric Gray

You wrote:

> > Is this one of your usual insightful comments?
>
> nope.  a statement of ietf culture and policy.
>
> randy

Delivery-date: Fri, 01 Jun 2001 13:03:30 -0700
From: Randy Bush <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls
Date: Fri, 01 Jun 2001 13:00:45 -0700

> Is this one of your usual insightful comments?

nope.  a statement of ietf culture and policy.

randy

Delivery-date: Fri, 01 Jun 2001 12:28:28 -0700
To: Dimitrios Pendarakis <[email-masked]>
cc: "'Jonathan Lang'" <[email-masked]>, "'Fong Liaw'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>, "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last call - RSVP problems 
Date: Fri, 01 Jun 2001 12:26:42 -0700
From: Yakov Rekhter <[email-masked]>

Dimitrios,

> The problem with being in meetings is it took me a long
> time to respond -:)
> 
> So, I 'll try to provide a summary of the messages exchanged
> as well as my understanding of our off-line discussion 
> on the applicability of RSVP and LMP Hello mechanisms.
> 
> An attempt on terminology clarification first:
> Control channel: This is a logical channel over which IP 
> control packets are transported between two network elements 
> (for example a UNI-C and UNI-N in the case of the OIF UNI). 
> A control channel can be realized in multiple ways, for example,
> in-fiber using SONET/SDH overhead bytes, out-of-band over an 
> Ethernet, etc. 
> A pair of network elements may be connected by multiple control 
> channels, used either concurrently or in a primary-backup 
> configuration. Control channel failures can be detected using 
> link management procedures, such as the LMP Hello mechanism. 
> 
> Signaling channel: This is a logical channel over which signaling 
> messages are exchanged between two peers. The signaling channel 
> is realized using (potentially multiple) control channels and 
> it operation relies on processing of signaling messages by the 
> respective peer signaling entities. 
> A signaling channel failure is the result of failure of all control 
> channels, or failure of a signaling entity. Signaling channel 
> failures can be detected using the RSVP hello mechanism (assuming
> of course RSVP is the signaling protocol used!).

And then to extend it further we can also talk about routing channel,
which is a logical channel over which routing messages (Hellos,
Link State Updates) are exchanged between two peers. The routing
channel is realized using (potentially multiple) control channels
and its operation relies on processing of routing messages by the
respective peer routing entities.  A routing channel failure is
the result of failure of all control channels, or failure of a
routing entity. Routing channel failures can be detected using the
ISIS/OSPF hello mechanism (assuming ISIS/OSPF is the routing protocol
used).

Yakov.

Delivery-date: Fri, 01 Jun 2001 12:25:19 -0700
Date: Fri, 01 Jun 2001 15:23:35 -0400
From: Eric Gray <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

Randy,

    Is this one of your usual insightful comments?  Let's see what our
studio audience has to say - Bzztzzt!  Apparently that was a wrong
answer.  :-)

    Repeatedly we ask for input from carriers.  We get some and we
hear that we're only interested in hearing from individuals?  As Lloyd
said, interesting...

--
Eric Gray

You wrote:

> > These are the collective opinions of me and my colleagues
>
> as the ietf is composed of individuals, i have not read your irrelevant
> message.  should you have personal expertise you wish to share, i would
> be very inteested in hearing it.
>
> randy

Delivery-date: Fri, 01 Jun 2001 10:26:48 -0700
From: [email-masked]
Date: Fri, 1 Jun 2001 12:22:55 -0500
Subject: RE: GMPLS Last Calls
TO: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

--openmail-part-4060ffff-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Fri, 1 Jun 2001 12:22:54 -0500"
Content-Transfer-Encoding: 7bit

>as the ietf is composed of individuals, i have not read your irrelevant
>message.  should you have personal expertise you wish to share, i would
>be very inteested in hearing it.

In the interest of saving bandwidth, individual expertise has been 
bundled/aggregated/grouped to have one email instead of several. can't 
help it if this doesn't appeal to you

--openmail-part-4060ffff-00000001--

Delivery-date: Fri, 01 Jun 2001 10:23:54 -0700
To: "Mannie, Eric" <[email-masked]>, "Stephen Trowbridge" <[email-masked]>
Date: Fri, 01 Jun 2001 10:19:08 -0700
From: "Lyndon Ong" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Length: 1083

Hi Folks,

It seems like the discussion is getting back down to earth a bit :o)

I think Eric's point was that arbitrary concatenation is only
incidental to GMPLS, as Greg pointed out in one of the early
emails it is a feature of newer chips.  GMPLS drafts probably
have a leaning towards leading edge features because GMPLS
itself or optical routing is a sort of leading edge feature. 

Hopefully people can use GMPLS as a way to route connections
to take advantage of the availability of new features in an 
optical network, so that it opens up possibilities more than
it causes problems.

BTW, I suspect that virtual concatenation raises more issues
for GMPLS than it does for the transport level - suppose that
you send component channels along different routes, for 
example, you would need to be able to correlate multiple
signaling messages as being part of the same connection
when they are received at the termination point.

Cheers,

Lyndon

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Delivery-date: Fri, 01 Jun 2001 09:59:10 -0700
From: Randy Bush <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Fri, 01 Jun 2001 09:50:50 -0700

> These are the collective opinions of me and my colleagues

as the ietf is composed of individuals, i have not read your irrelevant
message.  should you have personal expertise you wish to share, i would
be very inteested in hearing it.

randy

Delivery-date: Fri, 01 Jun 2001 09:28:27 -0700
From: [email-masked]
Date: Fri, 1 Jun 2001 11:27:49 -0500
Subject: RE: GMPLS Last Calls
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]

--openmail-part-405eee36-00000001
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
	;Creation-Date="Fri, 1 Jun 2001 11:27:49 -0500"
Content-Transfer-Encoding: 8bit

All,
Sprint has remained fairly quiet on the issues regarding the control 
plane as we have been working to formulate our internal views.  We are 
very concerned about the many issues that have been raised regarding 
the proposed draft GMPLS standard over the past few weeks. These are 
the collective opinions of me and my colleagues who are 
involved/interested in optical control plane issues.

Issues raised by others and some added here are of particular concern.  
In order to move forward, it is recommended that the scope of this 
version of the standard be re-evaluated and all issues related to that 
scope of work resolved before standardization. We tried to include here 
as many items that we could although it is not all inclusive as there 
were so many issues raised.  We believe it is not in the best interest 
of any of the parties involved to standardize as things stand with so 
many known issues outstanding. Depending on determined scope (i.e. this 
list could change depending on scope of GMPLS determined by the group), 
here are some items that we currently believe must be addressed before 
final approval:
1) GMPLS is being specified without clear requirements identified 
first.  As such, there is no way to ensure all needed features have 
been provided by the specification.  For example, control plane 
management requirements have not adequately been identified and there 
is concern that the addition of management requirements may cause 
modifications to GMPLS functions/protocol.
2) GMPLS is being defined based on assumptions about proprietary 
transmission planes without those assumptions being specified. How can 
we be sure that the control plane support is correct? How can we be 
sure that it can be combined with other features?  Assumptions 
regarding the transmission plane that can affect the control plane must 
be clearly documented. This creates the additional related problem that 
there is not a clear inter-working defined for interaction between 
standard/proprietary control planes/transmission planes.
3) Assuring separation of the control plane from the data plane 
continues to arise.. When the control plane fails it should not affect 
existing connections.  Also if connections in progress are affected 
then they should not leave partially setup connections – they should 
fail gracefully informing the initiator. The GMPLS architecture 
document mentions this separation, but it's not clear how the GMPLS 
signaling specifications reflect the implications of this decoupling.  
4) Support for NSAP addresses and in general support such that control 
plane addressing is independent of clients and vice versa.  Also 
scalable naming/addressing scheme such as proposed in OIF.
5) Since the control plane may be supported via multiple protocols, 
clear statement of what is - and isn't - covered in the GMPLS Signaling 
Description, RSVP Extensions, LDP Extensions drafts is needed.
6) Terminology is an issue (e.g.waveband switching, link)
7) Transaction support for connection set-up and release is needed for 
connection oriented networks (e.g. crankback capability).
8) Reliable message transfer 
9) 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. In 
general, admission control issues need to be addressed.
10) The definition of transparency may be overly simplified.  See 
comments by Ben Mack-Crane:
I think the debate on transparency indicates that the issue is not as 
clear
as we might think.  The OIF document you cite defines forms of 
transparency
that are very straightforward (flags 1,2) not the more complex forms in 
the current GMPLS drafts (flags 3..10).  Also, these are easily 
provided in
O-E-O or O-O-O networks operating at the lambda level, but there is no
standard for providing these over TDM multiplexed SONET/SDH links.

If two vendors implement the same signaling but different TDM 
multiplexing, that 
doesn't achieve interoperability.  Is there any way in the drafts to 
determine the scope
of application of the various signaling elements (that is, whether they 
apply to UNI or NNI, whether they apply to specific network 
layers/technologies)?
11) One summary of additional items with issues includes:
- SDH/SONET transparency.
- SDH/SONET arbitrary concatenation, flexible concatenation.
- AUG-X, TUG, STS Groups signal types and LSP capabilities.
- All kinds of end-to-end protection/restoration for any layer, except 
the IP layer.
- The concept of LSC and FSC layers, i.e. concept of lambda and fiber 
switching.
- The label set object (only used for lambda issues).
- LSP encoding type, bandwidth encoding and GPID have to be simplified 
accordingly.
- MPLS extensions to control G.709 (since multiplexing, etc is not yet 
defined).
12) Support for paths across SONET/SDH gateways
13) Compatibility is required/desired with legacy SDH/SONET equipment 
[and also legacy DWDM]
14) Just so that we don't stop at 13 :-)

Thanks,
Ananth

--openmail-part-405eee36-00000001--

Delivery-date: Fri, 01 Jun 2001 08:10:29 -0700
Date: Fri, 01 Jun 2001 09:06:13 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Eric,
Let me try to clarify what I think Tony was saying:
- There is a great deal of installed SONET/SDH equipment in todays networks
that does not implement the non-standardized forms of concatenation. The
standardized forms (contiguous at the agreed multiples of the basic rates
and virtual, which involves only the endpoints) are pretty universally
available in todays networks.
- Arbitrary concatenation is not something that can be easily added to
the installed equipment. It generally needs different ASICs. While it may
be possible to build new port boards for existing NEs with the different
ASICs, this doesn't help you with respect to providing the capability on
installed links that are currently providing service. There is no graceful
way to replace port boards in service without creating a traffic hit on
that existing service. This is not something that can be added to most
installed NEs with only a software upgrade.
- Many of the operators of these existing networks would like to offer
switched SONET/SDH services using GMPLS or some other form of control and
signaling. There is a hope and expectation that this can be deployed in
existing networks through software upgrades to some existing NEs and perhaps
some additional controllers. If a fork lift replacement of every NE in the
switching path is needed, I don't think you will see rapid acceptance among
established operators. I think it is also expected that this capability
can be inserted gradually into existing networks - some NEs may simply
provide nailed up pipes between the NEs where the switching functions are
actually performed, and those NEs shouldn't require any kind of upgrade.
Basing the control plane on currently standardized forms of concationation
would provide a much smoother path to incorporate GMPLS capabilities into
many existing networks.

Let me reiterate the hope that the advocates of arbitrary concatenation
will be contributing a precise proposal to the June meeting of T1X1 and
the October meeting of ITU-T Study Group 15. We could save a lot of
emails if everyone had the same picture about what SONET/SDH really is.

Regards,
Steve Trowbridge
Chairman, ITU-T WP 3/15

"Mannie, Eric" wrote:
> 
> Hello Tony
> 
> >Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
> >is the point I have been trying to make all along.
> 
> To be more precise, arbitrary concatenation won't work over SONET/SDH nodes
> that don't implement it, whatever there is a control plane or not. Arbitray
> concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's,
> TM's, etc... Folks didn't wait for a control plane to implement it.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 9:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Sorry,
> 
> Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
> is the point I have been trying to make all along.
> 
> Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not.
> 
> Tony
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 30 May 2001 15:45
> To: 'Zhi-Wei Lin'; John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> I didn't say that, and I don't think that it is true.
> 
> It is my understanding that if there was a set of SONET/SDH pipes between a
> pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
> those pipes however they wished as long as they were consistent with
> SONET/SDH
> transport protocols and the non-GMPLS nodes wouldn't need to understand what
> they were doing.
> 
> I think that this is exactly the same situation as virtual concatenation,
> where
> the endpoints are upgraded without disturbing the intermediate equipment.
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 7:32 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> Yes I agree. As long as the GMPLS nodes are consistent with the
> non-GMPLS cloud, then there is no interop issue.
> 
> As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
> would also need to support this. Then it not only impacts new equipment,
> but also require upgrades to embedded equipment as well for this to
> work?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> > interacting with the GMPLS
> > nodes wrt signalling.  This means that the links between the GMPLS nodes
> at
> > the edges of the non-GMPLS cloud
> > are pre-configured SONET/SDH pipes.  This also means that as long as what
> > the GMPLS nodes are doing
> > with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> > arbitrary concat, then there
> > is no interoperability issue.
> >
> > I think that this is the point that Eric has been making, which has tended
> > to get lost in the noise.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Wednesday, May 30, 2001 5:54 AM
> > To: John Drake
> > Cc: 'Rob Coltun'; [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >
> > I'm not sure it's all new boxes. Would you consider this scenario valid?
> >
> > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> > might go over legacy systems. The no-GMPLS area is simply providing a
> > "tunnel" between the two GMPLS areas.
> >
> > Do we consider such examples?
> >
> > Zhi
> >
> > John Drake wrote:
> > >
> > > Rob,
> > >
> > > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > > extensions include a set of code points called "vendor-specific".
> > >
> > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
> OSPF),
> > > there is the following:
> > >
> > >        Sub-TLV type   Length (octets)  Name
> > >
> > >            250-254                     Reserved for cisco specific
> > > extensions
> > >
> > > More importantly, what I thought Eric was saying was that the
> capabilities
> > > under
> > > discussion, i.e., transparency and arbitrary concatenation, didn't
> require
> > > any
> > > changes to the SONET/SDH standards.  Rather, it would require changes to
> > the
> > > cross-connects between the SONET/SDH spans.  Since these are new boxes,
> it
> > > doesn't
> > > sound like such a big deal.
> > >
> > > Thanks,
> > >
> > > John
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 4:20 PM
> > > To: John Drake
> > > Cc: [email-masked]
> > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > Hi John,
> > >     valid question -  I don't think this is true for BGP. There are
> > > extensions
> > > to BGP that the working group has adopted.
> > > Which TE drafts are you referring to?
> > >
> > > We've said from the beginning that we didn't want to define new "data
> > plane"
> > > functionality for technologies where the data plane is being defined
> > > elsewhere
> > > - whereas some of the functions aren't really new, and in cases might be
> > > de-facto standard
> > > we recognize that certain "data plane" functionality are beyond the
> scope
> > > of the IETF to define - so this keeps us more in line with (in this
> case)
> > > the ITU.
> > >
> > > Note that IETF has defined the
> > > MPLS data plane - if some other body were to define new functionality
> > > for the MPLS data plane it would certainly cause confusion in the
> > industry.
> > > This standard stuff is certainly not easy.
> > >
> > > Is it really that big an issue to just keep them in a separate RFC?
> > >
> > > thanks,
> > > ---rob
> > >
> > > John Drake wrote:
> > >
> > > > Rob,
> > > >
> > > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> > TE
> > > > drafts, for example, there are codepoints defined for use by specific,
> > > > named, vendors.  I think the same is also true for BGP.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Rob Coltun [mailto:[email-masked]]
> > > > Sent: Thursday, May 24, 2001 6:54 PM
> > > > To: [email-masked]
> > > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > > >
> > > > All,
> > > >     despite the heated arguments I think the discussion is important
> to
> > > > have.
> > > >
> > > > I suggest that instead of  tagging non/pre-standard items in the
> current
> > > > drafts
> > > > that they be put into a separate Informational document  - this is the
> > > > cleanest thing to do.
> > > > We (the IETF) do have a tradition of publishing company proprietary
> > > > protocols
> > > > but not as standard track documents.
> > > >
> > > > thanks,
> > > > ---rob

Delivery-date: Fri, 01 Jun 2001 08:08:01 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Fri, 1 Jun 2001 15:54:07 +0100 

Eric,

Could we halt the circular arguments. Arbitrary concatenation is not a part
of SDH/SONET as defined in ITU, ETSI, or as far as I'm aware ANSI. It has
not yet been introduced to ITU. It is being talked about in the same breath
as GMPLS etc, so I associate GMPLS as wishing to introduce the feature.
Regardless of whether this is correct or nor, arbitrary concatenation is not
standardised and will not be transported by existing SDH/SONET networks.

Therefore people who are proposing the use of it should be made aware that
it will not work over existing networks, but there are alternatives that
will.

regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 01 June 2001 09:19
To: [email-masked]'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Tony

>Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
>is the point I have been trying to make all along. 

To be more precise, arbitrary concatenation won't work over SONET/SDH nodes
that don't implement it, whatever there is a control plane or not. Arbitray
concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's,
TM's, etc... Folks didn't wait for a control plane to implement it.

Kind regards,

Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 01, 2001 9:33 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Sorry,

Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
is the point I have been trying to make all along. 

Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not.

Tony

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: 30 May 2001 15:45
To: 'Zhi-Wei Lin'; John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I didn't say that, and I don't think that it is true.

It is my understanding that if there was a set of SONET/SDH pipes between a
pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
those pipes however they wished as long as they were consistent with
SONET/SDH
transport protocols and the non-GMPLS nodes wouldn't need to understand what
they were doing.

I think that this is exactly the same situation as virtual concatenation,
where
the endpoints are upgraded without disturbing the intermediate equipment.  

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 7:32 AM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

Yes I agree. As long as the GMPLS nodes are consistent with the
non-GMPLS cloud, then there is no interop issue. 

As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
would also need to support this. Then it not only impacts new equipment,
but also require upgrades to embedded equipment as well for this to
work?

Zhi

John Drake wrote:
> 
> Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> interacting with the GMPLS
> nodes wrt signalling.  This means that the links between the GMPLS nodes
at
> the edges of the non-GMPLS cloud
> are pre-configured SONET/SDH pipes.  This also means that as long as what
> the GMPLS nodes are doing
> with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> arbitrary concat, then there
> is no interoperability issue.
> 
> I think that this is the point that Eric has been making, which has tended
> to get lost in the noise.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the
capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't
require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes,
it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the
scope
> > of the IETF to define - so this keeps us more in line with (in this
case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important
to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the
current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Fri, 01 Jun 2001 08:04:02 -0700
From: Dimitrios Pendarakis <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Fong Liaw'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>
Cc: "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 1 Jun 2001 10:57:32 -0400 

Jonathan,

The problem with being in meetings is it took me a long
time to respond -:)

So, I 'll try to provide a summary of the messages exchanged
as well as my understanding of our off-line discussion 
on the applicability of RSVP and LMP Hello mechanisms.

An attempt on terminology clarification first:
Control channel: This is a logical channel over which IP 
control packets are transported between two network elements 
(for example a UNI-C and UNI-N in the case of the OIF UNI). 
A control channel can be realized in multiple ways, for example,
in-fiber using SONET/SDH overhead bytes, out-of-band over an 
Ethernet, etc. 
A pair of network elements may be connected by multiple control 
channels, used either concurrently or in a primary-backup 
configuration. Control channel failures can be detected using 
link management procedures, such as the LMP Hello mechanism. 

Signaling channel: This is a logical channel over which signaling 
messages are exchanged between two peers. The signaling channel 
is realized using (potentially multiple) control channels and 
it operation relies on processing of signaling messages by the 
respective peer signaling entities. 
A signaling channel failure is the result of failure of all control 
channels, or failure of a signaling entity. Signaling channel 
failures can be detected using the RSVP hello mechanism (assuming
of course RSVP is the signaling protocol used!).

Hope this helps,
Dimitrios

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 2:08 PM
> To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; 
> 'suresh Katukam'
> Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> Subject: RE: Last call - RSVP problems
> 
> 
> Dimitrios,
>   The luxury of being in meetings all morning is that I had 
> the chance to
> read your email as well as the responses from David, Lyndon, 
> and Eric before
> I respond.  Since I agree with their response, I will try to be brief.
> Using RSVP Hellos to detect RSVP module failures is in my 
> mind the correct
> usage for them.  Control channel failures should be detected 
> by mechanisms
> designed to detect them (e.g., LMP Hellos).   One scenario 
> that carriers are
> interested in supporting is the notion of having parallel 
> redundant control
> channels for signaling purposes.  We will need to support 
> other mechanisms
> for detecting control channel failures in this case.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > Sent: Wednesday, May 30, 2001 7:24 AM
> > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'
> > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > Subject: RE: Last call - RSVP problems
> > 
> > 
> > Jonathan,
> > 
> > Could you please clarify why you think RSVP Hello doesn't work for 
> > parallel (redundant) control channels? Control channel redundancy 
> > is obviously important; however I don't think it relates to the 
> > usefulness of the RSVP hello mechanism, at least in the context of 
> > this discussion.
> > 
> > The whole issue is one of layering: LMP hello allows you to detect 
> > individual link (or control channel) failures; RSVP Hello allows
> > you to detect that you 've lost contact with your signaling peer
> > for whatever reason (failure of all redundant control channels, 
> > failure of the RSVP daemon, etc.). Since they operate at different
> > levels they are to some extend complementary; once RSVP Hello tells
> > you that your peer is not reachable, you could use LMP Hello's to 
> > try to pinpoint where the problem occurred. 
> > 
> > For clarification, the "control channel failure" mentioned in
> > Fong's mail that started this discussion refers to a failure of the
> > signaling channel, i.e., inability to communicate with your 
> signaling
> > peer, not failure of specific (individual) control 
> channels. As such, 
> > I still believe RSVP Hello is a more accurate detection mechanism.
> > 
> > Please see some additional comments inline.
> > 
> > Thanks,
> > Dimitris
> > 
> > 
> > >   If you're using the RSVP Hello to detect the failure of the 
> > > RSVP module
> > > only, then this is fine.  If you're using the RSVP Hello to 
> > detect (or
> > > rather, infer) control channel failures, I have a problem.  
> > > For starters, I
> > > don't think it works for parallel (redundant) control 
> > > channels; if control
> > > channel redundancy is *not* important for SPs, then it's not 
> > > as much of an
> > > issue, however, I think you're overloading the semantics of 
> > > the RSVP Hello.
> > > 
> > >   See additional comments inline.
> > > 
> > > Thanks,
> > > Jonathan
> > > 
> > > > 
> > > > Hi Jonathan,
> > > > 
> > > > What needs to be detected here is the inability to send and 
> > > > receive signaling messages to and from your RSVP peer. In this 
> > > > respect, using RSVP Hello is a more accurate mechanism for 
> > > > detecting failures since it is part of the RSVP protocol and 
> > > > independent of the link layer used to realize the control 
> > > > channel. As you point out, if you prefer redundant control 
> > > > channels for resiliency, and want to rely on LMP only, you have
> > > > to correlate all LMP detected failures in order to declare a 
> > > > control channel failure.
> > > This is not correct.  LMP allows you to detect individual 
> > > control channel
> > > failures, even when there are multiple (redundant) control 
> > > channels.  The
> > > RSVP Hello cannot do this.
> > > 
> > 
> > Sure, as I pointed above, RSVP Hello is not intended to detect 
> > individual link failures. At the risk of sounding repetitive, the
> > point here is that these are different mechanisms that serve 
> > different purpose. For example, if you have 3 (redundant) 
> IP control 
> > channels and rely on LMP Hello only, in order to infer 
> failure of the 
> > signaling channel with your peer, you would have to correlate LMP 
> > failures in all three channels. 
> > 
> > > > With RSVP Hello you would rely on a 
> > > > single set of event(s) to detect the failure.
> > > To be clear, the failure of the RSVP module.
> > 
> > Or simultaneous failure of all IP control channels...
> > 
> > > 
> > > > To go even further, what if all your control channels 
> are working
> > > > fine, but your RSVP daemon has crashed, for whatever reason.
> > > > LMP hellos will keep going across but RSVP messages will not...
> > > This is where the RSVP Hello has its place.
> > > 
> > > > 
> > > > All this points to the (certainly non-trivial) problem 
> of failure 
> > > > detection and correlation at different layers. I am not 
> trying to
> > > > say that RSVP Hello is the perfect or only mechanism we 
> > should rely 
> > > > on, but it certainly has a place in addressing the problem.
> > > agreed.  see above comment.
> > > 
> > > > 
> > > > Thanks,
> > > > Dimitris
> > > > 
> > > > PS. Hopefully we are not too far apart so we might not have
> > > > to keep the discussion going for too long :-)
> > > > In any case I believe it has some relevance here as well.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: Friday, May 25, 2001 6:56 PM
> > > > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong 
> Liaw'; 'suresh
> > > > > Katukam'; [email-masked]
> > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > Subject: RE: Last call - RSVP problems
> > > > > 
> > > > > 
> > > > > Dimitris,
> > > > >   The RSVP Hello Extension is intended to detect node 
> > > > failures and not
> > > > > necessarily link (control channel) failures.  In particular, 
> > > > > the tunnel
> > > > > draft says, "It should be noted that node failure detection 
> > > > > is not the same
> > > > > as a link failure detection mechanism, particularly in the 
> > > > > case of multiple
> > > > > parallel unnumbered links."  What happens if you want 
> > > > > redundant control
> > > > > channels for control-channel resiliency?  I believe you would 
> > > > > still want a
> > > > > mechanism to detect control channel (link-layer) failures.
> > > > > 
> > > > >   In LMP, you can have multiple active control channels 
> > > > > between a pair of
> > > > > nodes.  You can configure control channels over shared 
> > > > > Ethernet and over
> > > > > SONET/SDH overhead, etc.  You send keep-alive Hellos over 
> > > > each control
> > > > > channel.  If you so desire, you can send all signaling 
> > > > > messages over the
> > > > > Ethernet control channels.  You can also choose to send all 
> > > > > remaining LMP
> > > > > messages over the SONET/SDH-based control channels.  Keeping 
> > > > > RSVP Hellos as
> > > > > "optional" would be fine.  Making them mandatory doesn't seem 
> > > > > like the right
> > > > > solution.
> > > > > 
> > > > > Thanks,
> > > > > Jonathan
> > > > > 
> > > > > P.S.  Should we move this discussion on the OIF list??
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > > > > > Sent: Friday, May 25, 2001 3:16 PM
> > > > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; 
> > > > > [email-masked]
> > > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > > Subject: RE: Last call - RSVP problems
> > > > > > 
> > > > > > 
> > > > > > Hi Jonathan,
> > > > > > 
> > > > > > One point to consider is that the signaling control 
> > > > > > channel might be realized over a different link layer 
> > > > > > than LMP. For example, LMP might be running in-fiber
> > > > > > over SONET/SDH overhead bytes, while RSVP is running 
> > > > > > over an out-of-band network such a shared Ethernet.
> > > > > > RSVP Hello allows independent detection of signaling 
> > > > > > channel failure, so it's a useful option to keep.
> > > > > > 
> > > > > > Thanks,
> > > > > > Dimitris
> > > > > > 
> > > > > > Dimitris Pendarakis
> > > > > > Tellium, Inc.
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > > > Sent: Friday, May 25, 2001 5:30 PM
> > > > > > > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > > > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > > > Subject: RE: Last call - RSVP problems
> > > > > > > 
> > > > > > > 
> > > > > > > Fong,
> > > > > > > 
> > > > > > > 
> > > > > > > <snip>
> > > > > > > > Same as (2), any proposals that remove the refresh 
> > > mechanism 
> > > > > > > > is going to be difficult to prove that all cases 
> > > are covered.
> > > > > > > > 
> > > > > > > > Instead, we (will) recommend the following in OIF UNI 
> > > > document:
> > > > > > > >    
> > > > > > > >    Use RSVP Hello to detect control channel failure.
> > > > > > > Why wouldn't you use the LMP Hello to detect 
> > control channel 
> > > > > > > failure?  This
> > > > > > > is exactly what it is designed for.  From 
> > > > > > > draft-ietf-mpls-lsp-tunnel-08.txt,
> > > > > > > 
> > > > > > >   "This (RSVP Hello) mechanism is intended to be 
> used when 
> > > > > > > notification of
> > > > > > > link layer
> > > > > > >    failures is not available and unnumbered links are not 
> > > > > > > used, or when
> > > > > > >    the failure detection mechanisms provided by the link 
> > > > > > layer are not
> > > > > > >    sufficient for timely node failure detection."
> > > > > > >  
> > > > > > > >    If a control channel failure is detected, 
> LSPs states 
> > > > > > > >    are maintained as if a node continues to receive 
> > > > > > > >    RSVP refresh message from the failed control channel.
> > > > > > > >    The recommended Hello timer will be in second range,
> > > > > > > >    instead of ms range specified in RSVP-TE draft.  
> > > > > > > > 
> > > > > > > >    If a control channel failed permanently, manual 
> > > > intervention 
> > > > > > > >    may be required. This is to be studied.
> > > > > > > > 
> > > > > > > > p.s The text is currently being drafted as we type.
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Delivery-date: Fri, 01 Jun 2001 01:27:31 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Fri, 1 Jun 2001 10:18:30 +0200 

Hello Tony

>Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
>is the point I have been trying to make all along. 

To be more precise, arbitrary concatenation won't work over SONET/SDH nodes
that don't implement it, whatever there is a control plane or not. Arbitray
concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's,
TM's, etc... Folks didn't wait for a control plane to implement it.

Kind regards,

Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 01, 2001 9:33 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Sorry,

Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
is the point I have been trying to make all along. 

Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not.

Tony

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: 30 May 2001 15:45
To: 'Zhi-Wei Lin'; John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I didn't say that, and I don't think that it is true.

It is my understanding that if there was a set of SONET/SDH pipes between a
pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
those pipes however they wished as long as they were consistent with
SONET/SDH
transport protocols and the non-GMPLS nodes wouldn't need to understand what
they were doing.

I think that this is exactly the same situation as virtual concatenation,
where
the endpoints are upgraded without disturbing the intermediate equipment.  

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 7:32 AM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

Yes I agree. As long as the GMPLS nodes are consistent with the
non-GMPLS cloud, then there is no interop issue. 

As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
would also need to support this. Then it not only impacts new equipment,
but also require upgrades to embedded equipment as well for this to
work?

Zhi

John Drake wrote:
> 
> Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> interacting with the GMPLS
> nodes wrt signalling.  This means that the links between the GMPLS nodes
at
> the edges of the non-GMPLS cloud
> are pre-configured SONET/SDH pipes.  This also means that as long as what
> the GMPLS nodes are doing
> with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> arbitrary concat, then there
> is no interoperability issue.
> 
> I think that this is the point that Eric has been making, which has tended
> to get lost in the noise.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the
capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't
require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes,
it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the
scope
> > of the IETF to define - so this keeps us more in line with (in this
case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important
to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the
current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Fri, 01 Jun 2001 00:44:01 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Fri, 1 Jun 2001 08:32:44 +0100 

Sorry,

Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
is the point I have been trying to make all along. 

Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not.

Tony

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: 30 May 2001 15:45
To: 'Zhi-Wei Lin'; John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I didn't say that, and I don't think that it is true.

It is my understanding that if there was a set of SONET/SDH pipes between a
pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
those pipes however they wished as long as they were consistent with
SONET/SDH
transport protocols and the non-GMPLS nodes wouldn't need to understand what
they were doing.

I think that this is exactly the same situation as virtual concatenation,
where
the endpoints are upgraded without disturbing the intermediate equipment.  

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 7:32 AM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

Yes I agree. As long as the GMPLS nodes are consistent with the
non-GMPLS cloud, then there is no interop issue. 

As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
would also need to support this. Then it not only impacts new equipment,
but also require upgrades to embedded equipment as well for this to
work?

Zhi

John Drake wrote:
> 
> Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> interacting with the GMPLS
> nodes wrt signalling.  This means that the links between the GMPLS nodes
at
> the edges of the non-GMPLS cloud
> are pre-configured SONET/SDH pipes.  This also means that as long as what
> the GMPLS nodes are doing
> with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> arbitrary concat, then there
> is no interoperability issue.
> 
> I think that this is the point that Eric has been making, which has tended
> to get lost in the noise.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the
capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't
require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes,
it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the
scope
> > of the IETF to define - so this keeps us more in line with (in this
case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important
to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the
current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob