Subject: Re: draft-lee-mpls-path-request
From: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 Jan 2002 13:49:01 EST

Jeff,
Thanks for your feedback. Comments inline.

regards
cheng-yin

Jeff Pickering wrote:

> cheng-yin,
>
> I have a couple questions/comments on your draft:
>
> 1) The reference to [OSPF-TE-EXT] used in the resource class definition
>     is not in the reference list.
> 2) It would seem reasonable to deploy PCE capability inside ABRs and
>     let the IGP instance in the LER determine how to find/recurse PCEs
> to
>     make a complete ER. I think this is what the document means,
but its
> not
>     clear.

Yes, this is what it means. The LERs and LSRs would know where the ABRs are.

> On the other hand, the draft-ash-multi-area-te-reqmts seems
> to
>     state that your idea requires out-of-band signaling to locate
PCEs.
> I'm
>     confused, can you clarify?

You may be referring to draft-lee-mpls-te-exchange which allows non ABRs to be PCE as well.

> 3) It would be nice to explicitly state how a "no ER available" is
> returned by
>     a path reply.

Will do.

> 4) I presume the disjoint route tlv is used to retry after LSP
setup
> failure. It would
>     help clarity if something to this effect was put in the text.

The disjoint route tlv is used to specify that the path to be computed
should be disjoint from the specified disjoint route tlv (not necessarily
after an LSP setup failure). We'll add more clarification as you suggest.

>
> Cheers,
> Jeff

Delivery-date: Thu, 31 Jan 2002 08:36:27 -0800
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>
Cc: <[email-masked]>
Subject: FW: Label Set and Suggested Label
Date: Thu, 31 Jan 2002 11:31:35 -0500

Manoj,

While some of the questions you raise are valid, there were at
least a couple that seem contradictory, and didn't seem to be
stated clearly enough for one to respond to them.

Anyway, here are some thoughts.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of manoj juneja
>Sent: Wednesday, January 30, 2002 7:33 PM
>To: [email-masked]
>Subject: Label Set and Suggested Label
>
>
>Hi All,
>        The GMPLS drafts specify the use of suggested label and label
>set in a very generic way. These are not mentioned based on specific
>technology.
>
>The following question comes to mind while reading the draft.
>
>Whether the suggested label and label set are going to be used in
>SDH/SONET
>?

The suggested label and label set are provided for use by all
of the technologies that GMPLS covers (packet, TDM, lambda, fiber).
So, yes, they *can* be used by SDH/SONET. Whether a particular
vendor will "use" them, and whether a particular carrier will
turn them on, even if the vendor code incorporates them, will
depend on the specific vendor or carrier.

So, strictly speaking, the answer to whether they *are* going
to be used is "it depends on the vendor or carrier."

>The OIF's O-UNI v 1.0 is applicable for establishing SDH/SONET LSPs. They
>don't use the suggested label at all. Regarding the usage of label set, it
>mentions that if a node wants the upstream and downstream labels
>to be same
>in both the directions then the upstream label should be included in the
>label set. Is GMPLS looking for the this type of usage for label set in
>SDH/SONET LSPs ?

Again, the type of usage outlined in the OIF-UNI is one way in
which the label set may be used. The GMPLS documents, as they
stand, do not mandate or restrict how the label set should
be used.

Your question is quite unclear here. If you mean "can this be a possible
usage for label set in GMPLS" the answer is "yes." If you mean
"is this the only usage for label set in GMPLS for SDH/SONET", the answer
is "no."

>Can I have a action field indicating range (include/exclude) in label set
>for SDH/SONET LSPs ?

This is another one of the confusing questions. Do you mean
can you use the "Action" field specified for the label set
when using the label set with SDH/SONET labels?
Well, yes. The label set format is common to all technologies,
and was designed so that its features were such that all
technologies (including SDH/SONET) covered by GMPLS could
use them.
So unless I'm missing something, I don't see the point of confusion
here.

>What is the reason for including the SDH/SONET list of labels
>(include/exclude) for SDH/SONET LSPs ?

Again, not clear in the light of the previous question. Based
on your previous question, I would surmise that you had some
need to actually use the "Action" and range concepts for SDH/SONET
and simply need to verify whether they could be used with SDH/SONET.
In that case, you should already have an application in mind.

A very simple application for specifying a range might be when
an upstream node wishes to use some form of concatenation to bind
certain SDH/SONET channels together, and wishes to inform the
downstream node of the specific channels to be bound.

>I can understand the usage of suggested label/label set on LSC interfaces.
>
>Please don't give answers like GMPLS is a generic framework and O-UNI is a
>sub-set of GMPLS or label set/suggested label is a carrier requirement.

Please, also invest some time and thought in framing your questions
more clearly.
This will go a long way in enabling people to answer them.

Thanks,
-Vishal

Delivery-date: Thu, 31 Jan 2002 06:45:11 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-03.txt
Date: Tue, 29 Jan 2002 07:42:05 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-03.txt
	Pages		: 9
	Date		: 28-Jan-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS).  The description of the extensions is specified in [GMPLS-
ROUTING].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-ospf-gmpls-extensions-03.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-ietf-ccamp-ospf-gmpls-extensions-03.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-ietf-ccamp-ospf-gmpls-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-03.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, 30 Jan 2002 16:35:12 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Label Set and Suggested Label
Date: Wed, 30 Jan 2002 17:33:02 -0700

Hi All,
        The GMPLS drafts specify the use of suggested label and label
set in a very generic way. These are not mentioned based on specific 
technology.

The following question comes to mind while reading the draft.

Whether the suggested label and label set are going to be used in SDH/SONET 
?

The OIF's O-UNI v 1.0 is applicable for establishing SDH/SONET LSPs. They 
don't use the suggested label at all. Regarding the usage of label set, it 
mentions that if a node wants the upstream and downstream labels to be same 
in both the directions then the upstream label should be included in the 
label set. Is GMPLS looking for the this type of usage for label set in 
SDH/SONET LSPs ?

Can I have a action field indicating range (include/exclude) in label set 
for SDH/SONET LSPs ?

What is the reason for including the SDH/SONET list of labels 
(include/exclude) for SDH/SONET LSPs ?

I can understand the usage of suggested label/label set on LSC interfaces.

Please don't give answers like GMPLS is a generic framework and O-UNI is a 
sub-set of GMPLS or label set/suggested label is a carrier requirement.

Please clarify.

Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Wed, 30 Jan 2002 07:42:35 -0800
From: "Bhargava, Nidhi" <[email-masked]>
To: [email-masked]
Subject: LMP Questions regarding data link FSM.
Date: Wed, 30 Jan 2002 10:39:09 -0500

Hi all
In the draft-ietf-ccamp-lmp-02.txt, section 12.3.2.Data Link Events, the
event evSummaryFail
is suppose to make Data link transition from up/free state to down state.
But no event has been
specified for the data link to move to up/free state from down state during
link property exchange.

The event 5 does this job when the verification is completed or if
verification is not supported. But the 
case where verification hasn't yet been tried (exchanging of link summary),
there is no event to transition
to up/free state.

What will be the state of the data links after the local node has sent the
link summary and waiting for
ack? What will be the state of data links if local and peer nodes support
verification, have already exchanged
link summary but are not yet ready for verification procedure?.

Thanks
Nidhi
-------------------------------
Nidhi Bhargava
NetPlane Systems Inc.
A Mindspeed Technologies Company
Tel:   + 1.781.329.3200 x5353
Web:   http://www.netplane.com

Delivery-date: Tue, 29 Jan 2002 14:48:44 -0800
Date: Tue, 29 Jan 2002 14:47:55 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Randy Bush <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, Cheenu Srinivasan <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates

On Sat, 26 Jan 2002, Randy Bush wrote:

> > If the MIBs are GMPLS specific
> 
> then why are they in the COMMON control and measurement wg?

GMPLS-specific is a misnomer -- non-(MPLS-specific) [i.e., generic]
is probably what was meant.  More accurately: "If the MIBs contain
just the deltas to the MPLS MIBs to make them generalized ...".

"Generalized MPLS"-specific is a cute oxymoron.  

Kireeti.

Delivery-date: Tue, 29 Jan 2002 14:46:14 -0800
Date: Tue, 29 Jan 2002 14:39:46 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: "Thomas D. Nadeau" <[email-masked]>, Cheenu Srinivasan <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates

On Sat, 26 Jan 2002, Wijnen, Bert (Bert) wrote:

> >          I don't see the new MIBs as obsoleting the v1 MIBs.
> > The existing MPLS MIBs will continue to be perfectly
> > valid for existing implementations, as well as future ones that do not
> > want to have anything to do with GMPLS.

Speaking as an implementor, I would prefer that these MIBs *do*
obsolete the v1 MIBs.  That doesn't mean that the v1 MIBs should
be thrown away, just that (perhaps) they could be experimental instead
of PS (repeat: the above comment is *not* as a WG chair).

> >          The new v2 MIBs need to support the new GMPLS functions
> > as well as existing MPLS functions (since GMPLS is based on MPLS),
> > and I think there is sufficient reason for to stand on their own
> > while leaving the first versions of these MIBs as RFCs.
> > 
> OK, that sounds plausible.

> BUT......
> 
> Then I think you should try and duplicate as few objects from the old
> MPLS MIBs as possible. So only new stuff that is needed should be in
> the GMPLS MIBs. If Someone needs both MPLS and GMPLS MIB funcrtionality,
> they then implement both the MPLS MIBs and the GMPLS MIBs.
> 
> I think that that means that you should not consider them as version2 
> of the MPLS MIBs, but as MIBs that provide GMPLS function only.

I agree.  If the v2 MIBs provide minimum overlap, then they are
not really v2, and there is no need to obsolete the v1 MIBs (in fact,
one couldn't do that).  If the v2 MIBs are (for whatever SNMP-technical
reason) full, stand-on-their-own MIBs, then let's consider making the
v1 MIBs experimental or whatever.

I leave the naming of the MIBs to the SNMP experts.  The WG, however,
should be CCAMP.

Kireeti.

Delivery-date: Tue, 29 Jan 2002 14:29:21 -0800
Date: Tue, 29 Jan 2002 14:25:59 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Maarten Vissers <[email-masked]>
cc: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: Material for discussion on protection switching

On Mon, 28 Jan 2002, Maarten Vissers wrote:

> ITU-T SG15 is developing a new recommendation on generic aspects of
> protection switching (G.gps).

Thanks, Maarten!  This is very good material, and very relevant
to CCAMP.

Kireeti.

Delivery-date: Tue, 29 Jan 2002 04:46:29 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-03.txt
Date: Tue, 29 Jan 2002 07:42:05 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-03.txt
	Pages		: 9
	Date		: 28-Jan-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS).  The description of the extensions is specified in [GMPLS-
ROUTING].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-ospf-gmpls-extensions-03.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-ietf-ccamp-ospf-gmpls-extensions-03.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-ietf-ccamp-ospf-gmpls-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 28 Jan 2002 01:11:42 -0800
Date: Mon, 28 Jan 2002 10:07:35 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Material for discussion on protection switching

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

ITU-T SG15 is developing a new recommendation on generic aspects of protection
switching (G.gps). The first draft is available for use in e.g. the work on
support of transport plane protection switching in GMPLS. You will find a copy
of this G.gps at the URL below.

Regards,

Maarten

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_gps.html
--------------90D9A88BB18DCD2EB7B6CE10
Content-Type: text/html; charset=us-ascii;
 name="IETF_ccamp_gps.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="IETF_ccamp_gps.html"
Content-Base: "ftp://sg15opticalt:[email-masked]
	nt/tsg15opticaltransport/COMMUNICAT
	IONS/ccamp/IETF_ccamp_gps.html"
Content-Location: "ftp://sg15opticalt:[email-masked]
	nt/tsg15opticaltransport/COMMUNICAT
	IONS/ccamp/IETF_ccamp_gps.html"

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U) [Netscape]">
   <meta name="Author" content="Stephen Trowbridge">
   <title>Material for Discussion of Virtual Backplane Interface (VBI)</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#009CFF" vlink="#0099FF" alink="#009CFF">
&nbsp;
<table BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" HEIGHT="43" BGCOLOR="#0099FF" bordercolor="#FFFFFF" >
<tr>
<td VALIGN=TOP WIDTH="50%" HEIGHT="37" BGCOLOR="#000066" bordercolor="#FFFFFF"><img SRC="../itu_t-105.gif" BORDER=0 height=46 width=105 align=ABSCENTER><img SRC="../itu.gif" height=20 width=360></td>
</tr>
</table>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="701" HEIGHT="1" >
<tr>
<td WIDTH="105" HEIGHT="1" BGCOLOR="#0099FF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">
<div style="word-spacing: 0; line-height: 100%; text-indent: 0; margin: 0"><img SRC="../itubl_b-105.gif" BORDER=0 height=46 width=105></div>
</td>

<td COLSPAN="2" WIDTH="592" HEIGHT="1" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>
</tr>

<tr>
<td WIDTH="105" HEIGHT="1" BGCOLOR="#0099FF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td WIDTH="19" HEIGHT="1" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td WIDTH="573" HEIGHT="1" BGCOLOR="#0099FF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF"><b><font color="#FFFFFF">&nbsp;ITU-T&nbsp;
Study Group 15 (Study Period 2001 - 2004)</font></b>
<br><b><font color="#FFFFFF">&nbsp;Draft Recommendations under Development</font></b></td>
</tr>

<tr>
<td ALIGN=LEFT VALIGN=TOP WIDTH="105" HEIGHT="22" BGCOLOR="#009CFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td COLSPAN="2"></td>
</tr>

<tr>
<td ALIGN=LEFT VALIGN=TOP WIDTH="105" HEIGHT="22" BGCOLOR="#0099FF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td ALIGN=LEFT VALIGN=TOP WIDTH="19" HEIGHT="22" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td ALIGN=LEFT VALIGN=TOP WIDTH="573" HEIGHT="22" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">
<div style="word-spacing: 0; line-height: 100%; text-indent: 0; margin: 0"><b><font color="#FF0000"><font size=-1>These
documents are drafts of Recommendations Under Development by ITU-T Study
Group 15. While they represent the current working view of the questions
under which they are developed, work is ongoing and the content may change
at any time prior to approval.</font></font></b></div>
</td>
</tr>

<tr>
<td WIDTH="105" HEIGHT="22" BGCOLOR="#009CFF">&nbsp;</td>

<td COLSPAN="2"></td>
</tr>

<tr>
<td ALIGN=LEFT VALIGN=TOP WIDTH="105" HEIGHT="266" BGCOLOR="#0099FF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>&nbsp;</td>

<td ALIGN=LEFT VALIGN=TOP WIDTH="19" HEIGHT="266" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">&nbsp;</td>

<td ALIGN=LEFT VALIGN=TOP WIDTH="573" HEIGHT="266" BGCOLOR="#FFFFFF" bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#FFFFFF">
<table BORDER WIDTH="100%" >
<tr BGCOLOR="#009CFF">
<td>
<center><b><font color="#FFFFFF">Number</font></b></center>
</td>

<td>
<center><b><font color="#FFFFFF">Title</font></b></center>
</td>

<td>
<center><b><font color="#FFFFFF">Download</font></b></center>
</td>
</tr>

<tr>
<td><font face="Times New Roman,Times">G.gps</font></td>

<td><font face="Times New Roman,Times">Generic Protection Switching</font></td>

<td BGCOLOR="#009CFF">
<center><a href="ggps-v01-0110.pdf"><img SRC="../pdf.gif" height=16 width=16 align=ABSCENTER></a><a href="ggps-v01-0110.doc"><img SRC="../msw8.gif" height=16 width=16 align=ABSCENTER></a></center>
</td>
</tr>
</table>

<p><font face="Times New Roman,Times"><a href="http://www.itu.int/home/copyright/index.html">Copyright
Notice</a></font>
<p><font face="Arial,Helvetica"><font size=-1>Contact: <a href="mailto:[email-masked]">Ghani
Abbas</a></font></font></td>
</tr>
</table>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="99%" >
<tr>
<td><img SRC="../blueline.gif" height=1 width=100%></td>
</tr>
</table>

</body>
</html>

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

--------------90D9A88BB18DCD2EB7B6CE10--

Delivery-date: Sat, 26 Jan 2002 07:31:31 -0800
Date: Sat, 26 Jan 2002 10:27:03 -0500
To: Randy Bush <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: GMPLS MIB I-D updates
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Cheenu Srinivasan <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]

> > If the MIBs are GMPLS specific
>
>then why are they in the COMMON control and measurement wg?

         I thought that it was decided that all GMPLS extensions to
MPLS were to be done in CCAMP.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Sat, 26 Jan 2002 07:21:18 -0800
From: Randy Bush <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Cheenu Srinivasan <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates
Date: Sat, 26 Jan 2002 07:17:06 -0800

> If the MIBs are GMPLS specific

then why are they in the COMMON control and measurement wg?

randy

Delivery-date: Sat, 26 Jan 2002 06:11:23 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: Cheenu Srinivasan <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates
Date: Sat, 26 Jan 2002 15:06:22 +0100

> >So that to means you will obsolete the MPLS MIBs at that time.
> >And tat means you recycle at Proposed Standard.
> >So maybe you are to quick trying to get the current set of MPLS
> >MIBs approved as PS?
> 
>          I don't see the new MIBs as obsoleting the v1 MIBs.
> The existing MPLS MIBs will continue to be perfectly
> valid for existing implementations, as well as future ones that do not
> want to have anything to do with GMPLS. These MIBs have been around
> for over 3 years now, and are fully cooked for "classic" MPLS. There
> are many implementations that support them. Disregarding them now so
> that we can wait for GMPLS-related functions will delay them 
> for several more years. The vendors and operators that I work and 
> interact with want the existing MPLS MIBs to become RFCs ASAP.
> 
>          The new v2 MIBs need to support the new GMPLS functions
> as well as existing MPLS functions (since GMPLS is based on MPLS),
> and I think there is sufficient reason for to stand on their own
> while leaving the first versions of these MIBs as RFCs.
> 
OK, that sounds plausible. 

BUT......

Then I think you should try and duplicate as few objects from the old
MPLS MIBs as possible. So only new stuff that is needed should be in
the GMPLS MIBs. If Someone needs both MPLS and GMPLS MIB funcrtionality,
they then implement both the MPLS MIBs and the GMPLS MIBs.

I think that that means that you should not consider them as version2 
of the MPLS MIBs, but as MIBs that provide GMPLS function only.

Bert
>          --tom
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

Delivery-date: Fri, 25 Jan 2002 20:50:38 -0800
Date: Fri, 25 Jan 2002 23:46:31 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: GMPLS MIB I-D updates
Cc: Cheenu Srinivasan <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]

At 12:51 AM 1/26/2002 +0100, Wijnen, Bert (Bert) wrote:
> > > > 2. We believe CCAMP is the appropriate place to continue this
> > > >    work since the extensions are completely GMPLS related. This was
> > > >    discussed in Salt Lake City and (we thought) agreed upon but
> > > >    we would like to hear the chairs'/AD's word on this.
> > > >
> > >If the MIBs are GMPLS specific, in which case they would
> > >probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> > >then they may belong in CCAMP. If they are changing (i.e.
> > >just repeating and adding new objects) the base tables in the
> > >MPLS MIBs, then it seems to me that they may also belong in the
> > >MPLS WG. I'd like to hear from author how they want to approach
> > >adding GMPLS management objects to the MPLS MIBs. Then I want
> > >to hear from WG chairs how they are reading consensus on what
> > >to do and where to do it.
> >
> >          The AUGMENTS approach was originally thought though
> > (I think that we sent you email on this, but maybe not). The
> > conclusion was to not AUGMENT the existing MIBs because the
> > indexing of many of the existing tables used the MPLS label. Since
> > GMPLS allows for labels of much greater length, we could not
> > use this approach, and thus decided to write new tables that
> > were as close as the old ones as possible so as to preserve existing
> > implementations, but to also facilitate GMPLS functions (existing and
> > future).
> >
>So that to means you will obsolete the MPLS MIBs at that time.
>And tat means you recycle at Proposed Standard.
>So maybe you are to quick trying to get the current set of MPLS
>MIBs approved as PS?

         I don't see the new MIBs as obsoleting the v1 MIBs.
The existing MPLS MIBs will continue to be perfectly
valid for existing implementations, as well as future ones that do not
want to have anything to do with GMPLS. These MIBs have been around
for over 3 years now, and are fully cooked for "classic" MPLS. There
are many implementations that support them. Disregarding them now so
that we can wait for GMPLS-related functions will delay them for several
more years. The vendors and operators that I work and interact with
want the existing MPLS MIBs to become RFCs ASAP.

         The new v2 MIBs need to support the new GMPLS functions
as well as existing MPLS functions (since GMPLS is based on MPLS),
and I think there is sufficient reason for to stand on their own
while leaving the first versions of these MIBs as RFCs.

         --tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Fri, 25 Jan 2002 15:54:41 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: Cheenu Srinivasan <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates
Date: Sat, 26 Jan 2002 00:51:43 +0100

> > > 2. We believe CCAMP is the appropriate place to continue this
> > >    work since the extensions are completely GMPLS related. This was
> > >    discussed in Salt Lake City and (we thought) agreed upon but
> > >    we would like to hear the chairs'/AD's word on this.
> > >
> >If the MIBs are GMPLS specific, in which case they would
> >probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> >then they may belong in CCAMP. If they are changing (i.e.
> >just repeating and adding new objects) the base tables in the
> >MPLS MIBs, then it seems to me that they may also belong in the
> >MPLS WG. I'd like to hear from author how they want to approach
> >adding GMPLS management objects to the MPLS MIBs. Then I want
> >to hear from WG chairs how they are reading consensus on what
> >to do and where to do it.
> 
>          The AUGMENTS approach was originally thought though
> (I think that we sent you email on this, but maybe not). The
> conclusion was to not AUGMENT the existing MIBs because the
> indexing of many of the existing tables used the MPLS label. Since
> GMPLS allows for labels of much greater length, we could not
> use this approach, and thus decided to write new tables that
> were as close as the old ones as possible so as to preserve existing
> implementations, but to also facilitate GMPLS functions (existing and
> future).
> 
So that to means you will obsolete the MPLS MIBs at that time.
And tat means you recycle at Proposed Standard.
So maybe you are to quick trying to get the current set of MPLS
MIBs approved as PS?

Bert

Delivery-date: Fri, 25 Jan 2002 10:28:40 -0800
Date: Fri, 25 Jan 2002 13:24:09 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: GMPLS MIB I-D updates
Cc: Cheenu Srinivasan <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]

At 05:18 PM 1/25/2002 +0100, Wijnen, Bert (Bert) wrote:
>Inline
> > -----Original Message-----
> > From: Cheenu Srinivasan [mailto:[email-masked]]
> > Sent: Friday, January 25, 2002 4:22 PM
> > To: Thomas D. Nadeau; Wijnen, Bert (Bert)
> > Cc: Joan Cucchiara; [email-masked]; Kireeti Kompella; Vijay Gill;
> > [email-masked]
> > Subject: RE: GMPLS MIB I-D updates
> >
> > Just to reiterate the authors' view:
> >
> > 1. We can change the MIB/doc name to whatever the WG/chairs/ADs think
> >    is appropriate.
> >
>You can change the docname to whatever you want.
>You can even change the MIB name to whatever you want.
>But if you want this document to be a ever considered for standards
>track, then you better follow the rules as outlined in RFC2578 on
>how you can extend MIB Modules.
>
>And even if you claim that this is just a GMPLS MIB and then
>when I find a lot of duplictae/overlapping information, even then
>it will not go on the standards track. I am quite convinced that I
>can convince my IESG collegues to not approve.
>
>Sorry of this sounds too managerial... but your remark above seems
>to sound as if you have all the authority to decide on this.
>
>Bert, speaking as AD.

         That wasn't the idea, sorry if it sounded that way. The point
was that we will change the name to whatever is necessary to get
this work moving forward.   We will use the v2 approach as you
suggested. The only question now is which WG to put these into:
CCAMP or MPLS (see below).

> > 2. We believe CCAMP is the appropriate place to continue this
> >    work since the extensions are completely GMPLS related. This was
> >    discussed in Salt Lake City and (we thought) agreed upon but
> >    we would like to hear the chairs'/AD's word on this.
> >
>If the MIBs are GMPLS specific, in which case they would
>probably conatin a set of AUGMENTing tables to the MPLS MIBs,
>then they may belong in CCAMP. If they are changing (i.e.
>just repeating and adding new objects) the base tables in the
>MPLS MIBs, then it seems to me that they may also belong in the
>MPLS WG. I'd like to hear from author how they want to approach
>adding GMPLS management objects to the MPLS MIBs. Then I want
>to hear from WG chairs how they are reading consensus on what
>to do and where to do it.

         The AUGMENTS approach was originally thought though
(I think that we sent you email on this, but maybe not). The
conclusion was to not AUGMENT the existing MIBs because the
indexing of many of the existing tables used the MPLS label. Since
GMPLS allows for labels of much greater length, we could not
use this approach, and thus decided to write new tables that
were as close as the old ones as possible so as to preserve existing
implementations, but to also facilitate GMPLS functions (existing and
future).

         --Tom

>Bert, again speaking as AD
>
> > 3. We request that these be adopted as WG documents; shortly
> >    thereafter we will reissue them under the correct MIB and document
> >    names.
> >
> > Thanks,
> > Cheenu
> >
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:[email-masked]]
> > > Sent: Friday, January 25, 2002 9:50 AM
> > > To: Wijnen, Bert (Bert)
> > > Cc: Joan Cucchiara; Cheenu Srinivasan; [email-masked]; Kireeti
> > > Kompella; Vijay Gill; [email-masked]
> > > Subject: RE: GMPLS MIB I-D updates
> > >
> > >
> > >
> > >          Hi,
> > >
> > > >Thanks for the posting.
> > > >I have not yet looked at these new MIBs.
> > > >If they are indeed updates or enhancements to the MPLS versions,
> > > >then they should follow the rules/guidelines that we have for
> > > >updating MIB Modules as outlined in RFC2578.
> > >
> > >          The question of what to name the documents is up
> > > to the WG; the co-authors are indifferent on this issue.
> > > Just some background.  The state of the GMPLS MIBs is that they
> > > do indeed extend existing  MPLS MIBs  to facilitate new GMPLS
> > > functions. Specifically, they have been modified to
> > > accommodate longer labels, and a few other things.
> > > However, in the future, additional modifications, features
> > > and functions
> > > may be added that are GMPLS-specific.
> > >
> > > >That is independent of the question of which WG does the work.
> > >
> > >          As I recall, the question of where this work is to be done
> > > was already discussed and decided that it would happen in
> > > CCAMP. However, the ADs, George and Kareeti might want to
> > > verify this for us all. The co-authors are agnostic as to
> > > where the work
> > > gets done; however, the point raised above about the MIBs
> > potentially
> > > changing more for GMPLS-specifics might bias the work to be done
> > > in CCAMP. This is also why we chose the naming of the documents.
> > >
> > >          --Tom
> > >
> > >
> > >
> > > >Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: Joan Cucchiara [mailto:[email-masked]]
> > > > > Sent: Friday, January 25, 2002 1:43 AM
> > > > > To: Cheenu Srinivasan
> > > > > Cc: [email-masked]; Kireeti Kompella; Vijay Gill
> > > > > Subject: Re: GMPLS MIB I-D updates
> > > > >
> > > > >
> > > > >
> > > > > Hi Folks,
> > > > >
> > > > > I would like to raise 2 concerns with having this working
> > > > > group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka
> > > > > GMPLS-LSR-MIB)
> > > > > and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> > > > >
> > > > > 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> > > > > are updates to 2 of the MIBs in the MPLS working group,
> > > > > namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs
> > > > > should be proposed in the MPLS working group which is
> > where folks
> > > > > have experience in implementing and using them.  In my
> > opinion the
> > > > > additions for GMPLS to these MIBs is minor and it would
> > be better
> > > > > to stick with the MPLS working group for these MIBs.
> > > > >
> > > > > 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> > > > > GMPLS-TE-MIB,
> > > > > does not follow how the IETF names a new version of a MIB.
> > > > > The current trend in the IETF is to use the same name for
> > > > > the draft versions of an existing MIB and differentiate this
> > > > > with the draft title (and eventually a new RFC number).
> > > As examples:
> > > > >
> > > > > draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> > > > > draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> > > > > draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name:
> > > EtherLike-MIB
> > > > > draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> > > > > draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> > > > > and many others...
> > > > >
> > > > > My biggest concern is that the names of GMPLS-LSR-MIB and
> > > GMPLS-TE-MIB
> > > > > will be confusing and misleading to customers.  Could these be
> > > > > renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus,
> > accurately reflect
> > > > > what they are?
> > > > >
> > > > > thanks,
> > > > >  -Joan
> > > > >
> > > > > Cheenu Srinivasan wrote:
> > > > > >
> > > > > > We would like to request that these four I-Ds be
> > > adopted as CCAMP
> > > > > > working group documents.
> > > > > >
> > > > > > Thanks,
> > > > > > Tom, Cheenu, Adrian, Tim, Ed
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Cheenu Srinivasan
> > > > > > > Sent: Thursday, January 24, 2002 12:48 PM
> > > > > > > To: [email-masked]
> > > > > > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim
> > > > > Hall (E-mail);
> > > > > > > Ed Harrison (E-mail)
> > > > > > > Subject: GMPLS MIB I-D updates
> > > > > > >
> > > > > > >
> > > > > > > The following I-D updates have been posted:
> > > > > > >
> > > > > > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > > > > > >
> > > > > > > They are aligned with each other and have been verified to
> > > > > > > compile cleanly with smilint.
> > > > > > >
> > > > > > > They should appear on the IETF's site shortly. Copies are
> > > > > > > attached for your reference.
> > > > > > >
> > > > > > > Cheenu
> > > > > > >
> > > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> > >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Envelope-to: [email-masked]
Delivery-date: Fri, 25 Jan 2002 09:11:37 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: "Joan Cucchiara" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Vijay Gill" <[email-masked]>, <[email-masked]>
Subject: Re: GMPLS MIB I-D updates
Date: Fri, 25 Jan 2002 12:08:26 -0500

Thanks Bert,
I don't think Cheenu meant to suggest that the authors would decide, rather that
we would like to be guided by ADs/chairs and act accordingly.  You have now
guided us!

With regard to new/overlapping material.  We did go through the
augments/extends/replaces issue at the last couple of IETFs, but would be
pleased to revisit it.

In summary, there is a lot of material in the GMPLS MIBs that is "identical" to
that in the MPLS MIBs.  The intention so far has been to produce a 'version 2'
of the MPLS MIBs that can support MPLS on its own,  GMPLS on its own, or both at
once.  This v2 MIB would replace the existing MIB in implementations that were
interested in GMPLS and would be the base MIB for new implementations of MPLS or
GMPLS.  At the same time, a lot of thought has gone into easing the migration
path for existing implementations.

As always, we look for guidance and opinions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
[email-masked]
> > -----Original Message-----
> > From: Cheenu Srinivasan [mailto:[email-masked]]
> > Sent: Friday, January 25, 2002 4:22 PM
> > To: Thomas D. Nadeau; Wijnen, Bert (Bert)
> > Cc: Joan Cucchiara; [email-masked]; Kireeti Kompella; Vijay Gill;
> > [email-masked]
> > Subject: RE: GMPLS MIB I-D updates
> >
> > Just to reiterate the authors' view:
> >
> > 1. We can change the MIB/doc name to whatever the WG/chairs/ADs think
> >    is appropriate.
> >
> You can change the docname to whatever you want.
> You can even change the MIB name to whatever you want.
> But if you want this document to be a ever considered for standards
> track, then you better follow the rules as outlined in RFC2578 on
> how you can extend MIB Modules.
>
> And even if you claim that this is just a GMPLS MIB and then
> when I find a lot of duplictae/overlapping information, even then
> it will not go on the standards track. I am quite convinced that I
> can convince my IESG collegues to not approve.
>
> Sorry of this sounds too managerial... but your remark above seems
> to sound as if you have all the authority to decide on this.
>
> Bert, speaking as AD.
>
> > 2. We believe CCAMP is the appropriate place to continue this
> >    work since the extensions are completely GMPLS related. This was
> >    discussed in Salt Lake City and (we thought) agreed upon but
> >    we would like to hear the chairs'/AD's word on this.
> >
> If the MIBs are GMPLS specific, in which case they would
> probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> then they may belong in CCAMP. If they are changing (i.e.
> just repeating and adding new objects) the base tables in the
> MPLS MIBs, then it seems to me that they may also belong in the
> MPLS WG. I'd like to hear from author how they want to approach
> adding GMPLS management objects to the MPLS MIBs. Then I want
> to hear from WG chairs how they are reading consensus on what
> to do and where to do it.
>
> Bert, again speaking as AD

Delivery-date: Fri, 25 Jan 2002 09:03:04 -0800
Content-class: urn:content-classes:message
Subject: RE: GMPLS MIB I-D updates
Date: Fri, 25 Jan 2002 12:02:00 -0500
From: "Cheenu Srinivasan" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: "Joan Cucchiara" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Vijay Gill" <[email-masked]>, <[email-masked]>

Bert, Please see comments inline.

> > 1. We can change the MIB/doc name to whatever the=20
> WG/chairs/ADs think
> >    is appropriate.
> >=20
> You can change the docname to whatever you want.
> You can even change the MIB name to whatever you want.
> But if you want this document to be a ever considered for standards
> track, then you better follow the rules as outlined in RFC2578 on
> how you can extend MIB Modules.
>=20
> And even if you claim that this is just a GMPLS MIB and then
> when I find a lot of duplictae/overlapping information, even then
> it will not go on the standards track. I am quite convinced that I
> can convince my IESG collegues to not approve.
>=20
> Sorry of this sounds too managerial... but your remark above seems
> to sound as if you have all the authority to decide on this.
>=20
> Bert, speaking as AD.

You misread - I said we would change it to whatever the WG/chairs/ADs
think is appropriate, not what we (the authors) decide. We'll go
through 2578 and get bck to the list about this.

> > 2. We believe CCAMP is the appropriate place to continue this
> >    work since the extensions are completely GMPLS related. This was
> >    discussed in Salt Lake City and (we thought) agreed upon but
> >    we would like to hear the chairs'/AD's word on this.
> >=20
> If the MIBs are GMPLS specific, in which case they would=20
> probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> then they may belong in CCAMP. If they are changing (i.e.
> just repeating and adding new objects) the base tables in the
> MPLS MIBs, then it seems to me that they may also belong in the
> MPLS WG. I'd like to hear from author how they want to approach
> adding GMPLS management objects to the MPLS MIBs. Then I want
> to hear from WG chairs how they are reading consensus on what
> to do and where to do it.
>=20
> Bert, again speaking as AD

We tried the former approach (AUGMENTing the existing tables) but
this turned out to be really messy since there was a need to change
indexing and reorganize information. So, we took the latter approach.

Delivery-date: Fri, 25 Jan 2002 08:44:14 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Cheenu Srinivasan <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Joan Cucchiara <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates
Date: Fri, 25 Jan 2002 17:18:18 +0100

Inline
> -----Original Message-----
> From: Cheenu Srinivasan [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 4:22 PM
> To: Thomas D. Nadeau; Wijnen, Bert (Bert)
> Cc: Joan Cucchiara; [email-masked]; Kireeti Kompella; Vijay Gill;
> [email-masked]
> Subject: RE: GMPLS MIB I-D updates
> 
> Just to reiterate the authors' view:
> 
> 1. We can change the MIB/doc name to whatever the WG/chairs/ADs think
>    is appropriate.
> 
You can change the docname to whatever you want.
You can even change the MIB name to whatever you want.
But if you want this document to be a ever considered for standards
track, then you better follow the rules as outlined in RFC2578 on
how you can extend MIB Modules.

And even if you claim that this is just a GMPLS MIB and then
when I find a lot of duplictae/overlapping information, even then
it will not go on the standards track. I am quite convinced that I
can convince my IESG collegues to not approve.

Sorry of this sounds too managerial... but your remark above seems
to sound as if you have all the authority to decide on this.

Bert, speaking as AD.

> 2. We believe CCAMP is the appropriate place to continue this
>    work since the extensions are completely GMPLS related. This was
>    discussed in Salt Lake City and (we thought) agreed upon but
>    we would like to hear the chairs'/AD's word on this.
> 
If the MIBs are GMPLS specific, in which case they would 
probably conatin a set of AUGMENTing tables to the MPLS MIBs,
then they may belong in CCAMP. If they are changing (i.e.
just repeating and adding new objects) the base tables in the
MPLS MIBs, then it seems to me that they may also belong in the
MPLS WG. I'd like to hear from author how they want to approach
adding GMPLS management objects to the MPLS MIBs. Then I want
to hear from WG chairs how they are reading consensus on what
to do and where to do it.

Bert, again speaking as AD

> 3. We request that these be adopted as WG documents; shortly
>    thereafter we will reissue them under the correct MIB and document
>    names.
> 
> Thanks,
> Cheenu
> 
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Friday, January 25, 2002 9:50 AM
> > To: Wijnen, Bert (Bert)
> > Cc: Joan Cucchiara; Cheenu Srinivasan; [email-masked]; Kireeti
> > Kompella; Vijay Gill; [email-masked]
> > Subject: RE: GMPLS MIB I-D updates
> > 
> > 
> > 
> >          Hi,
> > 
> > >Thanks for the posting.
> > >I have not yet looked at these new MIBs.
> > >If they are indeed updates or enhancements to the MPLS versions,
> > >then they should follow the rules/guidelines that we have for
> > >updating MIB Modules as outlined in RFC2578.
> > 
> >          The question of what to name the documents is up
> > to the WG; the co-authors are indifferent on this issue.
> > Just some background.  The state of the GMPLS MIBs is that they
> > do indeed extend existing  MPLS MIBs  to facilitate new GMPLS
> > functions. Specifically, they have been modified to
> > accommodate longer labels, and a few other things.
> > However, in the future, additional modifications, features 
> > and functions
> > may be added that are GMPLS-specific.
> > 
> > >That is independent of the question of which WG does the work.
> > 
> >          As I recall, the question of where this work is to be done
> > was already discussed and decided that it would happen in
> > CCAMP. However, the ADs, George and Kareeti might want to
> > verify this for us all. The co-authors are agnostic as to 
> > where the work
> > gets done; however, the point raised above about the MIBs 
> potentially
> > changing more for GMPLS-specifics might bias the work to be done
> > in CCAMP. This is also why we chose the naming of the documents.
> > 
> >          --Tom
> > 
> > 
> > 
> > >Bert
> > >
> > > > -----Original Message-----
> > > > From: Joan Cucchiara [mailto:[email-masked]]
> > > > Sent: Friday, January 25, 2002 1:43 AM
> > > > To: Cheenu Srinivasan
> > > > Cc: [email-masked]; Kireeti Kompella; Vijay Gill
> > > > Subject: Re: GMPLS MIB I-D updates
> > > >
> > > >
> > > >
> > > > Hi Folks,
> > > >
> > > > I would like to raise 2 concerns with having this working
> > > > group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka
> > > > GMPLS-LSR-MIB)
> > > > and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> > > >
> > > > 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> > > > are updates to 2 of the MIBs in the MPLS working group,
> > > > namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs
> > > > should be proposed in the MPLS working group which is 
> where folks
> > > > have experience in implementing and using them.  In my 
> opinion the
> > > > additions for GMPLS to these MIBs is minor and it would 
> be better
> > > > to stick with the MPLS working group for these MIBs.
> > > >
> > > > 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> > > > GMPLS-TE-MIB,
> > > > does not follow how the IETF names a new version of a MIB.
> > > > The current trend in the IETF is to use the same name for
> > > > the draft versions of an existing MIB and differentiate this
> > > > with the draft title (and eventually a new RFC number).  
> > As examples:
> > > >
> > > > draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> > > > draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> > > > draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name: 
> > EtherLike-MIB
> > > > draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> > > > draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> > > > and many others...
> > > >
> > > > My biggest concern is that the names of GMPLS-LSR-MIB and 
> > GMPLS-TE-MIB
> > > > will be confusing and misleading to customers.  Could these be
> > > > renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus, 
> accurately reflect
> > > > what they are?
> > > >
> > > > thanks,
> > > >  -Joan
> > > >
> > > > Cheenu Srinivasan wrote:
> > > > >
> > > > > We would like to request that these four I-Ds be 
> > adopted as CCAMP
> > > > > working group documents.
> > > > >
> > > > > Thanks,
> > > > > Tom, Cheenu, Adrian, Tim, Ed
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Cheenu Srinivasan
> > > > > > Sent: Thursday, January 24, 2002 12:48 PM
> > > > > > To: [email-masked]
> > > > > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim
> > > > Hall (E-mail);
> > > > > > Ed Harrison (E-mail)
> > > > > > Subject: GMPLS MIB I-D updates
> > > > > >
> > > > > >
> > > > > > The following I-D updates have been posted:
> > > > > >
> > > > > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > > > > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > > > > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > > > > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > > > > >
> > > > > > They are aligned with each other and have been verified to
> > > > > > compile cleanly with smilint.
> > > > > >
> > > > > > They should appear on the IETF's site shortly. Copies are
> > > > > > attached for your reference.
> > > > > >
> > > > > > Cheenu
> > > > > >
> > > >
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time. 
> > 
> > 
> 

Delivery-date: Fri, 25 Jan 2002 07:22:39 -0800
Content-class: urn:content-classes:message
Subject: RE: GMPLS MIB I-D updates
Date: Fri, 25 Jan 2002 10:21:36 -0500
From: "Cheenu Srinivasan" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Joan Cucchiara" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Vijay Gill" <[email-masked]>, <[email-masked]>

Just to reiterate the authors' view:

1. We can change the MIB/doc name to whatever the WG/chairs/ADs think
   is appropriate.

2. We believe CCAMP is the appropriate place to continue this
   work since the extensions are completely GMPLS related. This was
   discussed in Salt Lake City and (we thought) agreed upon but
   we would like to hear the chairs'/AD's word on this.

3. We request that these be adopted as WG documents; shortly
   thereafter we will reissue them under the correct MIB and document
   names.

Thanks,
Cheenu

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 9:50 AM
> To: Wijnen, Bert (Bert)
> Cc: Joan Cucchiara; Cheenu Srinivasan; [email-masked]; Kireeti
> Kompella; Vijay Gill; [email-masked]
> Subject: RE: GMPLS MIB I-D updates
>=20
>=20
>=20
>          Hi,
>=20
> >Thanks for the posting.
> >I have not yet looked at these new MIBs.
> >If they are indeed updates or enhancements to the MPLS versions,
> >then they should follow the rules/guidelines that we have for
> >updating MIB Modules as outlined in RFC2578.
>=20
>          The question of what to name the documents is up
> to the WG; the co-authors are indifferent on this issue.
> Just some background.  The state of the GMPLS MIBs is that they
> do indeed extend existing  MPLS MIBs  to facilitate new GMPLS
> functions. Specifically, they have been modified to
> accommodate longer labels, and a few other things.
> However, in the future, additional modifications, features=20
> and functions
> may be added that are GMPLS-specific.
>=20
> >That is independent of the question of which WG does the work.
>=20
>          As I recall, the question of where this work is to be done
> was already discussed and decided that it would happen in
> CCAMP. However, the ADs, George and Kareeti might want to
> verify this for us all. The co-authors are agnostic as to=20
> where the work
> gets done; however, the point raised above about the MIBs potentially
> changing more for GMPLS-specifics might bias the work to be done
> in CCAMP. This is also why we chose the naming of the documents.
>=20
>          --Tom
>=20
>=20
>=20
> >Bert
> >
> > > -----Original Message-----
> > > From: Joan Cucchiara [mailto:[email-masked]]
> > > Sent: Friday, January 25, 2002 1:43 AM
> > > To: Cheenu Srinivasan
> > > Cc: [email-masked]; Kireeti Kompella; Vijay Gill
> > > Subject: Re: GMPLS MIB I-D updates
> > >
> > >
> > >
> > > Hi Folks,
> > >
> > > I would like to raise 2 concerns with having this working
> > > group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka
> > > GMPLS-LSR-MIB)
> > > and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> > >
> > > 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> > > are updates to 2 of the MIBs in the MPLS working group,
> > > namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs
> > > should be proposed in the MPLS working group which is where folks
> > > have experience in implementing and using them.  In my opinion the
> > > additions for GMPLS to these MIBs is minor and it would be better
> > > to stick with the MPLS working group for these MIBs.
> > >
> > > 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> > > GMPLS-TE-MIB,
> > > does not follow how the IETF names a new version of a MIB.
> > > The current trend in the IETF is to use the same name for
> > > the draft versions of an existing MIB and differentiate this
> > > with the draft title (and eventually a new RFC number). =20
> As examples:
> > >
> > > draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> > > draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> > > draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name:=20
> EtherLike-MIB
> > > draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> > > draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> > > and many others...
> > >
> > > My biggest concern is that the names of GMPLS-LSR-MIB and=20
> GMPLS-TE-MIB
> > > will be confusing and misleading to customers.  Could these be
> > > renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus, accurately reflect
> > > what they are?
> > >
> > > thanks,
> > >  -Joan
> > >
> > > Cheenu Srinivasan wrote:
> > > >
> > > > We would like to request that these four I-Ds be=20
> adopted as CCAMP
> > > > working group documents.
> > > >
> > > > Thanks,
> > > > Tom, Cheenu, Adrian, Tim, Ed
> > > >
> > > > > -----Original Message-----
> > > > > From: Cheenu Srinivasan
> > > > > Sent: Thursday, January 24, 2002 12:48 PM
> > > > > To: [email-masked]
> > > > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim
> > > Hall (E-mail);
> > > > > Ed Harrison (E-mail)
> > > > > Subject: GMPLS MIB I-D updates
> > > > >
> > > > >
> > > > > The following I-D updates have been posted:
> > > > >
> > > > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > > > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > > > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > > > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > > > >
> > > > > They are aligned with each other and have been verified to
> > > > > compile cleanly with smilint.
> > > > >
> > > > > They should appear on the IETF's site shortly. Copies are
> > > > > attached for your reference.
> > > > >
> > > > > Cheenu
> > > > >
> > >
>=20
>=20
>=20
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time.=20
>=20
>=20

Delivery-date: Fri, 25 Jan 2002 06:52:36 -0800
Date: Fri, 25 Jan 2002 09:50:02 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: GMPLS MIB I-D updates
Cc: Joan Cucchiara <[email-masked]>, Cheenu Srinivasan <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, [email-masked]

         Hi,

>Thanks for the posting.
>I have not yet looked at these new MIBs.
>If they are indeed updates or enhancements to the MPLS versions,
>then they should follow the rules/guidelines that we have for
>updating MIB Modules as outlined in RFC2578.

         The question of what to name the documents is up
to the WG; the co-authors are indifferent on this issue.
Just some background.  The state of the GMPLS MIBs is that they
do indeed extend existing  MPLS MIBs  to facilitate new GMPLS
functions. Specifically, they have been modified to
accommodate longer labels, and a few other things.
However, in the future, additional modifications, features and functions
may be added that are GMPLS-specific.

>That is independent of the question of which WG does the work.

         As I recall, the question of where this work is to be done
was already discussed and decided that it would happen in
CCAMP. However, the ADs, George and Kareeti might want to
verify this for us all. The co-authors are agnostic as to where the work
gets done; however, the point raised above about the MIBs potentially
changing more for GMPLS-specifics might bias the work to be done
in CCAMP. This is also why we chose the naming of the documents.

         --Tom

>Bert
>
> > -----Original Message-----
> > From: Joan Cucchiara [mailto:[email-masked]]
> > Sent: Friday, January 25, 2002 1:43 AM
> > To: Cheenu Srinivasan
> > Cc: [email-masked]; Kireeti Kompella; Vijay Gill
> > Subject: Re: GMPLS MIB I-D updates
> >
> >
> >
> > Hi Folks,
> >
> > I would like to raise 2 concerns with having this working
> > group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka
> > GMPLS-LSR-MIB)
> > and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> >
> > 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> > are updates to 2 of the MIBs in the MPLS working group,
> > namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs
> > should be proposed in the MPLS working group which is where folks
> > have experience in implementing and using them.  In my opinion the
> > additions for GMPLS to these MIBs is minor and it would be better
> > to stick with the MPLS working group for these MIBs.
> >
> > 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> > GMPLS-TE-MIB,
> > does not follow how the IETF names a new version of a MIB.
> > The current trend in the IETF is to use the same name for
> > the draft versions of an existing MIB and differentiate this
> > with the draft title (and eventually a new RFC number).  As examples:
> >
> > draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> > draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> > draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name: EtherLike-MIB
> > draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> > draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> > and many others...
> >
> > My biggest concern is that the names of GMPLS-LSR-MIB and GMPLS-TE-MIB
> > will be confusing and misleading to customers.  Could these be
> > renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus, accurately reflect
> > what they are?
> >
> > thanks,
> >  -Joan
> >
> > Cheenu Srinivasan wrote:
> > >
> > > We would like to request that these four I-Ds be adopted as CCAMP
> > > working group documents.
> > >
> > > Thanks,
> > > Tom, Cheenu, Adrian, Tim, Ed
> > >
> > > > -----Original Message-----
> > > > From: Cheenu Srinivasan
> > > > Sent: Thursday, January 24, 2002 12:48 PM
> > > > To: [email-masked]
> > > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim
> > Hall (E-mail);
> > > > Ed Harrison (E-mail)
> > > > Subject: GMPLS MIB I-D updates
> > > >
> > > >
> > > > The following I-D updates have been posted:
> > > >
> > > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > > >
> > > > They are aligned with each other and have been verified to
> > > > compile cleanly with smilint.
> > > >
> > > > They should appear on the IETF's site shortly. Copies are
> > > > attached for your reference.
> > > >
> > > > Cheenu
> > > >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Fri, 25 Jan 2002 03:53:18 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nadeau-ccamp-gmpls-tc-mib-01.txt
Date: Fri, 25 Jan 2002 06:52:04 -0500

--NextPart

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

	Title		: Definition of Textual Conventions and
                          OBJECT-IDENTITIES for Generalized Multiprotocol Label 
                          Switching (GMPLS) Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-nadeau-ccamp-gmpls-tc-mib-01.txt
	Pages		: 14
	Date		: 24-Jan-02
	
This memo describes Textual Conventions and OBJECT-
IDENTITIES common to the Management Information Bases
(MIBs) for managing Generalized Multiprotocol Label
It supplements [TCMIB] which describes Textual
Conventions and OBJECT-IDENTITIES common to the
Management Information Bases (MIBs) for managing
Multiprotocol Label Switching (MPLS) networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nadeau-ccamp-gmpls-tc-mib-01.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-nadeau-ccamp-gmpls-tc-mib-01.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-nadeau-ccamp-gmpls-tc-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-nadeau-ccamp-gmpls-tc-mib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 25 Jan 2002 03:53:15 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nadeau-ccamp-gmpls-te-mib-01.txt
Date: Fri, 25 Jan 2002 06:52:18 -0500

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching 
                          (GMPLS)Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-nadeau-ccamp-gmpls-te-mib-01.txt
	Pages		: 103
	Date		: 24-Jan-02
	
This memo defines an experimental portion of the
Management Information Base (MIB) for use with network
management protocols in the Internet community.  In
particular, it describes managed objects for
Multiprotocol Label Switching (MPLS) [RFC3031] and
Generalized Multiprotocol Label Switching (GMPLS)
[GMPLSArch] based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nadeau-ccamp-gmpls-te-mib-01.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-nadeau-ccamp-gmpls-te-mib-01.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-nadeau-ccamp-gmpls-te-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-nadeau-ccamp-gmpls-te-mib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 25 Jan 2002 03:53:12 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nadeau-ccamp-gmpls-label-mib-01.txt
Date: Fri, 25 Jan 2002 06:52:09 -0500

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching (GMPLS) 
                          Label Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-nadeau-ccamp-gmpls-label-mib-01.txt
	Pages		: 23
	Date		: 24-Jan-02
	
This memo defines an experimental portion of the
Management Information Base (MIB) for use with network
management protocols in the Internet community.  In
particular, it describes managed objects defining label
for Multiprotocol Label Switching (MPLS) [RFC3031] and
Generalized Multiprotocol Label Switching (GMPLS)
[GMPLSArch] Label Switching Routers (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nadeau-ccamp-gmpls-label-mib-01.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-nadeau-ccamp-gmpls-label-mib-01.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-nadeau-ccamp-gmpls-label-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-nadeau-ccamp-gmpls-label-mib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 25 Jan 2002 03:53:09 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
Date: Fri, 25 Jan 2002 06:52:13 -0500

--NextPart

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

	Title		: Generalized Multiprotocol Label Switching (GMPLS)Label
                          Switch Router Management Information Base
	Author(s)	: T. Nadeau et al.
	Filename	: draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
	Pages		: 68
	Date		: 24-Jan-02
	
This memo defines a portion of the Management Information
Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes
managed objects for Multiprotocol Label Switching (MPLS)
and Generalized Multiprotocol Label Switching (GMPLS)
Label Switched Routers (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nadeau-ccamp-gmpls-lsr-mib-01.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-nadeau-ccamp-gmpls-lsr-mib-01.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-nadeau-ccamp-gmpls-lsr-mib-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-nadeau-ccamp-gmpls-lsr-mib-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 25 Jan 2002 02:09:44 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Joan Cucchiara <[email-masked]>, Cheenu Srinivasan <[email-masked]>
Cc: [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
Subject: RE: GMPLS MIB I-D updates
Date: Fri, 25 Jan 2002 11:07:28 +0100

Thanks for the posting. 
I have not yet looked at these new MIBs.
If they are indeed updates or enhancements to the MPLS versions,
then they should follow the rules/guidelines that we have for
updating MIB Modules as outlined in RFC2578. 

That is independent of the question of which WG does the work.

Bert 

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 1:43 AM
> To: Cheenu Srinivasan
> Cc: [email-masked]; Kireeti Kompella; Vijay Gill
> Subject: Re: GMPLS MIB I-D updates
> 
> 
> 
> Hi Folks,
> 
> I would like to raise 2 concerns with having this working
> group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka 
> GMPLS-LSR-MIB)
> and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> 
> 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> are updates to 2 of the MIBs in the MPLS working group, 
> namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs 
> should be proposed in the MPLS working group which is where folks 
> have experience in implementing and using them.  In my opinion the
> additions for GMPLS to these MIBs is minor and it would be better
> to stick with the MPLS working group for these MIBs.
> 
> 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> GMPLS-TE-MIB,
> does not follow how the IETF names a new version of a MIB.
> The current trend in the IETF is to use the same name for
> the draft versions of an existing MIB and differentiate this
> with the draft title (and eventually a new RFC number).  As examples:
> 
> draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name: EtherLike-MIB
> draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> and many others...
> 
> My biggest concern is that the names of GMPLS-LSR-MIB and GMPLS-TE-MIB
> will be confusing and misleading to customers.  Could these be
> renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus, accurately reflect
> what they are?
> 
> thanks,
>  -Joan
> 
> Cheenu Srinivasan wrote:
> > 
> > We would like to request that these four I-Ds be adopted as CCAMP
> > working group documents.
> > 
> > Thanks,
> > Tom, Cheenu, Adrian, Tim, Ed
> > 
> > > -----Original Message-----
> > > From: Cheenu Srinivasan
> > > Sent: Thursday, January 24, 2002 12:48 PM
> > > To: [email-masked]
> > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim 
> Hall (E-mail);
> > > Ed Harrison (E-mail)
> > > Subject: GMPLS MIB I-D updates
> > >
> > >
> > > The following I-D updates have been posted:
> > >
> > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > >
> > > They are aligned with each other and have been verified to
> > > compile cleanly with smilint.
> > >
> > > They should appear on the IETF's site shortly. Copies are
> > > attached for your reference.
> > >
> > > Cheenu
> > >
> 

Delivery-date: Thu, 24 Jan 2002 16:41:52 -0800
Date: Thu, 24 Jan 2002 19:42:35 -0500
From: Joan Cucchiara <[email-masked]>
Organization: Crescent Networks
To: Cheenu Srinivasan <[email-masked]>
CC: [email-masked], Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
Subject: Re: GMPLS MIB I-D updates

Hi Folks,

I would like to raise 2 concerns with having this working
group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka GMPLS-LSR-MIB)
and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):

1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
are updates to 2 of the MIBs in the MPLS working group, 
namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs 
should be proposed in the MPLS working group which is where folks 
have experience in implementing and using them.  In my opinion the
additions for GMPLS to these MIBs is minor and it would be better
to stick with the MPLS working group for these MIBs.

2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
GMPLS-TE-MIB,
does not follow how the IETF names a new version of a MIB.
The current trend in the IETF is to use the same name for
the draft versions of an existing MIB and differentiate this
with the draft title (and eventually a new RFC number).  As examples:

draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name: EtherLike-MIB
draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
and many others...

My biggest concern is that the names of GMPLS-LSR-MIB and GMPLS-TE-MIB
will be confusing and misleading to customers.  Could these be
renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus, accurately reflect
what they are?

thanks,
 -Joan

Cheenu Srinivasan wrote:
> 
> We would like to request that these four I-Ds be adopted as CCAMP
> working group documents.
> 
> Thanks,
> Tom, Cheenu, Adrian, Tim, Ed
> 
> > -----Original Message-----
> > From: Cheenu Srinivasan
> > Sent: Thursday, January 24, 2002 12:48 PM
> > To: [email-masked]
> > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim Hall (E-mail);
> > Ed Harrison (E-mail)
> > Subject: GMPLS MIB I-D updates
> >
> >
> > The following I-D updates have been posted:
> >
> >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> >
> > They are aligned with each other and have been verified to
> > compile cleanly with smilint.
> >
> > They should appear on the IETF's site shortly. Copies are
> > attached for your reference.
> >
> > Cheenu
> >

Delivery-date: Thu, 24 Jan 2002 09:54:35 -0800
Content-class: urn:content-classes:message
Subject: RE: GMPLS MIB I-D updates
Date: Thu, 24 Jan 2002 12:51:15 -0500
From: "Cheenu Srinivasan" <[email-masked]>
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Vijay Gill" <[email-masked]>

We would like to request that these four I-Ds be adopted as CCAMP
working group documents.

Thanks,
Tom, Cheenu, Adrian, Tim, Ed

> -----Original Message-----
> From: Cheenu Srinivasan=20
> Sent: Thursday, January 24, 2002 12:48 PM
> To: [email-masked]
> Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim Hall (E-mail);
> Ed Harrison (E-mail)
> Subject: GMPLS MIB I-D updates
>=20
>=20
> The following I-D updates have been posted:
>=20
>   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
>   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
>   draft-nadeau-ccamp-gmpls-te-mib-01.txt
>   draft-nadeau-ccamp-gmpls-label-mib-01.txt
>=20
> They are aligned with each other and have been verified to
> compile cleanly with smilint.
>=20
> They should appear on the IETF's site shortly. Copies are
> attached for your reference.
>=20
> Cheenu
>=20

Delivery-date: Thu, 24 Jan 2002 09:53:01 -0800
Content-class: urn:content-classes:message
Subject: GMPLS MIB I-D updates
Date: Thu, 24 Jan 2002 12:47:54 -0500
From: "Cheenu Srinivasan" <[email-masked]>
To: <[email-masked]>
Cc: "Thomas Nadeau (E-mail)" <[email-masked]>, "Adrian Farrel (E-mail)" <[email-masked]>, "Tim Hall (E-mail)" <[email-masked]>, "Ed Harrison (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1A4FF.4077CF33
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The following I-D updates have been posted:

  draft-nadeau-ccamp-gmpls-tc-mib-01.txt
  draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
  draft-nadeau-ccamp-gmpls-te-mib-01.txt
  draft-nadeau-ccamp-gmpls-label-mib-01.txt

They are aligned with each other and have been verified to
compile cleanly with smilint.

They should appear on the IETF's site shortly. Copies are
attached for your reference.

Cheenu

------_=_NextPart_001_01C1A4FF.4077CF33
Content-Type: text/plain;
	name="draft-nadeau-ccamp-gmpls-label-mib-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-nadeau-ccamp-gmpls-label-mib-01.txt
Content-Disposition: attachment;
	filename="draft-nadeau-ccamp-gmpls-label-mib-01.txt"

------_=_NextPart_001_01C1A4FF.4077CF33
Content-Type: text/plain;
	name="draft-nadeau-ccamp-gmpls-lsr-mib-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
Content-Disposition: attachment;
	filename="draft-nadeau-ccamp-gmpls-lsr-mib-01.txt"

------_=_NextPart_001_01C1A4FF.4077CF33
Content-Type: text/plain;
	name="draft-nadeau-ccamp-gmpls-tc-mib-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-nadeau-ccamp-gmpls-tc-mib-01.txt
Content-Disposition: attachment;
	filename="draft-nadeau-ccamp-gmpls-tc-mib-01.txt"

------_=_NextPart_001_01C1A4FF.4077CF33
Content-Type: text/plain;
	name="draft-nadeau-ccamp-gmpls-te-mib-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-nadeau-ccamp-gmpls-te-mib-01.txt
Content-Disposition: attachment;
	filename="draft-nadeau-ccamp-gmpls-te-mib-01.txt"

------_=_NextPart_001_01C1A4FF.4077CF33--

Delivery-date: Thu, 24 Jan 2002 07:30:16 -0800
From: "Bhargava, Nidhi" <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject:  LMP Error code question
Date: Thu, 24 Jan 2002 10:24:29 -0500

Hi,
In the draft-ietf-ccamp-lmp-02.txt, section 14.16 talks about the 
Link_summary_error code.
Should the value 0x04 (Bad received Remote_link_Id) be used for 
Interface Id mismatch also?
If a Link summary message contains some data links having
interface Id mismatchings and some with non acceptable link
properties, how can we differentiate between the two errors
in the link summary Nack message?

Thanks
Nidhi
-------------------------------
Nidhi Bhargava
NetPlane Systems Inc.
A Mindspeed Technologies Company
Tel:   + 1.781.329.3200 x5353
Web:   http://www.netplane.com

Delivery-date: Fri, 18 Jan 2002 13:04:28 -0800
Date: Fri, 18 Jan 2002 16:05:19 -0500
From: Srinivasa Datari <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: LMP Message ID question

Hi,

In the draft-ietf-ccamp-lmp-02.txt, section 7 talks about Message ID usage. It
states that
	"Unacknowledged messages sent with the MESSAGE_ID object SHOULD be 
   retransmitted until the message is acknowledged or until a retry 
   limit is reached."

What are the subsequent actions that need to take place when the above
conditions occur ? Is there a recommended value for the "retry limit" ? Should
Link Summary start all over (with the TX and RX message IDs reset to initial
values ?)

Thanks.
Srini Datari

Delivery-date: Thu, 17 Jan 2002 17:32:14 -0800
From: "Karmakar, Soumen" <[email-masked]>
To: [email-masked]
Subject: Use of ResvTear at UNI
Date: Thu, 17 Jan 2002 17:26:31 -0800

Hi, Since the optical networks use the graceful shutdown procedure (and
mandated in UNI 1.0) so the use of ResvTear Message is not seen. However the
UNI 1.0 draft mentions that ResvTear is supported in UNI 1.0 to be
compatible with RSVP. How is the reception of ResvTear to be handled (if it
comes) ? Is it to be ignored or accepted ? 

Delivery-date: Thu, 17 Jan 2002 03:56:02 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-02.txt
Date: Thu, 17 Jan 2002 06:47:43 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-02.txt
	Pages		: 9
	Date		: 16-Jan-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS).  The description of the extensions is specified in [GMPLS-
ROUTING].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-ospf-gmpls-extensions-02.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-ietf-ccamp-ospf-gmpls-extensions-02.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-ietf-ccamp-ospf-gmpls-extensions-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-02.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, 16 Jan 2002 15:42:54 -0800
From: Joe Dumont <[email-masked]>
Reply-To: [email-masked]
To: [email-masked],[email-masked]
Subject: Addition to Deletion Proc for GMPLS RSVP
Date: Wed, 16 Jan 2002 17:39:18 -0600

I posted this comment a few weeks ago and I have not recevied a response yet.  I have attached the original 
posting:

Hello,

Section 7.2.2 of generalized-rsvp-te-06 does not appear cover the case of an Egress initiated deletion where the ingress node does not support admin status. 

I suggest the following additional wording to be added to the end of section 7.2.2 to clarify this additional error procedure:

"In the case of a non-supporting ingress node, a PathTear may not be returned when an egress node sends a Resv with D and R bits set. To support the case of non-supporting ingress node, the egress SHOULD only wait a configurable period of time for the PathTear message to be returned. Once the period of time has elapsed, the egress node sends a ResvTear message or a PathErr message with Path_state_removed flag set, and normal RSVP takes place. By default for this period SHOULD be 30 seconds."

Regards,

Joe

Delivery-date: Wed, 16 Jan 2002 11:05:32 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Admin Status Change
Date: Wed, 16 Jan 2002 12:03:01 -0700

Hi All,
        As per GMPLS drafts, if the ingress node wants to delete the
connection then it sends that path message with admin status as down.
What if the transit node recieves modified path message (e.g. policy data 
change etc) with admin status down ? Should the transit node look
at the modified params or just process the admin status ?

Regards,
manoj.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Wed, 16 Jan 2002 10:12:30 -0800
From: "Morgan, Peter (Engineering)" <[email-masked]>
To: "'Remi Theillaud'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: O-UNI/GMPLS node implementing CR-LDP
Date: Tue, 15 Jan 2002 13:52:44 -0000

Perhaps this will a configurable option on the "intelligent" box. Much the
same way as a BGP speaker knows whether  to run IBGP or EBGP.

Regards,
Peter.

-----Original Message-----
From: Remi Theillaud [mailto:[email-masked]]
Sent: 15 January 2002 11:41
To: [email-masked]; [email-masked]
Subject: O-UNI/GMPLS node implementing CR-LDP

I have one question regarding the extended discovery mechanism for nodes
that host both a GMPLS application and an O-UNI application (I'm not aware
of any standard forbidding such a configuration).

My current understanding:

_ For GMPLS, a node determines whether it plays the active role or the
passive role for a LDP session by comparing its own source (or transport) IP
address with the source (or transport) IP address of the LDP peer.
_ For OIF O-UNI, the O-UNI client always plays the active role; the O-UNI NE
always plays the passive role.

Assuming that the LDP extending discovery mechanism is used. If a node
implements the CR-LDP protocol for, let's say, both GMPLS and O-UNI NE, how
is it supposed to behave when it receives a LDP Targeted Hello message ? I
mean: which rules should it use to determine whether it should play the
active or passive role for the LDP session ?

Now assuming the LDP basic discovery mechanism. Same question. Maybe here
the control channel from which Link Hello messages are received is either
used for O-UNI signaling, or for GMPLS signaling, not both, so the rules
that should be used can be inferred from the control channel; makes any
sense ?

Remi Theillaud
Atos Origin

Delivery-date: Tue, 15 Jan 2002 03:44:20 -0800
Reply-To: "Remi Theillaud" <[email-masked]>
From: "Remi Theillaud" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: O-UNI/GMPLS node implementing CR-LDP
Date: Tue, 15 Jan 2002 12:41:27 +0100
Organization: AtosOrigin

I have one question regarding the extended discovery mechanism for nodes
that host both a GMPLS application and an O-UNI application (I'm not aware
of any standard forbidding such a configuration).

My current understanding:

_ For GMPLS, a node determines whether it plays the active role or the
passive role for a LDP session by comparing its own source (or transport) IP
address with the source (or transport) IP address of the LDP peer.
_ For OIF O-UNI, the O-UNI client always plays the active role; the O-UNI NE
always plays the passive role.

Assuming that the LDP extending discovery mechanism is used. If a node
implements the CR-LDP protocol for, let's say, both GMPLS and O-UNI NE, how
is it supposed to behave when it receives a LDP Targeted Hello message ? I
mean: which rules should it use to determine whether it should play the
active or passive role for the LDP session ?

Now assuming the LDP basic discovery mechanism. Same question. Maybe here
the control channel from which Link Hello messages are received is either
used for O-UNI signaling, or for GMPLS signaling, not both, so the rules
that should be used can be inferred from the control channel; makes any
sense ?

Remi Theillaud
Atos Origin

Delivery-date: Tue, 08 Jan 2002 22:32:50 -0800
To: [email-masked]
Date: Tue, 08 Jan 2002 22:26:04 -0800
From: "mitali J" <[email-masked]>
Reply-To: [email-masked]
Subject: Label Allocation in optical domain
Organization: Lycos Mail  (http://mail.lycos.com:80)
Content-Length: 1196

Hi All,
        I have a doubt related to the label allocation
in GMPLS. If I have two nodes A and B directly
connected by a bi-directional STM-16 link. Further
assume that this link is able to switch connections of
VC-4 granularity only. I will number 16 VC-4s in STM
-16 as say from 1...16 that are avaliable for
allocation. If a request comes from node A to
establish the bi-directional VC-4 connection (with
suggested label say 2, upstream label 2). Node B
allocates the label 2 to this connection. This means
that the available labels at nodes A and B after
successful establishment of the connection are
1,3,4...16 at both the ends. Now if a request comes
from A to establish a uni-directional connection from
A to B with suggested label as say 1. Node B will go
ahead and allocate label 1. This means label 1 is
allocated in direction of data flow from A to B but
the same label viz. 1 is free for allocation (for some
uni-directional LSP establishment from B to A) for the
data flow from node B to A.

Is this method of allocation correct ?

I would appreciate if anyone can provide link to information on fiber and lambda allocation too.

Regards,
mitali.

Delivery-date: Mon, 07 Jan 2002 23:12:49 -0800
Date: Tue, 08 Jan 2002 02:09:19 -0500
From: Gopal Kailad <[email-masked]>
To: Lou Berger <[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], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Transport networks and draft-ietf-mpls-generalized-rsvp-te  [ was Re: GMPLS signaling documents updated per last calls]

Lou Berger wrote:

 > At 09:38 AM 12/20/2001, Gopal Kailad wrote:
 >
 >> The Restart Time field in the Restart_Cap object supports a
 >> maximum value of about 49 days.  In case of transport networks,
 >> this would mean that in case of a controller failure due to say,
 >> a natural disaster, if the node is not accessible, established
 >> connections will fail after 49 days even if data plane is not
 >> affected, which is unacceptable.
 >
 >
 > You're right.  This looks like a blown edit.  The 0xffffffff value
 > applies to Restart not recovery time.  I'll move the text.  I'll also
 > elaborate for a bit more clarity.
 >
 > Thanks,
 > Lou
 >

This does not solve the problem of multiple controller failures.

I have attached the original message that you were responding to.
Does the current procedure for Fault Handling satisfy control
plane resiliency requirements specified in draft-ietf-ipo-carrier
-requirements?

Can you elaborate on how this procedure for Fault Handling
will work in the example scenario described where nodes B and C
fail, but only C restarts but B does not?

Regards,

Gopal

-------- Original Message --------

One characteristic of traditional transport networks is that
control plane failures do not affect established lightpaths or
TDM channels.  This is reflected by requirement 144 in
draft-ietf-ipo-carrier-requirements-00: "Control plane failures
shall not cause failure of established data plane connections."
Note that there is no time limit imposed on how long a control
plane failure can last without affecting established data plane
connections.

The Restart Time field in the Restart_Cap object supports a
maximum value of about 49 days.  In case of transport networks,
this would mean that in case of a controller failure due to say,
a natural disaster, if the node is not accessible, established
connections will fail after 49 days even if data plane is not
affected, which is unacceptable.

Even if this is fixed so that a node can advertise that the
restart time is infinite, there is another issue.  In existing
transport networks, established data plane connections do not
fail even if multiple controllers fail.  Accordingly, the
requirement from draft-ietf-ipo-carrier-requirements-00 quoted
above requires that there be no failure in the data plane in case
of "control plane failures."  This would effectively mean that
the recovery time could also be indeterminate. Consider the
following example with four nodes:

                      A ---- B ---- C ---- D

If B and C fail, and C restarts, it can not complete
synchronization with D until B restarts and exchanges state with
C.

I believe this level of resiliency is not possible with the
procedure specified.  Just advertising 0xffffffff for recovery
time will not be enough, as this could cause state to be held
indefinitely when it should be deleted.

So I suggest one of the following:

  - remove the restart section from the draft and consider it
    as a separate draft, so that the rest can move forward.

  - add a constraint in the beginning of section 9.5, after the
    first sentence:

    "The recovery mechanism specified in this section addresses
    restart issues only in case of PSC devices, and does not
    fulfil the requirements for transport networks.  Recovery
    procedures for transport networks is for further study."

  - postpone the last call, and look at adding a solution that
    would also satisfy the requirements of transport networks.

 From a transport network perspective, this could be a starting
point for discussion:

  - A new object called PERSISTENT_SESSION is introduced to
    indicate that a session is long lasting.  This will be sent
    in the Path message associated with transport network
    sessions.  This will be reflected back in the Resv message.
    The fact that a session is persistent is preserved along with
    forwarding plane information.

  - A new message (LRefresh) is introduced to synchronize the
    forwarding plane information for persistent sessions between
    peers, and it is transmitted periodically.

  - A new object called flags is added and this will be carried
    in Hello messages. This object has one field called flags,
    and a node supporting persistent sessions will set bit 0 of
    the Flags field.  Support for persistent sessions implies
    support for the PERSISTENT_SESSION object as well as
    LRefresh.

  - For sessions that are marked persistent, state will be
    cleared only under these conditions:

    - State will never be cleared based on timeout. Exceptions
      listed below.

    - State will be cleared based on timeout only after sending
      the Resv with the D bit set in the Admin_Status object
      upstream, and only if graceful deletion was initiated by
      the headend. This information will be preserved along with
      forwarding plane information.

    - Reception of PathTear.

    - If a node learns that it has some state in the forwarding
      plane that is not in sync with that of the peer, the
      forwarding plane state as well as associated control plane
      state will be cleared on a timer basis.  This timer will be
      more coarse-grained than the refresh timers for the control
      plane.

    - If a peer does not support persistent sessions, state that
      has to be refreshed by that peer will be timed out in the
      usual manner.  Restart procedure as specified for PSC
      devices may be used if the two nodes support it.

  - Specify clearly what help is needed from outside RSVP. To
    support recovery of hierarchical LSPs, RSVP needs the
    following information upon restart:

    - Mapping between interface id. assigned by the peer and the
      interface id. assigned locally.  (Related qn.: There was a
      suggestion on the list (from Yakov) that a node can learn
      this from the recovered link state database. But if the
      restart time is going to be indeterminate, isn't it
      possible that the TE-LSAs have expired when the node
      restarts?  If so, a node might instead preserve this
      information across restart.  But in any case, RSVP needs
      this information upon restart.)

    - Peers (LSR ids) with which Hello adjacencies were
      established dynamically as a result of FA-LSPs.

Comments?

Cheers,

Gopal

Delivery-date: Mon, 07 Jan 2002 08:41:45 -0800
From: Ling Li <[email-masked]>
To: [email-masked]
Subject: How would the ifMTU be used in gmpls-routing-01.txt
Date: Mon, 7 Jan 2002 11:40:55 -0500 

The draft mentioned the following:
  For Packet-Switch Capable interfaces the additional information
  includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface
  MTU
It explained how the Maximum LSP Bandwidth and Minimum LSP Bandwidth are 
expected to use when setting up an LSP. However it says only the following 
on MTU:
   The Interface MTU is the maximum size of a packet that can be
   transmitted on this interface without being fragmented

My question is how the if mtu is expected to use. Would it be used as a 
constraint during LSP setup just like the bandwidth constraint? If this is
the case, would the application/customer ask for a LSP MTU constraint larger
than a specific value or smaller than a value or both? 

Thanks, 

Ling Li 

Axiowave Networks, Inc. 
200 Nickerson Road 
Marlborough, MA 01752 
Email: [email-masked] 
======================== 

Delivery-date: Mon, 07 Jan 2002 08:32:53 -0800
From: Randy Bush <[email-masked]>
To: Scott  Bradner <[email-masked]>,
Cc: [email-masked]
Subject: Re: sub-ip list and draft sub-ip session minutes
Date: Mon, 07 Jan 2002 08:30:29 -0800

>>   To find the posting about the minutes, pls point your
>>   web browser to: ftp://ftp.psg.com/pub/lists/subip-area.current
> and/or <http://psg.com/lists/ccamp/ccamp.2002/>

<blush>

   <http://psg.com/lists/subip-area/subip-area.2002/>

and it will tell you "no data" until there is something in it

randy

Delivery-date: Mon, 07 Jan 2002 07:41:54 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "''John Drake' '" <[email-masked]>, "'Maarten Vissers '" <[email-masked]>, "'manoj juneja '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Lambda LSP establishment
Date: Mon, 7 Jan 2002 16:41:14 +0100 

Eric,

I am getting more confused on the subject with your introduction of "mini dummy VC-4 circuits".
Can some one for the second example below with the two VC-12 cross-connects connected via a VC-4 only cross-connect explain what are the routing adjacencies, FAs and labels for a VC-12 connection setup for the case that the VC-4 only cross-connect is GMPLS capable and not.

Regards

Juergen

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Friday, December 21, 2001 6:21 PM
To: 'Heiles Juergen'; ''John Drake' '; 'Maarten Vissers '; 'manoj juneja
'
Cc: [email-masked] '
Subject: RE: Lambda LSP establishment

Hello Juergen,

We already discussed it so many times....

FAs and links are two different objects. No routing adjacency over an FA
LSP. FAs are optional. You can route a VC-12 without having any FA. You can
have mini dummy VC-4 "circuits" just between two adjacent LSRs (VC-4 POH
terminated in two adjacent SDH/SONET nodes). These mini dummy VC-4 circuits
will not be seen as customer circuits. They don't need to be seen as FAs.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Thursday, December 20, 2001 11:04 AM
To: Mannie, Eric; Heiles Juergen; ''John Drake' '; 'Maarten Vissers ';
'manoj juneja '
Cc: [email-masked] '
Subject: RE: Lambda LSP establishment

Hi Eric,

thanks for the explanation below. I have some further questions for
clarification and I also think an informational I-D would be helpful.

You said that from the routing point of view a link and an FA are two
different things. There is a routing adjacency "over" a link but not over a
FA.
I don't see the difference between a "physical link" and a FA as routing can
use both to establish a connection.
Furthermore for the SDH case if a VC-12 connection is setup via an existing
VC-4 connection the VC-4 connection is an FA according to my understanding.
However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA,
it is a link. Is this correct? From the VC-12 or VC-4 routing view point I
don't see a difference between the FA or link. Furthermore the STM-16
connection itself could be transported via an OCh or ODUk in a WDM system.
So it is not the physical interface of the equipment. Is it still a link and
no FA as from the physical topology only WDM (OTM-n) interfaces are seen.

Now concerning the setup of a VC-12 over a STM-16. In this case you use the
full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3
connection has to be established prior to the VC-12 connection. Is this
implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists.
Is it now seen as a FA?
Lets have a look on two examples:

(1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC

(2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC

In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4
switching are directly interconnected via a STM-16. In this case the VC-12
label could be defined in relation to the STM-16 interface with the full
SUKLM set. In the second example the two 4/1 cross-connects are
interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do
we need a VC-4 FA in this case between the two 4/1 cross-connects to setup
the VC-12 connection?

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 6:57 PM
> To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj
> juneja '
> Cc: [email-masked] '
> Subject: RE: Lambda LSP establishment
> 
> 
> Hi All,
> 
> A few comments,
> 
> >In MPLS the FA establishes "virtual" layer networks. In 
> GMPLS the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, 
> OCh, OMS, OTS). A
> FA basically corresponds to a real trail in a circuit 
> switched network.
> 
> Eric: ...and this trail is setup dynamically using GMPLS. That's the
> interest. One can think of SDH/SONET FAs as shortcuts or 
> express-routes.
> 
> >One special thing about the SDH label is, that it includes a 
> hierarchy as
> it identifies the lower order VC in a higher order VC in a 
> STM-N signal.
> Note that this is somehow in contradiction with a statement 
> in the GMPLS
> signaling document which says 
> 
> >"A Generalized Label only carries a single level of label, 
> i.e., it is 
>    non-hierarchical.  When multiple levels of label (LSPs 
> within LSPs) 
>    are required, each LSP must be established separately, see [MPLS- 
>    HIERARCHY]." 
> 
> No, hierarchy of labels is not hierarchy of layers. And even 
> one should have
> a common definition of what means a "layer". This text says 
> that we cannot
> have multiple embedded labels, e.g. one label containting a 
> label stack.
> This is a signaling stuff that doesn't imply anything on the transport
> plane.
> 
> Now, a label identifies ONE LSP at an interface. This LSP can 
> be HO or LO in
> SDH. The label can be fully specified or partially specified, 
> depending on
> the context where the LSP is established.
> 
> E.g. when an LSP is established over a FA, the highest part 
> of the LSP label
> is not relevant. When the FA LSP is established the lowest 
> part of the FA
> LSP label is not relevant.
> 
> If a low order LSP is established without any higher order 
> FA, the label is
> fully specified. As you said the link is indeed the "ultimate 
> FA" in that
> case. Except that from the routing point of view a link and 
> an FA are two
> different things. There is a routing adjacency "over" a link 
> but not over a
> FA.
> 
> The SDH/SONET label just includes what you need to include in 
> each scenario.
> 
> Moreover, the label MUST be interpreted according to the type 
> of interface
> for which it is used. It is possible to code two labels 
> having the same
> value but a complete different meaning. Labels are context 
> sensitive of
> course.
> 
> For instance, an LSP over an STM-0 interface or over a FA 
> will have the
> highest part set to zero, and could possibly have the same 
> lowest part. You
> cannot understand what means the label without knowning the 
> detail of the
> interface. In that case, the interface is either an STM-0 
> interface or a
> VC-3 FA. And of course that FA and STM-0 interface are two 
> different things,
> but from the LSP point of view, in both cases what it wants 
> is a VC-3 in
> which it can be multiplexed.
> 
> Hope this helps.
> 
> I start to wonder if we should have an informational draft describing
> different scenarios of SDH/SONET LSP establishment. That 
> could complement
> the SDH/SONET signaling drafts and the GMPLS architecture. 
> That could solve
> many terminology and modeling issues.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen
> To: 'John Drake'; Maarten Vissers; manoj juneja
> Cc: [email-masked]
> Sent: 12/13/01 11:15 AM
> Subject: RE: Lambda LSP establishment
> 
> Let me express my understanding of FAs in MPLS/GMPLS, please 
> correct me
> if I am wrong. I have also some questions related to the label
> generation and interactions between layer networks.
> 
> The label in MPLS is local to the link between two adjacent MPLS
> switches, it indicates a LSP in this link. This link is therefore the
> ultimate FA. An already established LSP between two MPLS 
> switches, which
> don't have to be adjacent, can be used to transport/tunnel other LSPs
> between this two nodes. This already established LSP 
> generates a virtual
> adjacency between the two nodes, the FA. As several LSPs can 
> use this FA
> it is also a kind of virtual multiplexing.
> If you compare it with a circuit switched network the FA is a server
> layer trail that provides transport (a link connection) for 
> one or more
> client layer signals.
> In MPLS the FA establishes "virtual" layer networks. In GMPLS 
> the layer
> networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
> OTS). A FA basically corresponds to a real trail in a circuit switched
> network.
> In GMPLS the label is also local to the link between the two devices
> that perform the switching. For example for SDH the VC-N is identified
> by the STM-N link/port and the SUKLM number according to
> draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is 
> identified by
> the interface ID (I am not sure on this) and SUKLM is the SDH 
> label that
> locates the VC within the STM-N.
> From just the SDH viewpoint the STM-N connection is the 
> ultimate server
> trail/FA. However the STM-N signal could be transported over a Optical
> Channel or G.709 ODU. The OCh or ODU can already start in the 
> equipment
> that performs the VC-N switching. So the STM-N signal is not the port,
> but the WDM signal is the port and the STM-N signal makes use of a OCh
> or ODU server layer trail. This server layer trail can be established
> via management or using GMPLS. 
> Can someone explain how a label for a VC-4 is generated in this case
> (pre-established OCh or ODU trail via management or setup 
> using GMPLS).
> This interaction between the different technologies/labels need in my
> view some further explanation.
> 
> One special thing about the SDH label is, that it includes a hierarchy
> as it identifies the lower order VC in a higher order VC in a STM-N
> signal. Note that this is somehow in contradiction with a statement in
> the GMPLS signaling document which says 
> "A Generalized Label only carries a single level of label, i.e., it is
>    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
>    are required, each LSP must be established separately, see [MPLS-
>    HIERARCHY]."
> Following this statement each layer should have its own label
> independent of server layers.
> The combination of hierarchies in labels is based on technology (e.g.
> SDH, Sonet, G.709 ODU) but has in my view no real technical 
> reason. The
> SDH label for example fits to standard STM-N signals, but not 
> to sub-STM
> signals.
> For the SDH the full SUKLM number is used if a e.g. VC-12 is 
> located in
> relation to a STM-N interface. If it is located in relation to a VC-4
> (the VC-4 is in this case a FA) SUK are set to 0. For me it 
> is not clear
> in which case I use the first and in which case I use the 
> second case as
> a VC-4 trail is always needed for a VC-12 connection. This 
> VC-4 could be
> established using management or GMPLS. However it should have no
> influence on the label. 
> Some more information is needed in my view in this area.
> 
> 
> Juergen
>  
> 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Wednesday, December 12, 2001 6:54 AM
> > To: Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Subject: RE: Lambda LSP establishment
> > 
> > 
> > fortunately, this is just your opinion
> > 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Tuesday, December 11, 2001 9:31 PM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: Lambda LSP establishment
> > 
> > 
> > Manoj,
> > 
> > Forget the FA stuff, it is not appropriate in circuit 
> > networks. It only
> > applies
> > to MPLS. We should remove it when it is used in relation with PDH,
> > SDH/SONET,
> > OTN and pre-OTN. The text in sdh-sonet draft should state 
> > that if there is a
> > LOVC link (IETF: link bundle/TE link) then the LOVC signals 
> > use a label with
> > "00KLM".
> > 
> > Regards,
> > 
> > Maarten
> > 
> > manoj juneja wrote:
> > > 
> > > Hi Marteen,
> > >             The concept of FA is mentioned for SDH/SONET in 
> > gmpls-sdh
> > > -sonet draft. It says that if u have a HOVC trail as a FA 
> > (advertized
> > > as a link) then u can allocate the lower level signals in 
> > it by making
> > > the higher bits of label as 0s (i.e. S and U}. This is fine 
> > for the same
> > > technology. What about the case where the TDM LSP has to 
> be tunneled
> > through
> > > the Lambda LSP ? What will be the form of label (i.e. 
> > {SUKLM} or lambda
> > > etc.) ?
> > > 
> > > Regards,
> > > manoj.
> > > 
> > > >From: Maarten Vissers <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: Lambda LSP establishment
> > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > >
> > > >Manoj,
> > > >
> > > >You refer to one wavelength to be available between A-E without
> > wavelength
> > > >conversion capability. This suggests that you operate at 
> > the OCh layer
> > > >network.
> > > >Then you specify the capacity of the 4 OCh link 
> > connections (A-B, B-C,
> > C-D,
> > > >D-E)
> > > >to be "C". Say that C is about 10 Gbit/s. You then assume 
> > that there is a
> > > >request for an OCh signal with capacity C/4 (e.g. 2.5 
> > Gbit/s) between C
> > and
> > > >E.
> > > >The result is that the OCh link connections C-D and D-E 
> > are transporting
> > > >the OCh
> > > >signal (of e.g. 2.5G). These OCh link connections are now 
> > in service and
> > > >not
> > > >longer available to an other OCh connection request. I.e. 
> > a request for
> > an
> > > >OCh
> > > >connection between A and E will be rejected.
> > > >
> > > >FAs are not applicable in the circuit layers. IF there is 
> > a trail in
> > server
> > > >layer X, then there is a link in its client layer Y. X and 
> > Y are thus
> > > >different
> > > >layer networks and signals.
> > > >
> > > >If C-E is a "FA", then in an OTN the C-E connection would 
> > be an OCh trail
> > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > connection.
> > > >
> > > >Note a FA in MPLS creates essentially a MPLS sublayer 
> > network. Such is
> > not
> > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > >
> > > >Regards,
> > > >
> > > >Maarten
> > > >
> > > >OCh link connections
> > > >
> > > >manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >         If I have 5 nodes A, B, C, D and E connected as 
> > shown. Assume
> > > > > that only one wavelength is available on the path A to E (no
> > wavelength
> > > > > conversion capability is there on the complete path). 
> > Let the capacity
> > > > > of the wavelength be C. Further assume a request arrives for
> > connection
> > > > > from node C to E for a line capacity of C/4. This 
> > request will be
> > > > > successful as we have available wavelength. Now If 
> > another request
> > > > > comes at node A to establish another connection from 
> > node A to node E
> > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. 
> > Should this request
> > > > > be successful as we have already allocated the wavelength ?
> > > > >
> > > > > If the previous connection from C to E of capacity 
> C/4 had been
> > > > > advertised as a FA, in that case will the IInd 
> request succeed ?
> > > > >
> > > > > If the previous connection from C to E of capacity C/4 
> > had not been
> > > > > advertised as FA then what will be the fate of IInd 
> connection ?
> > > > >
> > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > 
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > > >http://explorer.msn.com/intl.asp
> > > ><< mvissers.vcf >>
> > > 
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: 
> http://mobile.msn.com
> 

Delivery-date: Mon, 07 Jan 2002 07:37:57 -0800
From: Randy Bush <[email-masked]>
To: Scott  Bradner <[email-masked]>
Cc: [email-masked]
Subject: Re: sub-ip list and draft sub-ip session minutes
Date: Mon, 07 Jan 2002 07:37:35 -0800

>   To find the posting about the minutes, pls point your
>   web browser to: ftp://ftp.psg.com/pub/lists/subip-area.current

and/or <http://psg.com/lists/ccamp/ccamp.2002/>

randy

Envelope-to: [email-masked]
Delivery-date: Mon, 07 Jan 2002 07:32:45 -0800
Date: Mon, 7 Jan 2002 10:30:01 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: sigh - was sub-ip list and draft sub-ip session minutes

there is some messup with teh subip-area list - I'm trying to get it
resolved

Scott

Delivery-date: Mon, 07 Jan 2002 06:52:50 -0800
Date: Mon, 7 Jan 2002 08:56:06 -0500 (EST)
From: Scott  Bradner <[email-masked]>
To: [email-masked]
Subject: sub-ip list and draft sub-ip session minutes

  We have posted the draft minutes of the SUB-IP Area
  open meeting to [email-masked] - please comment on the
  draft minutes (for example correct what they have you saying)
  by Jan 11 at 8pm EST

  To subscribe to the subip list send email to: [email-masked]
  in message body: subscribe subip-area

  To find the posting about the minutes, pls point your
  web browser to: ftp://ftp.psg.com/pub/lists/subip-area.current

  Thanks
	Scott & Bert

Delivery-date: Sun, 06 Jan 2002 19:24:01 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Notify Message structure Issue
Date: Sun, 06 Jan 2002 20:21:51 -0700

Hi All,
        In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, the
downstream notify session is defined as a part of notify session
list (in notify message). The Style should also be present before flow
descriptor list and should be mandatory.

Please correct me if I am wrong.

Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Sun, 06 Jan 2002 17:53:05 -0800
Date: Mon, 07 Jan 2002 10:46:42 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked]
Subject: (FYI) draft-suemura-protection-hierarchy-00

Dear all,

I have posted the following I-D regarding protection/restoration of
hierarchical LSPs.
I would appreciate any comments.

Thank you.

----- Forwarded -----

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

	Title		: Protection of Hierarchical LSPs
	Author(s)	: Y. Suemura, A. Kolarov, T. Shiragaki
	Filename	: draft-suemura-protection-hierarchy-00.txt
	Pages		: 
	Date		: 03-Jan-02
	
In this document, we propose two different mechanisms for protection 
of hierarchical LSPs.  We assume that an hierarchical LSP traverses a 
network that is partitioned into multiple smaller, non-overlapping 
subnetworks.  Protection of the hierarchical LSP can be realized 
through two mechanisms: 1)Subnetwork Protection and 2)End-to-end 
Protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-suemura-protection-hierarchy-00.txt

-----------------------------------------------------------------
Yoshihiko SUEMURA 

Networking Research Laboratories, 
NEC Corporation

Delivery-date: Fri, 04 Jan 2002 13:32:47 -0800
Date: Fri, 04 Jan 2002 16:16:21 -0500
To: Dimitri Papadimitriou <[email-masked]>
From: Baktha Muralidharan <[email-masked]>
Subject: Re: Node and CC ID types in LMP
Cc: [email-masked], Srinivasa Datari <[email-masked]>, [email-masked], [email-masked]

Hi Dimitri,

          Thanks for pointing out that Node ID, per OIF UNI,
         needs to be either IPv4 or IPv6.  I probably got mixed
         up with connection end-point, which can be TNA
         (and hence NSAP).

         I am a bit confused however, about how a CC ID is
         then packed into LMP control messages; with just
         a c-type of 1, how will the neighbor interpret the
         CC ID?

Thanks,

/Baktha

At 09:56 PM 1/4/2002 +0100, Dimitri Papadimitriou wrote:
>Bakhta,
>
>OIF's UNI allows for (IP) CCID to be either unnumbered (Node ID &
>IF_Index) or numbered and allows for Node ID (ie UNI-C or UNI-N ID)
>to be either IPv4 (or IPv6 but let for next UNI version(s)). So I
>don't know where you found that the Node ID can be an NSAP in
>this doc...
>
>Per OIF UNI:
>"An IPCC may be numbered, in which case it is identified by an IPv4
>address at each end. If it is unnumbered then it is identified by the
>combination of the Node ID and an interface index at each end. In the
>case of numbered IPCC, migration to IPv6 addressing will depend on the
>proliferation of IPv6 capable UNI-C and UNI-N nodes."
>
>[...]
>
>"Under UNI 1.0, the Node ID is an IPv4 address, which must be unique
>within the domain of operation of the communicating UNI-C and UNI-N
>nodes." [...] "Migration to IPv6 addressing for the Node ID will depend
>on the proliferation of IPv6 capable UNI-C and UNI-N nodes".
>
>So numbered IPCC would have (for future UNI version) to encompass
>IPv6 addressing as well.
>
>However, in LMP I-D, one defines the CCID as follows:
>" Rather, a node-wide unique 32-bit non-zero integer control channel
>identifier (CCId) is assigned at each end of the control channel. This
>identifier comes from the same space as the unnumbered interface Id."
>
>Therefore only the Node_ID would need to allow IPv6 in addition to what
>is currently defined in LMP I-D.
>
>Cheers,
>- dimitri.
>
>Baktha Muralidharan wrote:
> >
> > Jonathan
> >         As you are preparing to update the LMP draft,  could please
> >         consider the following ?
> >
> >         Per the draft-ietf-ccamp-lmp-02 draft, CC ID and Node ID
> >         can only of  one type (c-type = 1). OIF's OUNI however allows
> >         for CC ID to be either unnumbered or numbered (IPv4, I assume)
> >         and allows for node IDs to be of one of  IPv4/IPv6/NSAP types.
> >
> >         Given that OUNI points to the CCAMP LMP, I would think that we
> >         would want to allow for them?
> >
> > Thanks
> >
> > /Baktha

Delivery-date: Fri, 04 Jan 2002 13:08:49 -0800
Date: Fri, 04 Jan 2002 21:56:29 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Baktha Muralidharan <[email-masked]>
CC: [email-masked], Srinivasa Datari <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Node and CC ID types in LMP

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

Bakhta,

OIF's UNI allows for (IP) CCID to be either unnumbered (Node ID &
IF_Index) or numbered and allows for Node ID (ie UNI-C or UNI-N ID)
to be either IPv4 (or IPv6 but let for next UNI version(s)). So I 
don't know where you found that the Node ID can be an NSAP in 
this doc... 

Per OIF UNI:
"An IPCC may be numbered, in which case it is identified by an IPv4 
address at each end. If it is unnumbered then it is identified by the 
combination of the Node ID and an interface index at each end. In the 
case of numbered IPCC, migration to IPv6 addressing will depend on the 
proliferation of IPv6 capable UNI-C and UNI-N nodes."

[...]

"Under UNI 1.0, the Node ID is an IPv4 address, which must be unique 
within the domain of operation of the communicating UNI-C and UNI-N 
nodes." [...] "Migration to IPv6 addressing for the Node ID will depend 
on the proliferation of IPv6 capable UNI-C and UNI-N nodes".

So numbered IPCC would have (for future UNI version) to encompass 
IPv6 addressing as well.

However, in LMP I-D, one defines the CCID as follows:
" Rather, a node-wide unique 32-bit non-zero integer control channel 
identifier (CCId) is assigned at each end of the control channel. This 
identifier comes from the same space as the unnumbered interface Id."  

Therefore only the Node_ID would need to allow IPv6 in addition to what
is currently defined in LMP I-D. 

Cheers,
- dimitri.

Baktha Muralidharan wrote:
> 
> Jonathan
>         As you are preparing to update the LMP draft,  could please
>         consider the following ?
> 
>         Per the draft-ietf-ccamp-lmp-02 draft, CC ID and Node ID
>         can only of  one type (c-type = 1). OIF's OUNI however allows
>         for CC ID to be either unnumbered or numbered (IPv4, I assume)
>         and allows for node IDs to be of one of  IPv4/IPv6/NSAP types.
> 
>         Given that OUNI points to the CCAMP LMP, I would think that we
>         would want to allow for them?
> 
> Thanks
> 
> /Baktha
--------------1DE6C271CD35EC950A8B8DCC
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 NA (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

--------------1DE6C271CD35EC950A8B8DCC--

Delivery-date: Fri, 04 Jan 2002 11:44:43 -0800
Date: Fri, 04 Jan 2002 14:31:50 -0500
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Node and CC ID types in LMP
Cc: Srinivasa Datari <[email-masked]>, [email-masked], [email-masked]

--=====================_27207111==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Jonathan
         As you are preparing to update the LMP draft,  could please
         consider the following ?

         Per the draft-ietf-ccamp-lmp-02 draft, CC ID and Node ID
         can only of  one type (c-type = 1). OIF's OUNI however allows
         for CC ID to be either unnumbered or numbered (IPv4, I assume)
         and allows for node IDs to be of one of  IPv4/IPv6/NSAP types.

         Given that OUNI points to the CCAMP LMP, I would think that we
         would want to allow for them?

Thanks

/Baktha

--=====================_27207111==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Jonathan<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>As you are
preparing to update the LMP draft,&nbsp; could please<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>consider
the following ?<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Per the
<font face="Courier New, Courier">draft-ietf-ccamp-lmp-02 draft,
</font>CC ID and Node ID<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>can only
of&nbsp; one type (c-type = 1). OIF's OUNI however allows<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>for CC ID
to be either unnumbered or numbered (IPv4, I assume)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>and allows
for node IDs to be of one of&nbsp; IPv4/IPv6/NSAP types.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Given that
OUNI points to the CCAMP LMP, I would think that we<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>would want
to allow for them?<br>
<br>
Thanks<br>
<br>
/Baktha<br>
<br>
<br>
<br>
</html>

--=====================_27207111==_.ALT--

Delivery-date: Fri, 04 Jan 2002 08:38:44 -0800
From: Randy Bush <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, [email-masked]
Subject: Re: protection and restoration [was: Re: Moving right along ...   generalized-signaling-06]
Date: Fri, 04 Jan 2002 08:29:23 -0800

> You keep amazing me...

ok children, CUT IT OUT!  sheesh!

it's bad enough that you drag issues which i still think belong over in
itu-land into the ietf.  but, if you insist on doing so, could you please
be civil about it?

randy, with ad hat on

Delivery-date: Fri, 04 Jan 2002 08:33:14 -0800
To: Maarten Vissers <[email-masked]>
cc: "Mannie, Eric" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: Lambda LSP establishment 
Date: Fri, 04 Jan 2002 08:26:09 -0800
From: Yakov Rekhter <[email-masked]>

Maarten,

> Eric,
> 
> In a parallel discussion it was concluded that an IETF FA is equivalent to a
> G.805 link. And within ASON, routing adjacencies are over G.805 links... i.e.
> over an FA in IETF terms.
> 
> I believe that we are hitting here a major difference between GMPLS and ASON
> (and between GMPLS and existing management plane based connection management
> (eMPbCM)).
> 
> ASON (and eMPbCM) establish layer network X routing adjacencies between two
> layer network X switches which share (i.e. are at the two ends of) a G.805 
> layer network X link.
> 
> GMPLS establishes routing adjacencies between two equipment which share a
> physical medium (e.g. fiber).

That is certainly *a* way to establish routing adjacencies in GMPLS.
But not the *only way possible*, as GMPLS does *not* restrict
routing adjacencies to only "two equipment which share a physical
medium".
  
> This difference in my current understanding may prevent interworking 
> between an ASON/eMPbCM network and a GMPLS network.
> 
> Looking at the document introducing the FA concept
> (draft-ietf-mpls-lsp-hierarchy), I noticed that it is a MPLS document and not
> a GMPLS document... 

That is correct - it is an MPLS WG document. So what ?

> the document defines a MPLS FA.

That is correct - the document does define an MPLS FA.

> A MPLS FA is equivalent to a MPLS serial compound link (G.805); i.e. a serial

Please note that in the MPLS terminology there is no such thing
as "MPLS serial compound link".

> concatenation of MPLS links (G.805 terminology). The optical network FA (e.g.
> a VC-4 FA supporting a VC-12 link) is different as it represents a server 
> layer trail supporting a (single hop) link in the layer network of interest.
> 
> The MPLS link (G.805) between two adjacent MPLS LSRs is already a (optical
> network) FA (ON-FA). And two MPLS LSRs have no doubt a routing adjacency, but
> as indicated this adjacency is via an ON-FA... so my conclusion is that
> routing adjacencies are also over FAs.

First note that for the purpose of control there are routing
adjacencies (used for exchanging ISIS/OSPF Hellos and for Link
State flooding), and there are signaling adjacencies (used for
RSVP/CR-LDP signaling). And the presense of signaling adjacency
between a pair of LSRs doesn't imply that there is a routing
adjacency between these two LSRs.

Second node that even if two LSRs have an FA (or a link) between
then, it doesn't follow that routing adjacency *have to* be
established over this FA (or that link). In fact, there may not be
a routing adjacency between these two LSRs in the first place.

Yakov.

Delivery-date: Fri, 04 Jan 2002 07:59:27 -0800
From: John Drake <[email-masked]>
To: 'Maarten Vissers ' <[email-masked]>, "'Mannie, Eric '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: protection and restoration [was: Re: Moving right along ...   generalized-signaling-06]
Date: Fri, 4 Jan 2002 07:55:45 -0800 

Maarten,

Yes

Yes

Yes.  If two GMPLS nodes are connected with a protected link across a
SONET/SDH network, then they would simply take advantage of it.  Similarly,
some pre-OTN DWDM line systems provide the same protection capabilities and
again, the GMPLS nodes would simply take advantage of them.  As an aside,
it's becoming clear to me that we need another term to replace 'pre-OTN',
since 'pre-OTN' networks will continue to evolve in parallel with 'OTN'
networks.

Thanks,

John 

-----Original Message-----
From: Maarten Vissers
To: Mannie, Eric
Cc: [email-masked]
Sent: 1/4/2002 7:26 AM
Subject: Re: protection and restoration [was: Re: Moving right along ...
generalized-signaling-06]

Eric,

You keep amazing me... I ask a simple technical question concerning a
requirement for fast restoration, which I would have expected a Yes/No
answer
for. I then asked as second technical question concerning the the
interpretation
of fast protection, which also could have been answered by Yes/No. Then
assuming
a Yes on the second answer I ask a third technical question on the scope
of fast
restoration, which could also be answered by Yes or No. Instead of 3
simple
Yes/No answers I received an email with several accusations :-( ... I
still hope
I will receive answers on my simple questions. Would be appreciated.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Maarten,
> 
> This is too big this time, usually you are more subtle :-)
> 
> Last attempt to convince everybody that GMPLS is for pre-OTN only and
G.ASON
> for OTN ?
> 
> So that GMPLS becomes a secondary and temporary control plane until we
have
> a G.ASON based ITU-T control plane that will be used for everything
(and
> that we will have in several years) :-)))
> 
> I liked your speech during the IESG plenary when you said that the
"GMPLS
> work just started in CCAMP" and when you presented G.ASON as almost
> finished. From an honest perspective, it is exactly the opposite.
> 
> Since one cannot stop GMPLS, let's try to reduce the scope :-)))
> 
> You complained so many times that nobody is actively proposing GMPLS
at the
> ITU-T. If you could have spent the same energy that you are spending
here
> against GMPLS, rather proposing GMPLS at the ITU-T... The entire
community
> could have saved a lot of time and energy (or at least people on this
> mailing list :-)))
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 2:25 PM
> To: Mannie, Eric
> Cc: [email-masked]
> Subject: protection and restoration [was: Re: Moving right along ...
> generalized-signaling-06]
> 
> Eric,
> 
> One of the requirements we have to meet is that traffic of user A is
not
> delivered to user B. Also during recovery from a failed connection
(either
> by
> means of protection swithcing, or restoration) we have to guarantee
that
> user A
> traffic is not delivered to user B. This adds additional requirements
to the
> operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc
> architectures;
> these have a potential to temporarily connect A to B.
> 
> In protection switching this is guaranteed by means of the combination
of
> protection architecture and protection switching protocol type
(1-phase,
> 2-phase, 3-phase protocols).
> The tail end normal output #i of the protected domain will never
select from
> the
> protection connection until it is guaranteed that normal input #i at
the
> head
> end is bridged onto this protection connection. And vice versa, the
tail end
> will deselect the protection connection before the head end will put a
> different
> signal onto that protection connection.
> 
> I assume that for the case of restoration and fast restoration, the
same
> requirement is applicable. Has this requirement been considered in the
work
> on
> fast restoration?
> 
> It looks like "fast restoration" is a control plane based protection
> switching.
> Is my understanding correct?
> 
> If so, with transport plane based protection switching build into
SDH/SONET
> and
> OTN, is fast restoration being a pre-OTN feature? I assume there is no
need
> to
> replace SDH/SONET/OTN transport plane based protection switching by
control
> plane based protection switching.
> As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection
switching
> defined in the transport plane, pre-OTN has no alternative to control
plane
> based protection.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hello Stephen,
> >
> > John refers to fast restoration schemes that are being studied at
the
> IETF.
> > Such schemes are widely implemented in the new classes of
optical/TDM
> > equipments.
> >
> > The wording of the text just need to use the terms "working" LSP and
> > "protecting" LSP, instead of primary and secondary. That's just an
editing
> > modification.
> >
> > The bit itself is useful to qualify the LSP being established.
> >
> > The mechanisms to be applied to this qualification will be detailed
in
> other
> > documents.
> >
> > In the mean time, I guess that this bit can be used by
implementations for
> a
> > simple restoration scheme (e.g. first establish working and
protecting
> LSPs,
> > resources of protecting LSP may be "soft reserved", i.e. for
> extra-traffic,
> > when a fault occur send an RSVP-TE rapid failure notification to the
> source,
> > send Path with bit set to "working" on protecting LSP, this kills
all LSPs
> > using these resources, when acked switch to this LSP).
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 7:38 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > The problem here is that this is not compatible with transport plane
> > protection.
> > Assume you do 1:n MSP protection according to ITU Rec. G.841. The
> operation
> > of
> > the protection group is controlled by exchange of the K1, K2 bytes
in the
> > MSOH of the PROTECTION MS. If the control plane reuses the
protection MS
> at
> > for a different LSP at a time when the state of the protection group
is
> > "No Request" (assuming no extra traffic carried on the protection
section
> in
> > the
> > transport plane), this disables the protection since the endpoints
of the
> > protection group are no longer able to exchange K1, K2 over the
protection
> > channel. Even though the payload is unused and irrelevant to the
transport
> > plane at this point, the exchange of overhead is essential to proper
> > operation
> > of the protection group.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Steven,
> > >
> > > The basic idea is that if a connection is of type 'secondary',
then
> other
> > > LSPs of type 'primary' between the same or different
source/destination
> > > pairs MAY use its resources in intermediate nodes, until that LSP
is
> > > converted into a 'primary' with a subsequent Path/Resv flow.  At
this
> > point,
> > > other LSPs that were using its resources may get pre-empted.
Think of
> the
> > > primary/secondary mechanism as a way to ensure temporal priority
while
> > > allowing network resources to be re-used; i.e., an LSP of type
> 'secondary'
> > > is carrying no data.
> > >
> > > So in the 1:1 case the protect LSP could be established either as
a
> > primary
> > > or secondary LSP, while in the 1:N case the protect LSP would be
> > established
> > > as a secondary.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 PM
> > > To: John Drake
> > > Cc: Maarten Vissers; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > John,
> > > It would seem from this standpoint, ANY transport plane protection
> > > must use "primary" for all trails. You have already made this
argument
> > > for the 1+1 case to carry the permanently bridged copy of the
payload.
> > >
> > > In 1:1 or 1:n, when protection is not being used to carry one/any
of
> > > the normal traffic signals, it may either carry a null signal (no
> bridge)
> > > or transport plane extra traffic. Even if the transport plane has
only
> > > a null signal on protection, the control plane cannot itself place
extra
> > > traffic on any portion of the end-to-end protection channel as
this is
> > > where the APS protocol is carried to coordinate the 1:1 or 1:n
> protection.
> > > The protection channel overhead is chosen to carry the APS since
it is
> > > necessary to exchange APS bytes to complete a switch when working
> channels
> > > are failed. If the protection channel has failed and APS cannot be
> > > exchanged,
> > > normal traffic signals will not be selected from protection.
> > > Regards,
> > > Steve
> > >
> > > John Drake wrote:
> > > >
> > > > Maarten,
> > > >
> > > > That's fine, however it's beside the point.  The semantics of
> > > > Primary/Secondary refer to the control plane and whether the
node
> > > > establishing a given LSP is planning to use it at the time it's
> > > established
> > > > or at a later time.  As I indicated in an earlier note, 1+1
transport
> > > plane
> > > > protection would be accomplished in the control plane by
establishing
> > two
> > > > LSPs of type Primary.  The control plane really doesn't care
which LSP
> > the
> > > > transport plane is using as Working and which as Protect,
although
> that
> > > > information is available to the control plane at the LSP
endpoints.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Maarten Vissers [mailto:[email-masked]]
> > > > Sent: Thursday, December 13, 2001 12:15 AM
> > > > To: [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > There exist well defined protection terminology in ITU-T for the
> > transport
> > > > plane. "Working" and "Protection" are being used and not
> > > primary/secondary.
> > > > E.g.
> > > > a 1+1 architecture has one working connection, one protection
> connection
> > > and
> > > > a
> > > > permanent bridge.
> > > >
> > > > Besides working/protection indication for the transport entity,
there
> is
> > > > - "active" and "standby" to indicate if the signal is selected
from
> the
> > > > working
> > > > or protection transport entity; i.e. if selector selects from
working,
> > the
> > > > working is active and protection is standby, if the selector
selects
> > from
> > > > protection the working is standby and the protection is active.
> > > > - "normal" and "extra traffic" signal. The normal signal is
protected.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > [email-masked] wrote:
> > > > >
> > > > > Jonathan....review the text below....I think the problem is
1:1.
> > > > >
> > > > > neil
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > > Sent: 12 December 2001 17:46
> > > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > Ben,
> > > > > >   Please see inline.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > > To: John Drake
> > > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ...
generalized-signaling-06
> > > > > > >
> > > > > > >
> > > > > > > See comment below.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ben
> > > > > > >
> > > > > > > John Drake wrote:
> > > > > > > >
> > > > > > > > Snipped
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > > To: Lou Berger
> > > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > > Subject: Re: Moving right along ...
generalized-signaling-06
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >7) In Protection Information it states "The resources
> > > > > > > allocated for a
> > > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > > primary LSP fails
> > > > > > > > > >    over to the secondary LSP."  This may not always
be
> > > > > > > the case.  An
> > > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > > traffic may use the
> > > > > > > > > >    secondary path resources is needed.
> > > > > > > > >
> > > > > > > > > ??? This is the purpose of this bit.
> > > > > > > >
> > > > > > > > This is not clear from the definition.  The bit is
defined
> > > > > > > as indicating
> > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > > protection the
> > > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > > >
> > > > > > > > Perhaps the problem here is that protection features are
> > > > > > > being defined
> > > > > > > > before the protection framework and requirements are
> > > > > > done.  Is this
> > > > > > > > presupposing some particular outcome of the recovery
work in
> > CAMP?
> > > > > > > >
> > > > > > > > JD:  I think the definition of the bit is fine.  For
both
> > > > > > > 1+1 and 1:1
> > > > > > > > protection, there would be a pair of Primary LSPs
between
> > > > > > the source
> > > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > > >
> > > > > > > This is an unusual use of terms.  I have never encountered
a
> case
> > > > > > > where both the working and recovery paths are call
"primary."
> > > > > > >
> > > > > > > This is not consistent with either
draft-mpls-recovery-framework
> > > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign
that
> > the
> > > > > > > protection work is immature and not ready for progressing
to
> RFC.
> > > > > > >
> > > > > > For 1+1 path protection, both working/recovery paths are
> > > > > > carrying user data
> > > > > > traffic and it is an endpoint decision as to which path is
> > > > > > actually the
> > > > > > working/recovery path.  At a transit node, both paths need
to
> > > > > > be treated as
> > > > > > primary, as the resources are currently being used and
> > > > > > obviously can't be
> > > > > > used for Extra Traffic.
> > > > > >
 <<Card for Maarten Vissers>> 

Delivery-date: Fri, 04 Jan 2002 07:31:24 -0800
Cc: [email-masked]
Date: Fri, 04 Jan 2002 16:26:38 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: [email-masked]
Subject: Re: protection and restoration [was: Re: Moving right along ...   generalized-signaling-06]

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

Eric,

You keep amazing me... I ask a simple technical question concerning a
requirement for fast restoration, which I would have expected a Yes/No answer
for. I then asked as second technical question concerning the the interpretation
of fast protection, which also could have been answered by Yes/No. Then assuming
a Yes on the second answer I ask a third technical question on the scope of fast
restoration, which could also be answered by Yes or No. Instead of 3 simple
Yes/No answers I received an email with several accusations :-( ... I still hope
I will receive answers on my simple questions. Would be appreciated.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Maarten,
> 
> This is too big this time, usually you are more subtle :-)
> 
> Last attempt to convince everybody that GMPLS is for pre-OTN only and G.ASON
> for OTN ?
> 
> So that GMPLS becomes a secondary and temporary control plane until we have
> a G.ASON based ITU-T control plane that will be used for everything (and
> that we will have in several years) :-)))
> 
> I liked your speech during the IESG plenary when you said that the "GMPLS
> work just started in CCAMP" and when you presented G.ASON as almost
> finished. From an honest perspective, it is exactly the opposite.
> 
> Since one cannot stop GMPLS, let's try to reduce the scope :-)))
> 
> You complained so many times that nobody is actively proposing GMPLS at the
> ITU-T. If you could have spent the same energy that you are spending here
> against GMPLS, rather proposing GMPLS at the ITU-T... The entire community
> could have saved a lot of time and energy (or at least people on this
> mailing list :-)))
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 2:25 PM
> To: Mannie, Eric
> Cc: [email-masked]
> Subject: protection and restoration [was: Re: Moving right along ...
> generalized-signaling-06]
> 
> Eric,
> 
> One of the requirements we have to meet is that traffic of user A is not
> delivered to user B. Also during recovery from a failed connection (either
> by
> means of protection swithcing, or restoration) we have to guarantee that
> user A
> traffic is not delivered to user B. This adds additional requirements to the
> operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc
> architectures;
> these have a potential to temporarily connect A to B.
> 
> In protection switching this is guaranteed by means of the combination of
> protection architecture and protection switching protocol type (1-phase,
> 2-phase, 3-phase protocols).
> The tail end normal output #i of the protected domain will never select from
> the
> protection connection until it is guaranteed that normal input #i at the
> head
> end is bridged onto this protection connection. And vice versa, the tail end
> will deselect the protection connection before the head end will put a
> different
> signal onto that protection connection.
> 
> I assume that for the case of restoration and fast restoration, the same
> requirement is applicable. Has this requirement been considered in the work
> on
> fast restoration?
> 
> It looks like "fast restoration" is a control plane based protection
> switching.
> Is my understanding correct?
> 
> If so, with transport plane based protection switching build into SDH/SONET
> and
> OTN, is fast restoration being a pre-OTN feature? I assume there is no need
> to
> replace SDH/SONET/OTN transport plane based protection switching by control
> plane based protection switching.
> As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching
> defined in the transport plane, pre-OTN has no alternative to control plane
> based protection.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hello Stephen,
> >
> > John refers to fast restoration schemes that are being studied at the
> IETF.
> > Such schemes are widely implemented in the new classes of optical/TDM
> > equipments.
> >
> > The wording of the text just need to use the terms "working" LSP and
> > "protecting" LSP, instead of primary and secondary. That's just an editing
> > modification.
> >
> > The bit itself is useful to qualify the LSP being established.
> >
> > The mechanisms to be applied to this qualification will be detailed in
> other
> > documents.
> >
> > In the mean time, I guess that this bit can be used by implementations for
> a
> > simple restoration scheme (e.g. first establish working and protecting
> LSPs,
> > resources of protecting LSP may be "soft reserved", i.e. for
> extra-traffic,
> > when a fault occur send an RSVP-TE rapid failure notification to the
> source,
> > send Path with bit set to "working" on protecting LSP, this kills all LSPs
> > using these resources, when acked switch to this LSP).
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 7:38 PM
> > To: John Drake
> > Cc: Maarten Vissers; [email-masked]
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > The problem here is that this is not compatible with transport plane
> > protection.
> > Assume you do 1:n MSP protection according to ITU Rec. G.841. The
> operation
> > of
> > the protection group is controlled by exchange of the K1, K2 bytes in the
> > MSOH of the PROTECTION MS. If the control plane reuses the protection MS
> at
> > for a different LSP at a time when the state of the protection group is
> > "No Request" (assuming no extra traffic carried on the protection section
> in
> > the
> > transport plane), this disables the protection since the endpoints of the
> > protection group are no longer able to exchange K1, K2 over the protection
> > channel. Even though the payload is unused and irrelevant to the transport
> > plane at this point, the exchange of overhead is essential to proper
> > operation
> > of the protection group.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Steven,
> > >
> > > The basic idea is that if a connection is of type 'secondary', then
> other
> > > LSPs of type 'primary' between the same or different source/destination
> > > pairs MAY use its resources in intermediate nodes, until that LSP is
> > > converted into a 'primary' with a subsequent Path/Resv flow.  At this
> > point,
> > > other LSPs that were using its resources may get pre-empted.  Think of
> the
> > > primary/secondary mechanism as a way to ensure temporal priority while
> > > allowing network resources to be re-used; i.e., an LSP of type
> 'secondary'
> > > is carrying no data.
> > >
> > > So in the 1:1 case the protect LSP could be established either as a
> > primary
> > > or secondary LSP, while in the 1:N case the protect LSP would be
> > established
> > > as a secondary.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Thursday, December 13, 2001 12:15 PM
> > > To: John Drake
> > > Cc: Maarten Vissers; [email-masked]
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > John,
> > > It would seem from this standpoint, ANY transport plane protection
> > > must use "primary" for all trails. You have already made this argument
> > > for the 1+1 case to carry the permanently bridged copy of the payload.
> > >
> > > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > > the normal traffic signals, it may either carry a null signal (no
> bridge)
> > > or transport plane extra traffic. Even if the transport plane has only
> > > a null signal on protection, the control plane cannot itself place extra
> > > traffic on any portion of the end-to-end protection channel as this is
> > > where the APS protocol is carried to coordinate the 1:1 or 1:n
> protection.
> > > The protection channel overhead is chosen to carry the APS since it is
> > > necessary to exchange APS bytes to complete a switch when working
> channels
> > > are failed. If the protection channel has failed and APS cannot be
> > > exchanged,
> > > normal traffic signals will not be selected from protection.
> > > Regards,
> > > Steve
> > >
> > > John Drake wrote:
> > > >
> > > > Maarten,
> > > >
> > > > That's fine, however it's beside the point.  The semantics of
> > > > Primary/Secondary refer to the control plane and whether the node
> > > > establishing a given LSP is planning to use it at the time it's
> > > established
> > > > or at a later time.  As I indicated in an earlier note, 1+1 transport
> > > plane
> > > > protection would be accomplished in the control plane by establishing
> > two
> > > > LSPs of type Primary.  The control plane really doesn't care which LSP
> > the
> > > > transport plane is using as Working and which as Protect, although
> that
> > > > information is available to the control plane at the LSP endpoints.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Maarten Vissers [mailto:[email-masked]]
> > > > Sent: Thursday, December 13, 2001 12:15 AM
> > > > To: [email-masked]
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > There exist well defined protection terminology in ITU-T for the
> > transport
> > > > plane. "Working" and "Protection" are being used and not
> > > primary/secondary.
> > > > E.g.
> > > > a 1+1 architecture has one working connection, one protection
> connection
> > > and
> > > > a
> > > > permanent bridge.
> > > >
> > > > Besides working/protection indication for the transport entity, there
> is
> > > > - "active" and "standby" to indicate if the signal is selected from
> the
> > > > working
> > > > or protection transport entity; i.e. if selector selects from working,
> > the
> > > > working is active and protection is standby, if the selector selects
> > from
> > > > protection the working is standby and the protection is active.
> > > > - "normal" and "extra traffic" signal. The normal signal is protected.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > [email-masked] wrote:
> > > > >
> > > > > Jonathan....review the text below....I think the problem is 1:1.
> > > > >
> > > > > neil
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > > Sent: 12 December 2001 17:46
> > > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > Ben,
> > > > > >   Please see inline.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > > To: John Drake
> > > > > > > Cc: Lou Berger; Kireeti Kompella; [email-masked]
> > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > >
> > > > > > >
> > > > > > > See comment below.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ben
> > > > > > >
> > > > > > > John Drake wrote:
> > > > > > > >
> > > > > > > > Snipped
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ben Mack-Crane [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > > To: Lou Berger
> > > > > > > > Cc: Kireeti Kompella; [email-masked]
> > > > > > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >7) In Protection Information it states "The resources
> > > > > > > allocated for a
> > > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > > primary LSP fails
> > > > > > > > > >    over to the secondary LSP."  This may not always be
> > > > > > > the case.  An
> > > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > > traffic may use the
> > > > > > > > > >    secondary path resources is needed.
> > > > > > > > >
> > > > > > > > > ??? This is the purpose of this bit.
> > > > > > > >
> > > > > > > > This is not clear from the definition.  The bit is defined
> > > > > > > as indicating
> > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > > protection the
> > > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > > >
> > > > > > > > Perhaps the problem here is that protection features are
> > > > > > > being defined
> > > > > > > > before the protection framework and requirements are
> > > > > > done.  Is this
> > > > > > > > presupposing some particular outcome of the recovery work in
> > CAMP?
> > > > > > > >
> > > > > > > > JD:  I think the definition of the bit is fine.  For both
> > > > > > > 1+1 and 1:1
> > > > > > > > protection, there would be a pair of Primary LSPs between
> > > > > > the source
> > > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > > >
> > > > > > > This is an unusual use of terms.  I have never encountered a
> case
> > > > > > > where both the working and recovery paths are call "primary."
> > > > > > >
> > > > > > > This is not consistent with either draft-mpls-recovery-framework
> > > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign that
> > the
> > > > > > > protection work is immature and not ready for progressing to
> RFC.
> > > > > > >
> > > > > > For 1+1 path protection, both working/recovery paths are
> > > > > > carrying user data
> > > > > > traffic and it is an endpoint decision as to which path is
> > > > > > actually the
> > > > > > working/recovery path.  At a transit node, both paths need to
> > > > > > be treated as
> > > > > > primary, as the resources are currently being used and
> > > > > > obviously can't be
> > > > > > used for Extra Traffic.
> > > > > >
--------------54F984818987241C853DD722
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

--------------54F984818987241C853DD722--

Delivery-date: Fri, 04 Jan 2002 06:19:55 -0800
Cc: "[email-masked] '" <[email-masked]>
Date: Fri, 04 Jan 2002 15:15:23 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "[email-masked] '" <[email-masked]>
Subject: Re: Lambda LSP establishment

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

Eric,

In a parallel discussion it was concluded that an IETF FA is equivalent to a
G.805 link. And within ASON, routing adjacencies are over G.805 links... i.e.
over an FA in IETF terms.

I believe that we are hitting here a major difference between GMPLS and ASON
(and between GMPLS and existing management plane based connection management
(eMPbCM)).

ASON (and eMPbCM) establish layer network X routing adjacencies between two
layer network X switches which share (i.e. are at the two ends of) a G.805 layer
network X link.

GMPLS establishes routing adjacencies between two equipment which share a
physical medium (e.g. fiber).

This difference in my current understanding may prevent interworking between an
ASON/eMPbCM network and a GMPLS network.

Looking at the document introducing the FA concept
(draft-ietf-mpls-lsp-hierarchy), I noticed that it is a MPLS document and not a
GMPLS document... the document defines a MPLS FA.
A MPLS FA is equivalent to a MPLS serial compound link (G.805); i.e. a serial
concatenation of MPLS links (G.805 terminology). The optical network FA (e.g. a
VC-4 FA supporting a VC-12 link) is different as it represents a server layer
trail supporting a (single hop) link in the layer network of interest.

The MPLS link (G.805) between two adjacent MPLS LSRs is already a (optical
network) FA (ON-FA). And two MPLS LSRs have no doubt a routing adjacency, but as
indicated this adjacency is via an ON-FA... so my conclusion is that routing
adjacencies are also over FAs.

So if MPLS LSRs have routing adjacencies over ON-FAs, then VC-12 switches should
be able to have routing adjacencies over VC-12 links (G.805) which are VC-4 FAs
(IETF).

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Juergen,
> 
> We already discussed it so many times....
> 
> FAs and links are two different objects. No routing adjacency over an FA
> LSP. FAs are optional. You can route a VC-12 without having any FA. You can
> have mini dummy VC-4 "circuits" just between two adjacent LSRs (VC-4 POH
> terminated in two adjacent SDH/SONET nodes). These mini dummy VC-4 circuits
> will not be seen as customer circuits. They don't need to be seen as FAs.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Thursday, December 20, 2001 11:04 AM
> To: Mannie, Eric; Heiles Juergen; ''John Drake' '; 'Maarten Vissers ';
> 'manoj juneja '
> Cc: [email-masked] '
> Subject: RE: Lambda LSP establishment
> 
> Hi Eric,
> 
> thanks for the explanation below. I have some further questions for
> clarification and I also think an informational I-D would be helpful.
> 
> You said that from the routing point of view a link and an FA are two
> different things. There is a routing adjacency "over" a link but not over a
> FA.
> I don't see the difference between a "physical link" and a FA as routing can
> use both to establish a connection.
> Furthermore for the SDH case if a VC-12 connection is setup via an existing
> VC-4 connection the VC-4 connection is an FA according to my understanding.
> However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA,
> it is a link. Is this correct? From the VC-12 or VC-4 routing view point I
> don't see a difference between the FA or link. Furthermore the STM-16
> connection itself could be transported via an OCh or ODUk in a WDM system.
> So it is not the physical interface of the equipment. Is it still a link and
> no FA as from the physical topology only WDM (OTM-n) interfaces are seen.
> 
> Now concerning the setup of a VC-12 over a STM-16. In this case you use the
> full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3
> connection has to be established prior to the VC-12 connection. Is this
> implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists.
> Is it now seen as a FA?
> Lets have a look on two examples:
> 
> (1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC
> 
> (2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC
> 
> In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4
> switching are directly interconnected via a STM-16. In this case the VC-12
> label could be defined in relation to the STM-16 interface with the full
> SUKLM set. In the second example the two 4/1 cross-connects are
> interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do
> we need a VC-4 FA in this case between the two 4/1 cross-connects to setup
> the VC-12 connection?
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: Thursday, December 13, 2001 6:57 PM
> > To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj
> > juneja '
> > Cc: [email-masked] '
> > Subject: RE: Lambda LSP establishment
> >
> >
> > Hi All,
> >
> > A few comments,
> >
> > >In MPLS the FA establishes "virtual" layer networks. In
> > GMPLS the layer
> > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs,
> > OCh, OMS, OTS). A
> > FA basically corresponds to a real trail in a circuit
> > switched network.
> >
> > Eric: ...and this trail is setup dynamically using GMPLS. That's the
> > interest. One can think of SDH/SONET FAs as shortcuts or
> > express-routes.
> >
> > >One special thing about the SDH label is, that it includes a
> > hierarchy as
> > it identifies the lower order VC in a higher order VC in a
> > STM-N signal.
> > Note that this is somehow in contradiction with a statement
> > in the GMPLS
> > signaling document which says
> >
> > >"A Generalized Label only carries a single level of label,
> > i.e., it is
> >    non-hierarchical.  When multiple levels of label (LSPs
> > within LSPs)
> >    are required, each LSP must be established separately, see [MPLS-
> >    HIERARCHY]."
> >
> > No, hierarchy of labels is not hierarchy of layers. And even
> > one should have
> > a common definition of what means a "layer". This text says
> > that we cannot
> > have multiple embedded labels, e.g. one label containting a
> > label stack.
> > This is a signaling stuff that doesn't imply anything on the transport
> > plane.
> >
> > Now, a label identifies ONE LSP at an interface. This LSP can
> > be HO or LO in
> > SDH. The label can be fully specified or partially specified,
> > depending on
> > the context where the LSP is established.
> >
> > E.g. when an LSP is established over a FA, the highest part
> > of the LSP label
> > is not relevant. When the FA LSP is established the lowest
> > part of the FA
> > LSP label is not relevant.
> >
> > If a low order LSP is established without any higher order
> > FA, the label is
> > fully specified. As you said the link is indeed the "ultimate
> > FA" in that
> > case. Except that from the routing point of view a link and
> > an FA are two
> > different things. There is a routing adjacency "over" a link
> > but not over a
> > FA.
> >
> > The SDH/SONET label just includes what you need to include in
> > each scenario.
> >
> > Moreover, the label MUST be interpreted according to the type
> > of interface
> > for which it is used. It is possible to code two labels
> > having the same
> > value but a complete different meaning. Labels are context
> > sensitive of
> > course.
> >
> > For instance, an LSP over an STM-0 interface or over a FA
> > will have the
> > highest part set to zero, and could possibly have the same
> > lowest part. You
> > cannot understand what means the label without knowning the
> > detail of the
> > interface. In that case, the interface is either an STM-0
> > interface or a
> > VC-3 FA. And of course that FA and STM-0 interface are two
> > different things,
> > but from the LSP point of view, in both cases what it wants
> > is a VC-3 in
> > which it can be multiplexed.
> >
> > Hope this helps.
> >
> > I start to wonder if we should have an informational draft describing
> > different scenarios of SDH/SONET LSP establishment. That
> > could complement
> > the SDH/SONET signaling drafts and the GMPLS architecture.
> > That could solve
> > many terminology and modeling issues.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Heiles Juergen
> > To: 'John Drake'; Maarten Vissers; manoj juneja
> > Cc: [email-masked]
> > Sent: 12/13/01 11:15 AM
> > Subject: RE: Lambda LSP establishment
> >
> > Let me express my understanding of FAs in MPLS/GMPLS, please
> > correct me
> > if I am wrong. I have also some questions related to the label
> > generation and interactions between layer networks.
> >
> > The label in MPLS is local to the link between two adjacent MPLS
> > switches, it indicates a LSP in this link. This link is therefore the
> > ultimate FA. An already established LSP between two MPLS
> > switches, which
> > don't have to be adjacent, can be used to transport/tunnel other LSPs
> > between this two nodes. This already established LSP
> > generates a virtual
> > adjacency between the two nodes, the FA. As several LSPs can
> > use this FA
> > it is also a kind of virtual multiplexing.
> > If you compare it with a circuit switched network the FA is a server
> > layer trail that provides transport (a link connection) for
> > one or more
> > client layer signals.
> > In MPLS the FA establishes "virtual" layer networks. In GMPLS
> > the layer
> > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS,
> > OTS). A FA basically corresponds to a real trail in a circuit switched
> > network.
> > In GMPLS the label is also local to the link between the two devices
> > that perform the switching. For example for SDH the VC-N is identified
> > by the STM-N link/port and the SUKLM number according to
> > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is
> > identified by
> > the interface ID (I am not sure on this) and SUKLM is the SDH
> > label that
> > locates the VC within the STM-N.
> > From just the SDH viewpoint the STM-N connection is the
> > ultimate server
> > trail/FA. However the STM-N signal could be transported over a Optical
> > Channel or G.709 ODU. The OCh or ODU can already start in the
> > equipment
> > that performs the VC-N switching. So the STM-N signal is not the port,
> > but the WDM signal is the port and the STM-N signal makes use of a OCh
> > or ODU server layer trail. This server layer trail can be established
> > via management or using GMPLS.
> > Can someone explain how a label for a VC-4 is generated in this case
> > (pre-established OCh or ODU trail via management or setup
> > using GMPLS).
> > This interaction between the different technologies/labels need in my
> > view some further explanation.
> >
> > One special thing about the SDH label is, that it includes a hierarchy
> > as it identifies the lower order VC in a higher order VC in a STM-N
> > signal. Note that this is somehow in contradiction with a statement in
> > the GMPLS signaling document which says
> > "A Generalized Label only carries a single level of label, i.e., it is
> >    non-hierarchical.  When multiple levels of label (LSPs within LSPs)
> >    are required, each LSP must be established separately, see [MPLS-
> >    HIERARCHY]."
> > Following this statement each layer should have its own label
> > independent of server layers.
> > The combination of hierarchies in labels is based on technology (e.g.
> > SDH, Sonet, G.709 ODU) but has in my view no real technical
> > reason. The
> > SDH label for example fits to standard STM-N signals, but not
> > to sub-STM
> > signals.
> > For the SDH the full SUKLM number is used if a e.g. VC-12 is
> > located in
> > relation to a STM-N interface. If it is located in relation to a VC-4
> > (the VC-4 is in this case a FA) SUK are set to 0. For me it
> > is not clear
> > in which case I use the first and in which case I use the
> > second case as
> > a VC-4 trail is always needed for a VC-12 connection. This
> > VC-4 could be
> > established using management or GMPLS. However it should have no
> > influence on the label.
> > Some more information is needed in my view in this area.
> >
> >
> > Juergen
> >
> >
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: Wednesday, December 12, 2001 6:54 AM
> > > To: Maarten Vissers; manoj juneja
> > > Cc: [email-masked]
> > > Subject: RE: Lambda LSP establishment
> > >
> > >
> > > fortunately, this is just your opinion
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Tuesday, December 11, 2001 9:31 PM
> > > To: manoj juneja
> > > Cc: [email-masked]
> > > Subject: Re: Lambda LSP establishment
> > >
> > >
> > > Manoj,
> > >
> > > Forget the FA stuff, it is not appropriate in circuit
> > > networks. It only
> > > applies
> > > to MPLS. We should remove it when it is used in relation with PDH,
> > > SDH/SONET,
> > > OTN and pre-OTN. The text in sdh-sonet draft should state
> > > that if there is a
> > > LOVC link (IETF: link bundle/TE link) then the LOVC signals
> > > use a label with
> > > "00KLM".
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > manoj juneja wrote:
> > > >
> > > > Hi Marteen,
> > > >             The concept of FA is mentioned for SDH/SONET in
> > > gmpls-sdh
> > > > -sonet draft. It says that if u have a HOVC trail as a FA
> > > (advertized
> > > > as a link) then u can allocate the lower level signals in
> > > it by making
> > > > the higher bits of label as 0s (i.e. S and U}. This is fine
> > > for the same
> > > > technology. What about the case where the TDM LSP has to
> > be tunneled
> > > through
> > > > the Lambda LSP ? What will be the form of label (i.e.
> > > {SUKLM} or lambda
> > > > etc.) ?
> > > >
> > > > Regards,
> > > > manoj.
> > > >
> > > > >From: Maarten Vissers <[email-masked]>
> > > > >To: manoj juneja <[email-masked]>
> > > > >CC: [email-masked]
> > > > >Subject: Re: Lambda LSP establishment
> > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100
> > > > >
> > > > >Manoj,
> > > > >
> > > > >You refer to one wavelength to be available between A-E without
> > > wavelength
> > > > >conversion capability. This suggests that you operate at
> > > the OCh layer
> > > > >network.
> > > > >Then you specify the capacity of the 4 OCh link
> > > connections (A-B, B-C,
> > > C-D,
> > > > >D-E)
> > > > >to be "C". Say that C is about 10 Gbit/s. You then assume
> > > that there is a
> > > > >request for an OCh signal with capacity C/4 (e.g. 2.5
> > > Gbit/s) between C
> > > and
> > > > >E.
> > > > >The result is that the OCh link connections C-D and D-E
> > > are transporting
> > > > >the OCh
> > > > >signal (of e.g. 2.5G). These OCh link connections are now
> > > in service and
> > > > >not
> > > > >longer available to an other OCh connection request. I.e.
> > > a request for
> > > an
> > > > >OCh
> > > > >connection between A and E will be rejected.
> > > > >
> > > > >FAs are not applicable in the circuit layers. IF there is
> > > a trail in
> > > server
> > > > >layer X, then there is a link in its client layer Y. X and
> > > Y are thus
> > > > >different
> > > > >layer networks and signals.
> > > > >
> > > > >If C-E is a "FA", then in an OTN the C-E connection would
> > > be an OCh trail
> > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link
> > > connection.
> > > > >
> > > > >Note a FA in MPLS creates essentially a MPLS sublayer
> > > network. Such is
> > > not
> > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies.
> > > > >
> > > > >Regards,
> > > > >
> > > > >Maarten
> > > > >
> > > > >OCh link connections
> > > > >
> > > > >manoj juneja wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >         If I have 5 nodes A, B, C, D and E connected as
> > > shown. Assume
> > > > > > that only one wavelength is available on the path A to E (no
> > > wavelength
> > > > > > conversion capability is there on the complete path).
> > > Let the capacity
> > > > > > of the wavelength be C. Further assume a request arrives for
> > > connection
> > > > > > from node C to E for a line capacity of C/4. This
> > > request will be
> > > > > > successful as we have available wavelength. Now If
> > > another request
> > > > > > comes at node A to establish another connection from
> > > node A to node E
> > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4.
> > > Should this request
> > > > > > be successful as we have already allocated the wavelength ?
> > > > > >
> > > > > > If the previous connection from C to E of capacity
> > C/4 had been
> > > > > > advertised as a FA, in that case will the IInd
> > request succeed ?
> > > > > >
> > > > > > If the previous connection from C to E of capacity C/4
> > > had not been
> > > > > > advertised as FA then what will be the fate of IInd
> > connection ?
> > > > > >
> > > > > >        A <--> B <---> C <----> D <---> <----> E
> > > > > >
> > > > > > Regards,
> > > > > > manoj.
> > > > > >
> > > > > >
> > > _________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at
> > > > >http://explorer.msn.com/intl.asp
> > > > ><< mvissers.vcf >>
> > > >
> > > > _________________________________________________________________
> > > > Send and receive Hotmail on your mobile device:
> > http://mobile.msn.com
> >
--------------E640D57D048E904035B08AE9
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

--------------E640D57D048E904035B08AE9--

Delivery-date: Fri, 04 Jan 2002 05:17:46 -0800
Cc: "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Fri, 04 Jan 2002 14:14:02 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS signaling documents updated per last calls

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

Eric,

"Mannie, Eric" wrote:
> 
> Hello Maarten,
> 
> > It is not the intention to leave the choice of LSP encoding type and SU
> label
> structure to the vendor. This would give immediate interworking problems.
> 
> Sorry but this comment doesn't make sense. Of course if one implements an
> IP-LSR it could not speak SDH ! The vendor has the choice of the type of box
> he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of
> course we leave the choice of the supported LSP encoding types to the
> vendors !

The discussion is about the SDH/SONET label and LSP encoding type... not about
IP versus SDH or ATM versus SDH. So I maintain my statement that it is not the
intention to leave the choice of SDH/SONET LSP encoding type and SDH/SONET SU
label structure to the vendor. Standardising two alternatives will give
interworking problems.

> 
> The label structure is defined in the draft.
> 
> > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
> VC-4-4c/STS-12c,
> VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
> encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
> encoding type "SDH".
> 
> No, not necessarily. Why do you want to reject all SONET implementations ?

Sorry, but there are no implementations possible today of a standard which is
not yet available. there are pre-standard implementations only.

I am as such not rejecting any (future) standards compliant SDH/SONET
implementation. I am simply describing the result of our agreement to use LSP
encoding type SDH for all SDH and SONET signals which have equivalent SDH
types... i.e. all STS and VT signals except VT-3... 

And as VT-3 is not existing in the networks (see email of T1X1.5 chair) and can
be deleted from the T1.105 standard if a contribution is received, the above
agreement can be understood as "use LSP encoding type SDH for all SDH and all
SONET signals".

> 
> > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
> VC-4-64c/STS-192c
> and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure.
> 
> No, not necessarily. Why do you want to reject all SONET implementations ?

Sorry again, but there are no implementations possible today of a standard which
is not yet available. There are pre-standard implementations only.

I am as such not rejecting any (future) standards compliant SDH/SONET
implementation. I am simply describing the result of our agreement to use SU
label structure for SDH signals for all SDH and all SONET signals which have
equivalent SDH types... i.e. all STS ... 

> 
> > Looking at the label text in section 3 of the sonet-sdh document, I find
> it very
> confusing to read that SONET doesn't use the "U" field.
> 
> This didn't change since 1 or 2 years.
> 
> By the way, I thought that we reached an agreement ?

I thought also we reached an agreement, but given your reaction I doubt if we
have got one... As far as I remember we never agreed about keeping double coding
for STS and VT signals. We only agreed at using the SDH coding for both VC-n as
well as STS and VT (except VT-3) signals. As such I do not understand your
interpretation of the agreement. Perhaps the management team can help out here?

> 
> > As we indicated before there is no STS type signal that isn't having an
> SDH equivalent; i.e. there are no specific higher order SONET signals left.
> It is therefore much better to take out the SONET text for the SU label part
> altogether.
> 
> It is not only a matter of the signal type field in the draft, it is also a
> matter of how the network is monitored/operated. A SONET signal is not
> always 100% compatible with an SDH signal. It depends on the profile used in
> SDH and SONET. For sure there are different profiles for SONET and SDH (e.g.
> differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood
> that there is a join effort between T1 and ITU to reduce these differences,
> but you cannot assume that everybody will adapt to/implement the latest
> (draft) version of the transport plane standards.

It has been indicated more than once already that there aren't specific
SDH/SONET differences, there are the more general SDH/SDH differences (including
some that are due to original SONET specs) that need to be catered for. These
differences can't be tackled by the use of SDH and SONET identifiers. By pushing
continuously SDH and SONET identifiers for this purpose, you reject the more
general SDH/SDH differences and interworking issues. As half a solution is no
solution, SDH/SONET should be dropped and a negotiation mechanism should be
developed instead which can resolve the more general SDH/SDH differences.

> 
> Indeed, I think that we should have much more than just than two LSP
> encoding types (SDH and SONET),  but that we should in addition indentify
> profiles. Having SDH and SONET is a strict minimum. Making mandatory the use
> of one single LSP encoding type for both SONET and SDH is lying to the
> people. It will make GMPLS impossible to use in practice.
> 
> Anyway, as you said there are different profiles in SDH, and different
> profiles in SONET. The difference between SDH and SONET comes from the fact
> that they use different profiles (they can also use the same). In the LSP
> encoding type, when we use SONET, we mean a different profile than SDH. We
> wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't
> want.
> 
> If I understood, your idea is to have a second signaling protocol doing a
> second pass to setup the profile. Having a control plane with several
> signaling round trips and different signaling protocols to setup one single
> circuit is a complete mistake from my point of view and from my control
> plane design experience. Of course since you want to impose this second
> signaling pass, you need to impose a single unique LSP encoding type for
> both SDH and SONET so that we will be obliged to use another pass to make
> the distinction. I think that now everybody can understand what you have in
> mind but don't want to explain.

Mind reading isn't a success :-) ... SDH, SONET, SDH1996, SONET1995, SDH2000,
etc do not at all resolve any of the issues to be resolved. E.g. SDH2000
includes a number of alternatives for a single parameter (e.g. J1 byte: 16 or 64
bytes) and denoting something SDH2000 (or SDH1996, SONET 1995, ..) will thus not
resolve the interworking issues. 

I introduced the connection monitoring setup phase to get values assigned to
connection monitoring parameters (like Expected Trace Identifier, TIM disable,
Degraded Threshold, Degraded Monitor period, ..) within termination sink
functions connected to the setup connection. E.g. for the case of expected trace
identifier value assignment, the connection setup process has to read the
Transmitted Trace Identifier value at the termination source function, convey
this value to the far end termination sink (and possible intermediate non
intrusive monitors), where it will be assigned to the expected trace identifier
parameter MI_ExTI.

As this connection monitoring setup phase is needed eitherway, it can be used in
addition to negotiate certain parameters for which the SDH standard allows more
than one option. Seems time to document this connection monitoring setup
(including negotiation where applicable) in a new draft.

	Note - I called it "phase" or "step" to let it stand out from
	the basic connection set up of selecting links and link connections
	and closing matrix connections. This however doesn't imply that 
	phase/step 1 and 2 will have to be sequential... one typically 
	combines these phases/steps.

Regards,

Maarten

> 
> >Otherwise we will get a lot of confusion in the marketplace.
> 
> I think that you are creating the confusion by claiming that there is no
> difference at all between SDH and SONET.
> 
> > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
> label
> with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
> must
> thus use the "SDH" SU format.
> 
> We are back at the beginning of the discussion... for the Xth time ! As
> usual.
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, December 19, 2001 9:05 AM
> To: Mannie, Eric
> Cc: [email-masked]'; 'Stephen Trowbridge'; Kireeti
> Kompella; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Eric,
> 
> It is not the intention to leave the choice of LSP encoding type and SU
> label
> structure to the vendor. This would give immediate interworking problems.
> 
> VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c,
> VC-4-4c/STS-12c,
> VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
> encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
> encoding type "SDH".
> 
> VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c,
> VC-4-64c/STS-192c
> and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure.
> 
> Looking at the label text in section 3 of the sonet-sdh document, I find it
> very
> confusing to read that SONET doesn't use the "U" field. As we indicated
> before
> there is no STS type signal that isn't having an SDH equivalent; i.e. there
> are
> no specific higher order SONET signals left. It is therefore much better to
> take
> out the SONET text for the SU label part altogether. Otherwise we will get a
> lot
> of confusion in the marketplace.
> 
> Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the
> label
> with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and
> must
> thus use the "SDH" SU format.
> 
> -------
> 
> All,
> 
> With the clarification on VT-3 given by Deborah, I would request to consider
> a
> further simplification of the GMPLS standard: delete the LSP encoding type
> "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
> would be no ambiguity left at all.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hi Jonathan,
> >
> > > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > To leave to the manufacturer and to the user the right to decide if he/she
> > wants to signal an LSP as either SDH or SONET. There is no
> interoperability
> > problem at all since you use EITHER SDH OR SONET. If you decide to request
> > an SDH signal with what do you want to have interoperability issue at this
> > stage ? The sentence means indeed "one should better use SDH than SONET" !
> > Once you decided, there is no issue.
> >
> > > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> > the implementations that could not care of SDH, with implementations that
> > still do a distinction between SONET and SDH for some reasons, with the
> > implementations that could still use the VT3 (DS1C) (I don't have
> > confirmation that nobody is using it today, and this is not the goal of
> this
> > draft to state what is obsolete or not in SONET), etc.
> >
> > Anyway, there is no issue, the SONET label format is not used until SONET
> is
> > explicitly requested as such. This is not a primary feature of the draft,
> > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> > everything, consequently you don't care of the SONET label, you skip it in
> > the draft, you ignore it, you don't implement it and you just use a full
> SDH
> > implementation.
> >
> > I think that the solution is quite simple: if the SONET signal is indeed
> an
> > SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> > that's all.
> >
> > By the way, since according to some folks SONET is just a subset of SDH,
> why
> > do we care about SONET in these documents ? Why don't we simply remove all
> > references to SONET ?
> >
> > Is there somebody on this mailing list that cares about SONET ? If yes,
> why
> > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Tuesday, December 18, 2001 9:57 PM
> > To: Mannie, Eric
> > Cc: 'Stephen Trowbridge'; Kireeti Kompella; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > Eric -
> >
> > Comments inline...
> >
> > Jonathan Sadler
> >
> > "Mannie, Eric" wrote:
> > > "A SONET signal which has an identical SDH signal SHOULD be requested
> > using
> > > the same traffic parameters as for the equivalent SDH signal, and will
> > > consequently use the SDH label."
> >
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> > interoperability problems in the future...
> >
> > > We spend with Maarten a lot of time to write that sentence (not easy to
> > > write).
> > >
> > > Maybe that it should be better written:
> > >
> > > "A SONET signal which has an identical SDH signal SHOULD be requested as
> > an
> > > SDH signal using the same traffic parameters as for the equivalent SDH
> > > signal, and will consequently use the SDH label."
> >
> > Again, "SHOULD" needs to be replaced with "MUST"...
> >
> > > This doesn't mean that the SONET signal format disappear (simply not
> used
> > in
> > > that case), for backward compatibility we need to keep it.
> >
> > I'm curious what sort of backward compatability is necessary, as a
> > "standard" doesn't exist currently that this needs to be backward
> > compatible with...
> >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Tuesday, December 18, 2001 7:46 PM
> > > To: Kireeti Kompella
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: GMPLS signaling documents updated per last calls
> > >
> > > Kireeti,
> > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> > > (T1X1.5 chair) on this one and I take the liberty of sharing her
> response:
> > >
> > > Deborah Brungard wrote:
> > > > The VT3 (3M) structure was defined - but no services (mappings) were
> > ever
> > > defined for it. So there are no services/equip
> > > > with it. My take was if in the future it was ever defined (doubtful),
> we
> > > would be adding it to g707 also. So then it
> > > > would just be part of g707 too.
> > >
> > > So basically, there are no mappings or equipment functions for this
> rate,
> > > and as far as we know no network equipment or networks supporting it.
> > > Deborah suggests that if we were ever to define such mappings, that this
> > > would be proposed for addition to G.707 and hence be part of SDH.
> > >
> > > I think our agreement had been to use the SDH label for all signals that
> > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we
> > > thought
> > > that this was everything except VT3. Given that VT3 seems not to be a
> > "real"
> > > signal at this point and will likely be added to SDH if it ever becomes
> > > real, does our agreement then become that we use SDH labels for
> > everything?
> > >
> > > Regards,
> > > Steve
> > >
> > > Kireeti Kompella wrote:
> > > >
> > > > Hi Deborah,
> > > >
> > > > > I previously made the
> > > > > comments to merge the (1) SDH and SONET values as one value
> > > >
> > > > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > > > several issues, among them this one.  The upshot was that whenever
> > > > possible, the SDH label should be used, with the encoding type
> > > > set to SDH (i.e., G.707); however, there are signals that have
> > > > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > > > me!), so we will keep SONET labels and encoding types around
> > > > for that case and for legacy equipment.
> > > >
> > > > The revised SONET/SDH document will contain the exact wording.
> > > > I will also be sending a reply to the ITU communication stating
> > > > the agreement we came to.
> > > >
> > > > Kireeti.
--------------4F72B9F28FF8D8250473E28D
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

--------------4F72B9F28FF8D8250473E28D--

Delivery-date: Thu, 03 Jan 2002 11:16:42 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue in Label Set Object structure
Date: Thu, 03 Jan 2002 12:14:41 -0700

Mohan,
       Please see inline for comments.

Regards,
manoj.

>From: "Mohan Verma" <[email-masked]>
>Reply-To: <[email-masked]>
>To: "'manoj juneja'" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>, <[email-masked]>
>Subject: RE: Issue in Label Set Object structure
>Date: Thu, 3 Jan 2002 20:45:22 +1100
>
>
>Hi,
>      The number of virtual concatenated labels can be conveyed by
>  the SONET/SDH traffic parameters in PATH/REQ message.
[manoj] : I fully agree with this one.

>      The Label Set object inclusion plays role more in wavelength
>  switching networks as there can be limited wavelength conversion
>  [please refer to section 9 in ietf-ccamp-gmpls-architecture-01].
[manoj]: There is a difference in saying that label set of more of
importance to wavelengths and not of use to SDH/SONET networks.
Fortunately, the drafts mentions that it is more of use to wavelegths.
It does not mention that u can't include the virtual concatenated
labels in a label set. In O-UNI, u need that support where the upstream
node wants to have same label in both the directions of a bi
-directional LSP.

>      Hope this clarifies...
>Regards
>Mohan Varma
>
>
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of manoj juneja
>Sent: Thursday, January 03, 2002 6:22 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Issue in Label Set Object structure
>
>
>Hi All,
>
>         There seems to be some issue with the label set object format. Can 
>I
>include the virtually concatenated SDH/SONET signal label in the label set
>object ?
>If I want to have multiple subchannel elements in the label set
>(basically a set of labels in the label set instead of range) then
>how to determine that how many # of 4 byte octets comprise one
>virtual concatenated signal ?
>Or Is it that the subchannel element within the label set will also
>include the object header for generalized label ?
>
>Please let me know if I am missing something.
>Regards,
>manoj.
>
>_________________________________________________________________
>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
>

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Delivery-date: Thu, 03 Jan 2002 07:13:34 -0800
Reply-To: <[email-masked]>
From: "Mohan Verma" <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Issue in Label Set Object structure
Date: Thu, 3 Jan 2002 20:45:22 +1100

Hi,
     The number of virtual concatenated labels can be conveyed by
 the SONET/SDH traffic parameters in PATH/REQ message.
     The Label Set object inclusion plays role more in wavelength
 switching networks as there can be limited wavelength conversion
 [please refer to section 9 in ietf-ccamp-gmpls-architecture-01].
     Hope this clarifies...
Regards
Mohan Varma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of manoj juneja
Sent: Thursday, January 03, 2002 6:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Issue in Label Set Object structure

Hi All,

        There seems to be some issue with the label set object format. Can I
include the virtually concatenated SDH/SONET signal label in the label set
object ?
If I want to have multiple subchannel elements in the label set
(basically a set of labels in the label set instead of range) then
how to determine that how many # of 4 byte octets comprise one
virtual concatenated signal ?
Or Is it that the subchannel element within the label set will also
include the object header for generalized label ?

Please let me know if I am missing something.
Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Wed, 02 Jan 2002 17:54:13 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Notify Message structure Issue
Date: Wed, 02 Jan 2002 18:48:33 -0700

Hi All,
        In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, the
downstream notify session is defined as a part of notify session list
(in notify message). The Style should also be present before flow
descriptor list and should be mandatory.

Please correct me if I am wrong.

Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Wed, 02 Jan 2002 11:26:31 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Issue in Label Set Object structure
Date: Wed, 02 Jan 2002 12:22:00 -0700

Hi All,

        There seems to be some issue with the label set object format. Can I 
include the virtually concatenated SDH/SONET signal label in the label set 
object ?
If I want to have multiple subchannel elements in the label set
(basically a set of labels in the label set instead of range) then
how to determine that how many # of 4 byte octets comprise one
virtual concatenated signal ?
Or Is it that the subchannel element within the label set will also
include the object header for generalized label ?

Please let me know if I am missing something.
Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Delivery-date: Wed, 02 Jan 2002 10:19:32 -0800
Date: Wed, 2 Jan 2002 10:11:38 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>
cc: "[email-masked] '" <[email-masked]>
Subject: Re: SRLG in  generalized ISIS

On Wed, 26 Dec 2001, LE ROUX Jean-Louis FTRD/DAC/LAN wrote:

> Folks,
> 
> I have a question regarding the  TLV SRLG (138) in
> "draft-ietf-isis-gmpls-extensions-05.txt"
> Why is this information included in a separated TLV ?

TLV space.

Kireeti.