Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 30 Sep 2002 06:42:05 -0700
Date: Mon, 30 Sep 2002 09:42:45 -0400
Message-ID: <3D87C4450000BF9A@mta08.san.yahoo.com>
From: "Kavita Khanna" <kkhanna@isocore.com>
Subject: MPLS 2002 (www.mpls2002.com): Oct 27-29, Wash, DC
To: ccamp@ops.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Friends,

The leading service providers, major networking and test equipment vendor=
s,
and many IETF contributors will gather at MPLS 2002, October 27-29, in Wa=
shington,
DC, in the Omni Shoreham Hotel (http://www.mpls2002.com).

This unique international event, which is in its 5th year, is hosted by
Worldcom, Cable & Wireless, France Telecom, NTT and Isocore; and sponsore=
d
by industry leaders such as Alcatel, Avici Systems, Cisco Systems, CoSine=

Communications, Laurel Networks, Lucent, Nortel Networks, Redback Network=
s,
Juniper Networks, Extreme Networks; IXIA, NetTest, and Spirent Communicat=
ions.
The exhibits will be open throughout Monday and Tuesday. There will be ne=
w
product or software feature announcements. Prominent members of the press=

and well-regarded industry analysts will also be present at MPLS 2002.

MPLS 2002 consists of a two-day highly technical sessions, six technical
tutorials and exhibits. The technical sessions offer an excellent blend
of topics including deployment, application, and management aspects of MP=
LS
(please visit "Program" section http://www.mpls2002.com/sessions.htm). Th=
e
event will be followed by the third public MPLS Interoperability demo, on=

October 30. Major vendors will showcase interoperability of their MPLS-ba=
sed
leading-edge features on their core and edge routers.

We hope you would be able to actively participate in the MPLS 2002 Intern=
ational
Conference. You may register (on-line or off-line) for MPLS 2002 by visit=
ing
http://www.mpls2002.com/registration.htm and following the instructions.
The reduced registration fees, currently in effect, are extremely attract=
ive.

If you are planning to attend MPLS 2002, please make your hotel reservati=
ons
at the Omni Shoreham Hotel immediately, as only a limited number of rooms=
,
blocked for the conference at special rates, are left. You may visit (htt=
p://www.mpls2002.com/hotels.htm)
for more information on hotel reservations.

To celebrate the 5th anniversary of this series, all participants will re=
ceive
the conference proceedings from previous years MPLS1998, MPLS1999, MPLS20=
00,
MPLS2001) in addition to MPLS 2002 presentations on a CD. We look forward=

to seeing you at MPLS 2002, in Washington, DC.

Regards,
MPLS 2002 Team





Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 29 Sep 2002 23:57:53 -0700
Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08A75CBC@cms1.etri.re.kr>
From: yhwkim@etri.re.kr
To: ccamp@ops.ietf.org
Subject: LMP's authentication function
Date: Mon, 30 Sep 2002 15:46:33 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2684D.1DA72920"

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

------_=_NextPart_001_01C2684D.1DA72920
Content-Type: text/plain;
	charset="euc-kr"

Hi, all.

I'm sorry, but I'd like to know the reason that in the LMP of version 6 the
authentication function is not shown.
Could anyone tell me the fact?

Regards
Young H. Kim

****************************************** 
Young Hwa Kim 
Senior Member, Network Technology Lab., ETRI 
Office No. : 82-42-860-5819 
Fax No. : 82-42-860-6342 
Mobile No. : 011-433-5819 
Email addr. : yhwkim@etri.re.kr 
****************************************** 



------_=_NextPart_001_01C2684D.1DA72920
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>LMP's authentication function</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>I'm sorry, but I'd like to know the reason that in the LMP of version 6 the authentication function is not shown.</FONT>
<BR><FONT SIZE=2>Could anyone tell me the fact?</FONT>
</P>

<P><FONT SIZE=2>Regards</FONT>
<BR><FONT SIZE=2>Young H. Kim</FONT>
</P>

<P><FONT SIZE=2>****************************************** </FONT>
<BR><FONT SIZE=2>Young Hwa Kim </FONT>
<BR><FONT SIZE=2>Senior Member, Network Technology Lab., ETRI </FONT>
<BR><FONT SIZE=2>Office No. : 82-42-860-5819 </FONT>
<BR><FONT SIZE=2>Fax No. : 82-42-860-6342 </FONT>
<BR><FONT SIZE=2>Mobile No. : 011-433-5819 </FONT>
<BR><FONT SIZE=2>Email addr. : yhwkim@etri.re.kr </FONT>
<BR><FONT SIZE=2>****************************************** </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2684D.1DA72920--



Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 28 Sep 2002 21:39:01 -0700
Message-Id: <4.3.2.7.2.20020923172217.03af1200@mo-ex1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Date: Mon, 23 Sep 2002 17:24:36 -0400
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
From: Lou Berger <lberger@movaz.com>
Subject: RE: IESG comments on generalize MPLS documents
Cc: "Berger, Lou" <lberger@movaz.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>

Bert, the IESG web site says:
SUB JUN 5 Generalized MPLS - Signaling Functional Description (Proposed 
Standard)
   draft-ietf-mpls-generalized-signaling-09.txt
  Token: bwijnen
  Note: New revision needed
   Generalized MPLS Signaling - CR-LDP Extensions (Proposed Standard)
   draft-ietf-mpls-generalized-cr-ldp-07.txt
   Generalized MPLS Signaling - RSVP-TE Extensions (Proposed Standard)
   draft-ietf-mpls-generalized-rsvp-te-08.txt

Given that we issued new revs almost 1 month ago and there's been no 
additional comments, what's need to progress the documents?

Thanks,
Lou

PS Never heard from the security ADs and the reference you gave relates to 
TCP and is appropriate for LDP, but not RSVP.

At 03:27 PM 8/29/2002, Wijnen, Bert (Bert) wrote:

>I still have no complete answer from the SEC ADs...
>But a start might be document draft-iab-sec-cons-00.txt
>specifically sect 4.5.1
>
>Hope this gets you started
>
>Bert
> > > ><draft-ietf-mpls-generalized-rsvp-te-07.txt>
> > > >
> > > >1. This doc says "just use IPsec".  A clearer statement is needed,
> > > >    specifying the necessary IPsec selectors (per RFC 2401) and the
> > > >    way the cryptographically protected endpoints are related to
> > > >    the authorization model, i.e., who can do what.
> > >
> > > can you provide an example of what you'd like to see?
> > >
> >
> > I am checking with Security ADs.
> >






Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 27 Sep 2002 10:44:42 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB88659B1@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'Ong, Lyndon'" <LyOng@ciena.com>, 'Ron Bonica' <Ronald.P.Bonica@wcom.com>, ccamp@ops.ietf.org
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
Date: Fri, 27 Sep 2002 10:42:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Lyndon,
 Thanks for the review.  Comments inline.

-Jonathan

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@ciena.com]
> Sent: Thursday, September 26, 2002 2:09 PM
> To: 'Ron Bonica'; ccamp@ops.ietf.org
> Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
> 
> 
> Ron,
> 
> Very quiet list - hope everyone is still employed...
> 
> 1)  3.2.1 states that HelloInterval and HelloDeadInterval 
> MUST be agreed upon by the local and remote nodes, but I
> am still looking for a description of how they agree, if
> it's there would appreciate a pointer to this (e.g., shortest
> value wins?)
In Section 3.1 we describe parameter negotiation.

> 
> 2) TE_LINK Class includes flags to indicate Fault Mgmt
> or Link Verification supported/not supported.  If in fact
> the Trace function that has been sucked into the SONET/SDH
> draft is accepted, should another flag be assigned for this?
Since this is SONET/SDH specific, I'd prefer to put this in the SONET/SDH
draft. 

> 
> 3) minor alignment - 13.12.1.1 references Switching
> Capability and Link Encoding Type in the GMPLS-SIG
> draft, but the exact wording in GMPLS-SIG seems to
> be Switching Type and LSP Encoding Type.
Thanks for catching these. I will correct them.

> 
> Cheers,
> 
> L. Ong
> Ciena
> 
> 
> -----Original Message-----
> From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
> Sent: Thursday, September 19, 2002 6:34 AM
> To: ccamp@ops.ietf.org
> Subject: WG Last Call: draft-ietf-ccamp-lmp-06
> 
> 
> Folks,
> 
> This message begins a WG last call for 
> draft-ietf-ccamp-lmp-06. Last call
> will end one week from today, at midnight EDT on Spetember 26, 2002.
> 
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 27 Sep 2002 07:39:48 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03933@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Liu Qiang'" <qliu@lit.a-star.edu.sg>, "Reddy, Vikram" <vikramr@netplane.com>, ccamp@ops.ietf.org, IETF MPLS List <mpls@UU.NET>
Subject: RE: Question on Control Channel -Data Channel association
Date: Fri, 27 Sep 2002 07:37:43 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi,

What you described is permitted and in fact is used for example when per-platform
label spaces are used.

-Shahram

> 
> Hi all,
> 
> I have a question on the association of Control Channel and Data
> Channel. I would appreciate if somebody could answer it
> 
> In the following figure (A*,B*) are for Control Channel Interface
> addresses and  (X*,Y*) are for Data Channel Interface Addresses.
> Dotted lines (....) for control channel, Dashed line (----) for
> data channel.
> 
> 	      A1 .................................B1
>   Node 1      X1 ---------------------------------Y1     Node 2
>                   A2 .................................B2
> 
> In the above configuration can we have Node1 use A1-B1 for sending
> control messages for X1-Y1 but expect to receive control messages
> for X1-Y1 on A2-B2.
> Similarly can we have Node2 use B2-A2 for sending
> control messages for X1-Y1 but expect to receive control messages
> for X1-Y1 on B2-A2.
> 
> Is this prohibited and if it is, which document specifies it?
> 
> 
> Thanks,
> Vikram.
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 27 Sep 2002 01:00:08 -0700
Date: Fri, 27 Sep 2002 16:05:28 +0800
From: Liu Qiang <qliu@lit.a-star.edu.sg>
Subject: RE: Question on Control Channel -Data Channel association
To: "Reddy, Vikram" <vikramr@netplane.com>, ccamp@ops.ietf.org, IETF MPLS List <mpls@UU.NET>
Message-id: <NGBBJAJGOLOECPJHDOEBGECDCBAA.qliu@lit.a-star.edu.sg>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,

  Your question is some interesting. As I know the control channel is a pair
bi-directional reachable interface. That means messages can flow in the
"path"  A1->B1 and B1->A1. So does the "path" A2->B2 and B2->A2.
  The common idea is take one channel as active one, and another one as
backup, certainly you can set both of them as active and each of them serve
for a certain group of TE link.
  Here, you have two seperate "udi-direction" control channels, are they
physical  "uni" or just logical "uni-directional"?
  So far, I don't think any document prohibites or specifies it.

regards,

Liu Qiang

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of
Reddy, Vikram
Sent: 2002?9?27? 15:17
To: ccamp@ops.ietf.org; IETF MPLS List
Subject: Question on Control Channel -Data Channel association


Hi all,

I have a question on the association of Control Channel and Data
Channel. I would appreciate if somebody could answer it

In the following figure (A*,B*) are for Control Channel Interface
addresses and  (X*,Y*) are for Data Channel Interface Addresses.
Dotted lines (....) for control channel, Dashed line (----) for
data channel.

	      A1 .................................B1
  Node 1      X1 ---------------------------------Y1     Node 2
                  A2 .................................B2

In the above configuration can we have Node1 use A1-B1 for sending
control messages for X1-Y1 but expect to receive control messages
for X1-Y1 on A2-B2.
Similarly can we have Node2 use B2-A2 for sending
control messages for X1-Y1 but expect to receive control messages
for X1-Y1 on B2-A2.

Is this prohibited and if it is, which document specifies it?


Thanks,
Vikram.






Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 27 Sep 2002 00:15:28 -0700
Message-ID: <E7E13AAF2F3ED41197C100508BD6A328853DDB@india_exch.hyderabad.mindspeed.com>
From: "Reddy, Vikram" <vikramr@netplane.com>
To: ccamp@ops.ietf.org, IETF MPLS List <mpls@UU.NET>
Subject: Question on Control Channel -Data Channel association
Date: Fri, 27 Sep 2002 03:16:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

I have a question on the association of Control Channel and Data 
Channel. I would appreciate if somebody could answer it

In the following figure (A*,B*) are for Control Channel Interface 
addresses and  (X*,Y*) are for Data Channel Interface Addresses.  
Dotted lines (....) for control channel, Dashed line (----) for 
data channel.

	      A1 .................................B1
  Node 1      X1 ---------------------------------Y1     Node 2
                  A2 .................................B2

In the above configuration can we have Node1 use A1-B1 for sending 
control messages for X1-Y1 but expect to receive control messages
for X1-Y1 on A2-B2. 
Similarly can we have Node2 use B2-A2 for sending 
control messages for X1-Y1 but expect to receive control messages
for X1-Y1 on B2-A2. 

Is this prohibited and if it is, which document specifies it?


Thanks,
Vikram.





Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 26 Sep 2002 23:37:09 -0700
Message-ID: <99EC34181384D611BE56000347227B2C015186@MAILHOSTNB>
From: Manoj Agiwal <manoj.agiwal@metro-optix.com>
To: "Gmpls-Ops (E-mail)" <gmpls-ops@mplsrc.com>, "'Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: ERO Label Sub Object
Date: Fri, 27 Sep 2002 01:33:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Hi ,
        In optical networks is it assumed that ERO will always contain Label
subobject for an outgoing interface , or can we have
ERO label subobject for an incoming interface as well . If we look at the
processing of an ERO label subobject it is mentioned that downstream label
in the ERO subobject is passed in the Label Set object in the path message
to the next node , and Upstream Label in ERO label subobject is passed in
Upstream label in Path message to the next node .
       Using Numberred ERO subobject we can mention either incoming or
outgoing interface , can the same thing hold good for unnumberred ERO
subobject . The problem here is that if it is intended for incoming
interface then we need to check the interface
number with the PHOP to see if it is consistent.
Manoj
       



Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 26 Sep 2002 15:48:17 -0700
Message-ID: <39469E08BD83D411A3D900204840EC5576337A@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ong, Lyndon'" <LyOng@ciena.com>, "'Ron Bonica'" <Ronald.P.Bonica@wcom.com>, ccamp@ops.ietf.org
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
Date: Thu, 26 Sep 2002 18:45:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

LMP guys,

-> 1)  3.2.1 states that HelloInterval and HelloDeadInterval 
-> MUST be agreed upon by the local and remote nodes, but I
-> am still looking for a description of how they agree, if
-> it's there would appreciate a pointer to this (e.g., shortest
-> value wins?)

  I have something to say regarding this point.

  Synchronized Parameter settings are sometimes harmful.
  Most of the LMP Hello protocol fundamentals are derived
  from OSPF. But, inherently there are some issues with 
  the OSPF Hello protocol parameter exchange.

  Radia's 1991 paper reads (FYI):

  In OSPF, there are several parameters that must be 
  configured identically in routers, or else the router will 
  refuse to communicate with each other. This creates a 
  problem because it is virtually impossible to change the 
  parameter setting via network management. Once a router's 
  parameter setting is changed, it is cut off from the 
  rest of the network since no other routers will be able 
  to communicate with it. 
  . . .

   - HelloTime and DeadTime: 
     . . .
     ISIS reports only DeadTime in its Hello messages (not 
     HelloTime). As a result, the ratio between DeadTime and
     HelloTime is fixed in ISIS, but can be configured in
     different ways by OSPF. ISIS uses the information solely
     to determine how long to wait between receipt of Hellos
     from a particular neighbor before declaring the link
     to that neighbor down. There is no necessity for 
     neighboring nodes to have the same value.

     Being able to change these timers in a running network is
     important. As a LAN becomes larger it might be decided
     that the overhead from hellos is too great. It also
     might be important in some configurations to be able to
     run with different hello timers for different routers.
     There might be some routers for which quick deletion 
     of failure would be very desirable, whereas for other
     routers quick deletion of failure might not be as
     important. To lower overhead these routers might be 
     configured with a longer HelloTime. This cannot be done
     in OSPF since all routers must have identical timers.

  Moreover, please remember that LMP hellos are very very
  granular. The scalability requirements for LMP are little
  strict when compared to traditional protocols.

  So, please revisit the LMP hello protocol timer configurations.

  After all, my 2 cents... :)

--
Venkata.



Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 26 Sep 2002 14:13:24 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD3409@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Ron Bonica'" <Ronald.P.Bonica@wcom.com>, ccamp@ops.ietf.org
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-06
Date: Thu, 26 Sep 2002 14:08:30 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Ron,

Very quiet list - hope everyone is still employed...

1)  3.2.1 states that HelloInterval and HelloDeadInterval 
MUST be agreed upon by the local and remote nodes, but I
am still looking for a description of how they agree, if
it's there would appreciate a pointer to this (e.g., shortest
value wins?)

2) TE_LINK Class includes flags to indicate Fault Mgmt
or Link Verification supported/not supported.  If in fact
the Trace function that has been sucked into the SONET/SDH
draft is accepted, should another flag be assigned for this?

3) minor alignment - 13.12.1.1 references Switching
Capability and Link Encoding Type in the GMPLS-SIG
draft, but the exact wording in GMPLS-SIG seems to
be Switching Type and LSP Encoding Type.

Cheers,

L. Ong
Ciena


-----Original Message-----
From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
Sent: Thursday, September 19, 2002 6:34 AM
To: ccamp@ops.ietf.org
Subject: WG Last Call: draft-ietf-ccamp-lmp-06


Folks,

This message begins a WG last call for draft-ietf-ccamp-lmp-06. Last call
will end one week from today, at midnight EDT on Spetember 26, 2002.


===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 25 Sep 2002 07:10:39 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE6BD@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: REPOST: Clarification needed re: IF Index TLV in RSVP_HOP
Date: Wed, 25 Sep 2002 10:01:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

In draft-ietf-mpls-generalized-signaling-09, page 25 it says:


   In cases where there is not an explicit one-to-one association of
   control channels to data channels it is necessary to convey
   additional information in signaling to identify the particular data
   channel being controlled.  GMPLS supports explicit data channel
   identification by providing interface identification information.
   GMPLS allows the use of a number of interface identification schemes
   including IPv4 or IPv6 addresses, interface indexes (see [MPLS-
   UNNUM]) and component interfaces (established via configuration or a
   protocol such as [LMP]).  ***In all cases the choice of the data
   interface is indicated by the upstream node using addresses and
   identifiers used by the upstream node.***

The final sentence is clear enough for the Path message. The RSVP_HOP object
will specify the router ID and local link identifier according to the LSR
generating the Path message. It is not clear what is intended in the Reserve
message. I am guessing it is again the router ID and local link identifier,
but this time according to the generator of the Reserve message. However, I
can imagine other alternatives. Can someone in the know help out?

Thanks


> Michael Mandelberg
> FirstWave Intelligent Optical Networks, Inc.
> 11800 Sunrise Valley Drive, 15th floor
> Reston, Virginia 20191
> (703) 390 - 9401, x 1008
> mmandelberg@fwion.com
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 23 Sep 2002 14:59:15 -0700
Message-Id: <4.3.2.7.2.20020923175505.03861f00@mo-ex1>
Date: Mon, 23 Sep 2002 17:57:10 -0400
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
From: Lou Berger <lberger@movaz.com>
Subject: RE: IESG comments on generalize MPLS documents
Cc: "Berger, Lou" <lberger@movaz.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:53 PM 9/23/2002, Wijnen, Bert (Bert) wrote:

> > -----Original Message-----
> > From: Lou Berger [<mailto:lberger@movaz.com>mailto:lberger@movaz.com]
> > Sent: maandag 23 september 2002 23:25
> > To: Wijnen, Bert (Bert)
> > Cc: Berger, Lou; Ccamp-wg (E-mail)
> > Subject: RE: IESG comments on generalize MPLS documents
> >
> > Bert, the IESG web site says:
> > SUB JUN 5 Generalized MPLS - Signaling Functional Description
> > (Proposed Standard)
> >    draft-ietf-mpls-generalized-signaling-09.txt
> >   Token: bwijnen
> >   Note: New revision needed
> >    Generalized MPLS Signaling - CR-LDP Extensions (Proposed Standard)
> >    draft-ietf-mpls-generalized-cr-ldp-07.txt
> >    Generalized MPLS Signaling - RSVP-TE Extensions (Proposed Standard)
> >    draft-ietf-mpls-generalized-rsvp-te-08.txt
> >
>Well.. you know I have lots of things on my plate. They are in my
>queue of things to do. I warned you many months ago to do most of
>the things that came back after IESG review. Had you done them back
>then, then probably things would have moved faster.
>Sorry to be kind of nasty here.... but could not resists.

I'll resist responding further.

> > Given that we issued new revs almost 1 month ago and there's been no
> > additional comments, what's need to progress the documents?
> >
>We need to make sure that security ADs are OK with your new text.
>You can ping them directly and re-ask the question.

sure why not, but I look to you as the responsible AD to either get a 
response or to move the document along.

>I will try and review again this week and then try to get them back
>on IESG agenda. That is: your ping did raise the priority.
>But pls do follow up with security ADs.

will do.

Lou

>Bert
> > Thanks,
> > Lou
> >
> > PS Never heard from the security ADs and the reference you
> > gave relates to
> > TCP and is appropriate for LDP, but not RSVP.
> >
> > At 03:27 PM 8/29/2002, Wijnen, Bert (Bert) wrote:
> >
> > >I still have no complete answer from the SEC ADs...
> > >But a start might be document draft-iab-sec-cons-00.txt
> > >specifically sect 4.5.1
> > >
> > >Hope this gets you started
> > >
> > >Bert
> > > > > ><draft-ietf-mpls-generalized-rsvp-te-07.txt>
> > > > > >
> > > > > >1. This doc says "just use IPsec".  A clearer
> > statement is needed,
> > > > > >    specifying the necessary IPsec selectors (per RFC
> > 2401) and the
> > > > > >    way the cryptographically protected endpoints are
> > related to
> > > > > >    the authorization model, i.e., who can do what.
> > > > >
> > > > > can you provide an example of what you'd like to see?
> > > > >
> > > >
> > > > I am checking with Security ADs.
> > > >
> >




Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 23 Sep 2002 14:58:44 -0700
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0EFFDF23@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Lou Berger <lberger@movaz.com>
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: IESG comments on generalize MPLS documents
Date: Mon, 23 Sep 2002 23:53:50 +0200
MIME-Version: 1.0
Content-Type: text/plain

> -----Original Message-----
> From: Lou Berger [mailto:lberger@movaz.com]
> Sent: maandag 23 september 2002 23:25
> To: Wijnen, Bert (Bert)
> Cc: Berger, Lou; Ccamp-wg (E-mail)
> Subject: RE: IESG comments on generalize MPLS documents
> 
> Bert, the IESG web site says:
> SUB JUN 5 Generalized MPLS - Signaling Functional Description 
> (Proposed Standard)
>    draft-ietf-mpls-generalized-signaling-09.txt
>   Token: bwijnen
>   Note: New revision needed
>    Generalized MPLS Signaling - CR-LDP Extensions (Proposed Standard)
>    draft-ietf-mpls-generalized-cr-ldp-07.txt
>    Generalized MPLS Signaling - RSVP-TE Extensions (Proposed Standard)
>    draft-ietf-mpls-generalized-rsvp-te-08.txt
> 
Well.. you know I have lots of things on my plate. They are in my
queue of things to do. I warned you many months ago to do most of
the things that came back after IESG review. Had you done them back
then, then probably things would have moved faster.
Sorry to be kind of nasty here.... but could not resists.

> Given that we issued new revs almost 1 month ago and there's been no 
> additional comments, what's need to progress the documents?
> 
We need to make sure that security ADs are OK with your new text.
You can ping them directly and re-ask the question.

I will try and review again this week and then try to get them back
on IESG agenda. That is: your ping did raise the priority.
But pls do follow up with security ADs.

Bert
> Thanks,
> Lou
> 
> PS Never heard from the security ADs and the reference you 
> gave relates to 
> TCP and is appropriate for LDP, but not RSVP.
> 
> At 03:27 PM 8/29/2002, Wijnen, Bert (Bert) wrote:
> 
> >I still have no complete answer from the SEC ADs...
> >But a start might be document draft-iab-sec-cons-00.txt
> >specifically sect 4.5.1
> >
> >Hope this gets you started
> >
> >Bert
> > > > ><draft-ietf-mpls-generalized-rsvp-te-07.txt>
> > > > >
> > > > >1. This doc says "just use IPsec".  A clearer 
> statement is needed,
> > > > >    specifying the necessary IPsec selectors (per RFC 
> 2401) and the
> > > > >    way the cryptographically protected endpoints are 
> related to
> > > > >    the authorization model, i.e., who can do what.
> > > >
> > > > can you provide an example of what you'd like to see?
> > > >
> > >
> > > I am checking with Security ADs.
> > >
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 19 Sep 2002 06:52:24 -0700
Date: Thu, 19 Sep 2002 09:33:45 -0400
From: Ron Bonica <Ronald.P.Bonica@wcom.com>
Subject: WG Last Call: draft-ietf-ccamp-lmp-06
To: ccamp@ops.ietf.org
Message-id: <DKEJJCOCJMHEFFNMLKMPKELLHHAA.Ronald.P.Bonica@wcom.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

Folks,

This message begins a WG last call for draft-ietf-ccamp-lmp-06. Last call
will end one week from today, at midnight EDT on Spetember 26, 2002.


===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli




Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 19 Sep 2002 04:51:38 -0700
Message-Id: <200209191145.HAA00335@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-lmp-06.txt
Date: Thu, 19 Sep 2002 07:45:48 -0400

--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		: Link Management Protocol (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-06.txt
	Pages		: 73
	Date		: 2002-9-18
	
For scalability purposes, multiple data links can be combined to 
form a single traffic engineering (TE) link.  Furthermore, the 
management of TE links is not restricted to in-band messaging, but 
instead can be done using out-of-band techniques.  This document 
specifies a link management protocol (LMP) that runs between 
neighboring nodes and is used to manage TE links.  Specifically, LMP 
will be used to maintain control channel connectivity, verify the 
physical connectivity of the data links, correlate the link property 
information, suppress downstream alarms, and localize link failures 
for protection/restoration purposes in multiple kinds of networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.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-lmp-06.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-06.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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-18151013.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-06.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-18151013.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 19 Sep 2002 00:33:00 -0700
Message-ID: <99EC34181384D611BE56000347227B2C0728BE@MAILHOSTNB>
From: Khuzema Pithewan <khuzema.pithewan@metro-optix.com>
To: "Mpls (E-mail)" <mpls@UU.NET>, "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: Downstream label in  ERO
Date: Thu, 19 Sep 2002 02:28:04 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Hi,

draft-ietf-mpls-generalized-rsvp-te-08 , While talking about Explicit Label
control in ERO, it says..

"If the U-bit of the subobject being examined is set (1), then value
   of the label is label to be used for upstream traffic associated with
   the bidirectional LSP.  If this label is not acceptable, a "Bad
   EXPLICIT_ROUTE object" error SHOULD be generated."

and 

"If the U-bit of the subobject being examined is clear (0), then value of
the label is copied into a new Label_Set object."

what if the downstream label in sub-object (with U-Bit cleared, getting
copied in Label_Set ) is not acceptable? 
Do we need to generate "BAD EXPLICIT_ROUTE object" error for that also?

Regards,
Khuzema.





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 18 Sep 2002 15:44:15 -0700
Message-ID: <01C25F2A.4A8A7BD0.ramsrm@tdd.sj.nec.com>
From: ramanathan rams <ramsrm@tdd.sj.nec.com>
Reply-To: "ramsrm@tdd.sj.nec.com" <ramsrm@tdd.sj.nec.com>
To: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: ISIS-TE doubts.
Date: Wed, 18 Sep 2002 15:44:34 -0700
Organization: NEC

hi all,

             I have the following doubts in  GMPLS-IGP interaction for TE.
could u please explain me?

Normally for TE purposes we use explicit path for establishing the LSP 
tunnel. For finding out the explicit path CSPF is used.

using ISIS TE extensions, the link properties are flooded within the IGP 
area level only, it's not flooded across the entire AS. if that is the case 
if we want to establish a tunnel that spans multiple areas then the L1 
router sitting in one area does not know the properties of the links 
outside that area, so we can't compute the complete constraint based path 
from that router.  if my assumptions are  wrong, please explain me the 
correct procedure to compute the complete path which spans across multiple 
areas of an IGP.


thanks
rams.




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 17 Sep 2002 20:08:39 -0700
Date: Wed, 18 Sep 2002 11:12:55 +0800
From: Liu Qiang <qliu@lit.a-star.edu.sg>
Subject: RE: Timer constraint of the HelloInterval and HelloDeadInterval
To: yhwkim@etri.re.kr, ccamp@ops.ietf.org
Message-id: <NGBBJAJGOLOECPJHDOEBKEBFCBAA.qliu@lit.a-star.edu.sg>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_hvrqPuBLxhgM3oWkDRRZAw)"

This is a multi-part message in MIME format.

--Boundary_(ID_hvrqPuBLxhgM3oWkDRRZAw)
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: 8BIT

Timer constraint of the HelloInterval
and HelloDeadIntervalHi,

   5ms and 18ms are impossible for my
implementation as the timer
granularity is about 10ms in my OS. I
chose 50ms and 180ms for test, but it
still has some "timeout" and the lmp
control channel will restart. I ever
tried 150ms and 500ms as it was
defined in the previous version of lmp
draft, but I am not sure whether these
values are too big for whole system.

Regards,

Liu Qiang
=====================
Liu Qiang    Ph.D
Optical Networking Services Group,
Laboratories for Information
Technology (LIT) (A member of A*STAR)
21 Heng Mui Keng Terrace
Singapore 119613
E-mail: qliu@lit.a-star.edu.sg
DID: +65 6874 6697
Fax: +65 6774 4998



  -----Original Message-----
  From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]On
Behalf Of yhwkim@etri.re.kr
  Sent: 2002Ҵ9��17�� 12:05
  To: ccamp@ops.ietf.org
  Subject: Timer constraint of the
HelloInterval and HelloDeadInterval


  Hi,

  I have a question of the timer
constraint of the HelloInterval and
HelloDeadInterval parameters in the
LMP dratf,
  draft-ietf-ccamp-lmp-05.txt.
  The draft have proposed as default
values of these timer, 5ms and 18ms,
respectively.
  But, the example statement above the
one describing the default values
showed 150ms for the HelloInterval.
  I think there is a eding error in
default values of 5ms and 18ms.
  Is that right?
  If so, what are the default values
of these parameters?
  If not so, could you tell me how to
implememt the Hello protocol.
  I think there is no realistic way to
implement the software based Hello
protocol.
  As an example, in the
layer-1(physical layer) based
protection of SONET/SDH network,
  the detection time for SONET/SDH is
specified with 10ms and the
restoration time with 60ms.
  The Hello protocol may be not a
layer-1 protocol, but a
layer-7(application layer).

  Thanks,
  Young


****************************************** 
  Young Hwa Kim 
  Senior Memb
er, Network Technology Lab., ETRI
  Office No. : 82-42-860-5819
  Fax No. : 82-42-860-6342
  Mobile No. : 011-433-5819
  Email addr. : yhwkim@etri.re.kr

****************************************** 



--Boundary_(ID_hvrqPuBLxhgM3oWkDRRZAw)
Content-type: text/html; charset=ks_c_5601-1987
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Timer constraint of the HelloInterval and =
HelloDeadInterval</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dks_c_5601-1987">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff size=3D2>Hi,=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; 5ms and 18ms are impossible for my implementation=20
as&nbsp;the timer granularity is about 10ms in my OS. I chose 50ms and =
180ms for=20
test, but it still has some "timeout" and the lmp control channel will =
restart.=20
I ever tried 150ms and 500ms as it was defined in the previous version =
of lmp=20
draft, but I am not sure whether these values&nbsp;are too big for whole =

system.</FONT></SPAN></DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D280515902-18092002><FONT face=3D=E1=E4&#20307; =
color=3D#0000ff size=3D2>Liu=20
Qiang</FONT></SPAN></DIV>
<DIV><SPAN class=3D280515902-18092002>
<P><FONT =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR>Liu Qiang&nbsp;&nbsp;&nbsp;=20
Ph.D<BR>Optical Networking Services Group,<BR>Laboratories for =
Information=20
Technology (LIT)<SPAN class=3D280515902-18092002> </SPAN>(A member of=20
A*STAR)<BR>21 Heng Mui Keng Terrace<BR>Singapore 119613<BR>E-mail:=20
qliu@lit.a-star.edu.sg<BR>DID: +65 6874 6697<BR>Fax: +65 6774=20
4998<BR><BR>&nbsp;</FONT> </P></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-ccamp@ops.ietf.org=20
  [mailto:owner-ccamp@ops.ietf.org]<B>On Behalf Of=20
  </B>yhwkim@etri.re.kr<BR><B>Sent:</B> 2002=D2=B49=EA=C517=EC=ED =
12:05<BR><B>To:</B>=20
  ccamp@ops.ietf.org<BR><B>Subject:</B> Timer constraint of the =
HelloInterval=20
  and HelloDeadInterval<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>I have a question of the timer constraint of the =
HelloInterval=20
  and HelloDeadInterval parameters in the LMP dratf,</FONT> <BR><FONT=20
  size=3D2>draft-ietf-ccamp-lmp-05.txt.</FONT> <BR><FONT size=3D2>The =
draft have=20
  proposed as default values of these timer, 5ms and 18ms, =
respectively.</FONT>=20
  <BR><FONT size=3D2>But, the example statement above the one describing =
the=20
  default values showed 150ms for the HelloInterval.</FONT> <BR><FONT =
size=3D2>I=20
  think there is a eding error in default values of 5ms and 18ms.</FONT> =

  <BR><FONT size=3D2>Is that right?</FONT> <BR><FONT size=3D2>If so, =
what are the=20
  default values of these parameters? </FONT><BR><FONT size=3D2>If not =
so, could=20
  you tell me how to implememt the Hello protocol.</FONT> <BR><FONT =
size=3D2>I=20
  think there is no realistic way to implement the software based Hello=20
  protocol.</FONT> <BR><FONT size=3D2>As an example, in the =
layer-1(physical=20
  layer) based protection of SONET/SDH network, </FONT><BR><FONT =
size=3D2>the=20
  detection time for SONET/SDH is specified with 10ms and the =
restoration time=20
  with 60ms.</FONT> <BR><FONT size=3D2>The Hello protocol may be not a =
layer-1=20
  protocol, but a layer-7(application layer).</FONT> </P>
  <P><FONT size=3D2>Thanks,</FONT> <BR><FONT size=3D2>Young</FONT> </P>
  <P><FONT size=3D2>****************************************** =
</FONT><BR><FONT=20
  size=3D2>Young Hwa Kim </FONT><BR><FONT size=3D2>Senior Member, =
Network Technology=20
  Lab., ETRI </FONT><BR><FONT size=3D2>Office No. : 82-42-860-5819=20
  </FONT><BR><FONT size=3D2>Fax No. : 82-42-860-6342 </FONT><BR><FONT=20
  size=3D2>Mobile No. : 011-433-5819 </FONT><BR><FONT size=3D2>Email =
addr. :=20
  yhwkim@etri.re.kr </FONT><BR><FONT=20
  size=3D2>******************************************=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_hvrqPuBLxhgM3oWkDRRZAw)--



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 17 Sep 2002 16:06:27 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB88658E2@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'yhwkim@etri.re.kr'" <yhwkim@etri.re.kr>, ccamp@ops.ietf.org
Subject: RE: Timer constraint of the HelloInterval and HelloDeadInterval
Date: Tue, 17 Sep 2002 16:00:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="KS_C_5601-1987"

Young,
  The default values have been modified to read 150ms and 500ms,
respectively. This change will be reflected in the -06 version of LMP.

Thanks,
Jonathan

-----Original Message-----
From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr]
Sent: Monday, September 16, 2002 9:05 PM
To: ccamp@ops.ietf.org
Subject: Timer constraint of the HelloInterval and HelloDeadInterval


Hi, 
I have a question of the timer constraint of the HelloInterval and
HelloDeadInterval parameters in the LMP dratf, 
draft-ietf-ccamp-lmp-05.txt. 
The draft have proposed as default values of these timer, 5ms and 18ms,
respectively. 
But, the example statement above the one describing the default values
showed 150ms for the HelloInterval. 
I think there is a eding error in default values of 5ms and 18ms. 
Is that right? 
If so, what are the default values of these parameters? 
If not so, could you tell me how to implememt the Hello protocol. 
I think there is no realistic way to implement the software based Hello
protocol. 
As an example, in the layer-1(physical layer) based protection of SONET/SDH
network, 
the detection time for SONET/SDH is specified with 10ms and the restoration
time with 60ms. 
The Hello protocol may be not a layer-1 protocol, but a layer-7(application
layer). 
Thanks, 
Young 
****************************************** 
Young Hwa Kim 
Senior Member, Network Technology Lab., ETRI 
Office No. : 82-42-860-5819 
Fax No. : 82-42-860-6342 
Mobile No. : 011-433-5819 
Email addr. : yhwkim@etri.re.kr 
****************************************** 



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 17 Sep 2002 08:51:52 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE5DC@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: Clarification needed re: IF Index TLV in RSVP_HOP
Date: Tue, 17 Sep 2002 11:41:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

In draft-ietf-mpls-generalized-signaling-09, page 25 it says:


   In cases where there is not an explicit one-to-one association of
   control channels to data channels it is necessary to convey
   additional information in signaling to identify the particular data
   channel being controlled.  GMPLS supports explicit data channel
   identification by providing interface identification information.
   GMPLS allows the use of a number of interface identification schemes
   including IPv4 or IPv6 addresses, interface indexes (see [MPLS-
   UNNUM]) and component interfaces (established via configuration or a
   protocol such as [LMP]).  ***In all cases the choice of the data
   interface is indicated by the upstream node using addresses and
   identifiers used by the upstream node.***

The final sentence is clear enough for the Path message. The RSVP_HOP object
will specify the router ID and local link identifier according to the LSR
generating the Path message. It is not clear what is intended in the Reserve
message. I am guessing it is again the router ID and local link identifier,
but this time according to the generator of the Reserve message. However, I
can imagine other alternatives. Can someone in the know help out?

Thanks

> Michael Mandelberg
> FirstWave Intelligent Optical Networks, Inc.
> 11800 Sunrise Valley Drive, 15th floor
> Reston, Virginia 20191
> (703) 390 - 9401, x 1008
> mmandelberg@fwion.com
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 17 Sep 2002 05:06:14 -0700
Message-Id: <200209171158.HAA10973@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-lmp-wdm-01.txt
Date: Tue, 17 Sep 2002 07:58:58 -0400

--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		: Link Management Protocol (LMP) for DWDM Optical Line 
                          Systems
	Author(s)	: A. Fredette, J. Lang
	Filename	: draft-ietf-ccamp-lmp-wdm-01.txt
	Pages		: 13
	Date		: 2002-9-16
	
The Link Management Protocol (LMP) is defined to manage traffic 
engineering (TE) links.  In its present form, LMP focuses on peer 
nodes; i.e., nodes that peer in signaling and/or routing.  In this 
document we propose extensions to LMP to allow it to be used between 
a peer node and an adjacent optical line system (OLS).  These 
extensions are intended to satisfy the 'Optical Link Interface 
Requirements' described in a companion document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-wdm-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-ietf-ccamp-lmp-wdm-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-wdm-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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-16151748.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-wdm-01.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-16151748.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 17 Sep 2002 05:05:42 -0700
Message-Id: <200209171200.IAA11234@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: te-wg@ops.ietf.org, ospf@discuss.microsoft.com, ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-srisuresh-ospf-te-03.txt
Date: Tue, 17 Sep 2002 08:00:04 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Traffic Engineering Working Group of the IETF.

	Title		: TE LSAs to extend OSPF for Traffic Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-03.txt
	Pages		: 42
	Date		: 2002-9-16
	
OSPF is a link state routing protocol used for IP-network 
topology discovery and collection and dissemination of link
access metrics. The resulting Link State Database (LSDB) is
used to compute IP address forwarding table based on 
shortest-path criteria. Traffic Engineering extensions(OSPF-TE)
outlined in this document are built on the native OSPF
foundation, utilizing new LSAs, designed specifically for TE.
OSPF-TE sets out to discover TE network topology and perform
collection and dissemination of TE metrics within the TE network.
This results in the generation of an independent TE-LSDB, that
would permit computation of TE circuit paths. Unlike the native
OSPF link metrics, TE metrics can be rapidly changing and
varied across different elements of the network. TE circuit
paths are computed using varied TE criteria, often different
from the shortest-path, to route traffic around congestion
paths. Principal motivations to designing the OSPF-TE over
[OPQLSA-TE] and transition path for vendors currently using
[OPQLSA-TE] to adapt the OSPF-TE are outlined in separate
sections within the document. OSPF-TE provides a single unified
mechanism for traffic engineering across packet and non-packet
networks, and may be adapted for a peer networking model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-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-srisuresh-ospf-te-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-srisuresh-ospf-te-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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-16151944.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2002-9-16151944.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 16 Sep 2002 21:13:57 -0700
Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08A75C89@cms1.etri.re.kr>
From: yhwkim@etri.re.kr
To: ccamp@ops.ietf.org
Subject: Timer constraint of the HelloInterval and HelloDeadInterval
Date: Tue, 17 Sep 2002 13:04:56 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25DFF.6234B420"

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

------_=_NextPart_001_01C25DFF.6234B420
Content-Type: text/plain;
	charset="euc-kr"

Hi,

I have a question of the timer constraint of the HelloInterval and
HelloDeadInterval parameters in the LMP dratf,
draft-ietf-ccamp-lmp-05.txt.
The draft have proposed as default values of these timer, 5ms and 18ms,
respectively.
But, the example statement above the one describing the default values
showed 150ms for the HelloInterval.
I think there is a eding error in default values of 5ms and 18ms.
Is that right?
If so, what are the default values of these parameters? 
If not so, could you tell me how to implememt the Hello protocol.
I think there is no realistic way to implement the software based Hello
protocol.
As an example, in the layer-1(physical layer) based protection of SONET/SDH
network, 
the detection time for SONET/SDH is specified with 10ms and the restoration
time with 60ms.
The Hello protocol may be not a layer-1 protocol, but a layer-7(application
layer).

Thanks,
Young

****************************************** 
Young Hwa Kim 
Senior Member, Network Technology Lab., ETRI 
Office No. : 82-42-860-5819 
Fax No. : 82-42-860-6342 
Mobile No. : 011-433-5819 
Email addr. : yhwkim@etri.re.kr 
****************************************** 

------_=_NextPart_001_01C25DFF.6234B420
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Timer constraint of the HelloInterval and HelloDeadInterval</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>I have a question of the timer constraint of the HelloInterval and HelloDeadInterval parameters in the LMP dratf,</FONT>
<BR><FONT SIZE=2>draft-ietf-ccamp-lmp-05.txt.</FONT>
<BR><FONT SIZE=2>The draft have proposed as default values of these timer, 5ms and 18ms, respectively.</FONT>
<BR><FONT SIZE=2>But, the example statement above the one describing the default values showed 150ms for the HelloInterval.</FONT>
<BR><FONT SIZE=2>I think there is a eding error in default values of 5ms and 18ms.</FONT>
<BR><FONT SIZE=2>Is that right?</FONT>
<BR><FONT SIZE=2>If so, what are the default values of these parameters? </FONT>
<BR><FONT SIZE=2>If not so, could you tell me how to implememt the Hello protocol.</FONT>
<BR><FONT SIZE=2>I think there is no realistic way to implement the software based Hello protocol.</FONT>
<BR><FONT SIZE=2>As an example, in the layer-1(physical layer) based protection of SONET/SDH network, </FONT>
<BR><FONT SIZE=2>the detection time for SONET/SDH is specified with 10ms and the restoration time with 60ms.</FONT>
<BR><FONT SIZE=2>The Hello protocol may be not a layer-1 protocol, but a layer-7(application layer).</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Young</FONT>
</P>

<P><FONT SIZE=2>****************************************** </FONT>
<BR><FONT SIZE=2>Young Hwa Kim </FONT>
<BR><FONT SIZE=2>Senior Member, Network Technology Lab., ETRI </FONT>
<BR><FONT SIZE=2>Office No. : 82-42-860-5819 </FONT>
<BR><FONT SIZE=2>Fax No. : 82-42-860-6342 </FONT>
<BR><FONT SIZE=2>Mobile No. : 011-433-5819 </FONT>
<BR><FONT SIZE=2>Email addr. : yhwkim@etri.re.kr </FONT>
<BR><FONT SIZE=2>****************************************** </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25DFF.6234B420--



Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 13 Sep 2002 09:22:17 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD337D@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Fri, 13 Sep 2002 09:17:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi,

Not wanting to fan the flames again, but can someone
respond to Bert's question?  What was the reasoning
behind adding the new section on trace monitoring?

Will the main LMP draft also be updated to include
the trace function (presumably optional)?  For that
matter, is it clear that trace monitoring is a
SONET/SDH-specific function (anything apply to
G.709, for example)?

Thanks,

Lyndon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Wednesday, September 11, 2002 5:15 PM
To: ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt


Instead of having a(nother) flame war over if this is or is
not a WG doc right away, it would be better to ask the editors
as to why they thought they needed to add the new material.

As far as I can tell from a quick browse through the doc, it
seems that the new material is all the text in section 4.

So editors, what piece of comment raised by me or others on the
WG mailing list is being addressed by section 4 of this new document?

Thanks,
Bert 




Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 12 Sep 2002 00:14:13 -0700
Date: Thu, 12 Sep 2002 00:10:23 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
To: Jonathan Lang <jplang@calient.net>
cc: "'Ong, Lyndon'" <LyOng@ciena.com>, "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>, "Bernstein, Greg" <GregB@ciena.com>, <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Message-ID: <20020912000345.Q1312-100000@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Jonathan,

On Wed, 11 Sep 2002, Jonathan Lang wrote:

> Section 4 is SONET/SDH technology specific text taken from Section 3.6 of
> draft-ietf-ccamp-lmp-wdm-00.txt.

Thanks for the detailed explanation.  To round this out, it would make
sense to re-issue lmp-wdm (it's past expiry, so it's good to re-issue
this anyway), and take out the material that's been moved to the lmp
sonet-sdh doc.

It would also be good to say in a changes-since-last-version section
where exactly the new text went.

Kireeti.




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 17:15:45 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD3367@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 17:15:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

I suppose that I missed something - was LMP-WDM 
previously incorporated into the LMP specification?
That would explain how something from LMP-WDM 
has somehow become a draft "separated" from
LMP...

I thought that before going to Working Group
Last Call that a draft should at least be given
some review, perhaps even the opportunity given
for people to consider alternatives.

But I see that you speak for "our community" so
everyone else must agree with you!

Cheers,

Lyndon

 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Wednesday, September 11, 2002 4:49 PM
To: Ong, Lyndon
Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt


hi,

that's not complicated the text is basically the one that
was included in other wg i-d's concerning among other sonet/sdh 
(in particular draft-ietf-ccamp-lmp-wdm-00.txt) and we include 
it in this i-d - since they were intimately related - and put
it in section 4 were you will read that we put all our attention
in order to avoid any "mandatory" mechanism (following our 
previous mailing discussions)

therefore we follow the rule of more consistence "include all 
the technology specific mechanism" in a dedicated i-d;

consequently i don't really see where the assertion "not endorsed 
by the wg" applies and as said by kireeti this i-d will undergo 
a wg last call thus here i don't see why you think the content 
won't be "reviewed" by the ccamp community

hope this clarifies (once for all) the non-technical part of
this discussion - this said our community is still asking for 
any valuable technical comment on these wg i-d's -

thanks,
- dimitri.

"Ong, Lyndon" wrote:
> 
> Hi Dimitri,
> 
> This is not complicated, "separation" sounds like you take
> an existing WG draft text and split some of it off into a
> separate document, as was in fact done with the earlier
> gmpls signaling documents that you pointed out.
> 
> Here, there was basically a new set of text created from
> scratch, so it is more akin to a new individual draft
> and the text has not been reviewed or endorsed by the WG.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, September 11, 2002 11:10 AM
> To: Ong, Lyndon
> Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> hi,
> 
> i suggest that you take another look at the document
> because it clearly says "In [LMP], a link verification
> procedure is defined whereby Test messages are transmitted
> in-band over the data links.  This is used for data plane
> discovery, Interface_Id exchange (Interface_Ids are used
> in GMPLS signaling, either as port labels [GMPLS-SIG] or
> component link identifiers [BUNDLE], depending on the
> configuration), and physical connectivity verification."
> 
> thus complete the sentence by saying that this document
> uses a "generic mechanism" the link verification as
> defined in [LMP], for (among other) discovery purposes
> and this i-d describes the way to achieve it for sonet/
> sdh environments, thus we follow the ad's advices by
> meeting the mailing list comments ...
> 
> ... by the way an update of the bootstrap document has
> been issued addressing the valuable comments we have
> received through the ccamp mailing list:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-01.txt
> 
> the first comment is difficult to understand from the
> technical viewpoint (imho you agree on an assertion this
> does not make this assertion more valid) by the way when
> we split the gmpls signalling into gmpls-sonet-sdh you
> were much less shooting than today - and there the text
> was *really* different - what happened since then ? do i
> have to understand that you would like to build a car w/o
> its wheels (but... this is your *individual* choice)
> 
> thanks,
> - dimitri.
> 
> "Ong, Lyndon" wrote:
> >
> > Hi Kireeti,
> >
> > What is confusing people is that the new draft is not text
> > split off from the original LMP specification but almost
> > entirely new text and subject matter, as Zhi points out.
> >
> > Also, concerns were expressed on the mailing list that some
> > of the functions in LMP were not applicable in SONET/SDH,
> > _including_ link verification.  The new draft is basically
> > a set of extensions _to_ link verification.
> >
> > Cheers,
> >
> > L. Ong
> > Ciena
> >
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, September 11, 2002 9:06 AM
> > To: Bernstein, Greg
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> >
> > On Wed, 11 Sep 2002, Bernstein, Greg wrote:
> >
> > > This draft seems to contain new material not in LMP.  How can it be
> > already
> > > considered a working group item for CCAMP?
> >
> > draft-ietf-ccamp-lmp-01.txt had material that was not already in
> > draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
> > group document item for CCAMP?  und so weiter ...  Are you suggesting
> > a new process for documents in the IETF, or is it just for documents
> > whose name contains the string 'lmp'?
> >
> > <chair>
> > This draft is a separation of the original LMP draft into two documents,
> > as suggested by the primary AD: a *base* document, technology-agnostic,
> > and a SONET-SDH specific document.
> >
> > The fact that the latter document has new material is in response to
> > requests from folks in CCAMP.  Both documents will undergo another WG
> > Last Call.
> > </chair>
> >
> > Kireeti.



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 17:15:27 -0700
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0EE455A0@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Thu, 12 Sep 2002 02:14:47 +0200
MIME-Version: 1.0
Content-Type: text/plain

Instead of having a(nother) flame war over if this is or is
not a WG doc right away, it would be better to ask the editors
as to why they thought they needed to add the new material.

As far as I can tell from a quick browse through the doc, it
seems that the new material is all the text in section 4.

So editors, what piece of comment raised by me or others on the
WG mailing list is being addressed by section 4 of this new document?

Thanks,
Bert 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 17:07:06 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8865893@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'Ong, Lyndon'" <LyOng@ciena.com>,  "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>
Cc: 'Kireeti Kompella' <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 17:06:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Lyndon,
  draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt has 4 basic sections:
1) Introduction
2) Terminology
3) Verifying Link Connectivity
4) Trace Monitoring

Section 1 and 2 provide context for the draft. Nothing new here.
Section 3 gives an overview of Link Verification. Again, nothing new here.
Section 3.1 provides details of the various options for the Verify Transport
Mechanism when the encoding is SONET/SDH. Of these, the first 4 options came
from Section 14.8 of draft-ietf-ccamp-lmp-04.txt with the clarification
posted to the list in response to Jonathan Sadler's doubt. The remaining
options are new based on comments to the list that additional trail trace
identifier strings (J1, J2) could be used.
Section 4 is SONET/SDH technology specific text taken from Section 3.6 of
draft-ietf-ccamp-lmp-wdm-00.txt.

Thanks,
Jonathan

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@ciena.com]
> Sent: Wednesday, September 11, 2002 4:03 PM
> To: 'Dimitri.Papadimitriou@alcatel.be'
> Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
> Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> 
> Hi Dimitri,
> 
> This is not complicated, "separation" sounds like you take
> an existing WG draft text and split some of it off into a
> separate document, as was in fact done with the earlier
> gmpls signaling documents that you pointed out.
> 
> Here, there was basically a new set of text created from
> scratch, so it is more akin to a new individual draft
> and the text has not been reviewed or endorsed by the WG.
> 
> 
> Cheers,
> 
> Lyndon
> 
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, September 11, 2002 11:10 AM
> To: Ong, Lyndon
> Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> 
> hi,
> 
> i suggest that you take another look at the document
> because it clearly says "In [LMP], a link verification 
> procedure is defined whereby Test messages are transmitted 
> in-band over the data links.  This is used for data plane 
> discovery, Interface_Id exchange (Interface_Ids are used 
> in GMPLS signaling, either as port labels [GMPLS-SIG] or 
> component link identifiers [BUNDLE], depending on the 
> configuration), and physical connectivity verification."
> 
> thus complete the sentence by saying that this document
> uses a "generic mechanism" the link verification as
> defined in [LMP], for (among other) discovery purposes 
> and this i-d describes the way to achieve it for sonet/
> sdh environments, thus we follow the ad's advices by 
> meeting the mailing list comments ...
> 
> ... by the way an update of the bootstrap document has
> been issued addressing the valuable comments we have
> received through the ccamp mailing list:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-01.txt
> 
> the first comment is difficult to understand from the 
> technical viewpoint (imho you agree on an assertion this 
> does not make this assertion more valid) by the way when 
> we split the gmpls signalling into gmpls-sonet-sdh you 
> were much less shooting than today - and there the text 
> was *really* different - what happened since then ? do i 
> have to understand that you would like to build a car w/o 
> its wheels (but... this is your *individual* choice)
> 
> thanks,
> - dimitri.
> 
> "Ong, Lyndon" wrote:
> > 
> > Hi Kireeti,
> > 
> > What is confusing people is that the new draft is not text
> > split off from the original LMP specification but almost
> > entirely new text and subject matter, as Zhi points out.
> > 
> > Also, concerns were expressed on the mailing list that some
> > of the functions in LMP were not applicable in SONET/SDH,
> > _including_ link verification.  The new draft is basically
> > a set of extensions _to_ link verification.
> > 
> > Cheers,
> > 
> > L. Ong
> > Ciena
> > 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, September 11, 2002 9:06 AM
> > To: Bernstein, Greg
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> > 
> > On Wed, 11 Sep 2002, Bernstein, Greg wrote:
> > 
> > > This draft seems to contain new material not in LMP.  How 
> can it be
> > already
> > > considered a working group item for CCAMP?
> > 
> > draft-ietf-ccamp-lmp-01.txt had material that was not already in
> > draft-ietf-ccamp-lmp-00.txt.  How can it be already 
> considered a working
> > group document item for CCAMP?  und so weiter ...  Are you 
> suggesting
> > a new process for documents in the IETF, or is it just for documents
> > whose name contains the string 'lmp'?
> > 
> > <chair>
> > This draft is a separation of the original LMP draft into 
> two documents,
> > as suggested by the primary AD: a *base* document, 
> technology-agnostic,
> > and a SONET-SDH specific document.
> > 
> > The fact that the latter document has new material is in response to
> > requests from folks in CCAMP.  Both documents will undergo 
> another WG
> > Last Call.
> > </chair>
> > 
> > Kireeti.
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 16:48:33 -0700
Message-ID: <3D7FD650.7F78EC14@alcatel.be>
Date: Thu, 12 Sep 2002 01:48:32 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: "Ong, Lyndon" <LyOng@ciena.com>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

hi,

that's not complicated the text is basically the one that
was included in other wg i-d's concerning among other sonet/sdh 
(in particular draft-ietf-ccamp-lmp-wdm-00.txt) and we include 
it in this i-d - since they were intimately related - and put
it in section 4 were you will read that we put all our attention
in order to avoid any "mandatory" mechanism (following our 
previous mailing discussions)

therefore we follow the rule of more consistence "include all 
the technology specific mechanism" in a dedicated i-d;

consequently i don't really see where the assertion "not endorsed 
by the wg" applies and as said by kireeti this i-d will undergo 
a wg last call thus here i don't see why you think the content 
won't be "reviewed" by the ccamp community

hope this clarifies (once for all) the non-technical part of
this discussion - this said our community is still asking for 
any valuable technical comment on these wg i-d's -

thanks,
- dimitri.

"Ong, Lyndon" wrote:
> 
> Hi Dimitri,
> 
> This is not complicated, "separation" sounds like you take
> an existing WG draft text and split some of it off into a
> separate document, as was in fact done with the earlier
> gmpls signaling documents that you pointed out.
> 
> Here, there was basically a new set of text created from
> scratch, so it is more akin to a new individual draft
> and the text has not been reviewed or endorsed by the WG.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, September 11, 2002 11:10 AM
> To: Ong, Lyndon
> Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> hi,
> 
> i suggest that you take another look at the document
> because it clearly says "In [LMP], a link verification
> procedure is defined whereby Test messages are transmitted
> in-band over the data links.  This is used for data plane
> discovery, Interface_Id exchange (Interface_Ids are used
> in GMPLS signaling, either as port labels [GMPLS-SIG] or
> component link identifiers [BUNDLE], depending on the
> configuration), and physical connectivity verification."
> 
> thus complete the sentence by saying that this document
> uses a "generic mechanism" the link verification as
> defined in [LMP], for (among other) discovery purposes
> and this i-d describes the way to achieve it for sonet/
> sdh environments, thus we follow the ad's advices by
> meeting the mailing list comments ...
> 
> ... by the way an update of the bootstrap document has
> been issued addressing the valuable comments we have
> received through the ccamp mailing list:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-01.txt
> 
> the first comment is difficult to understand from the
> technical viewpoint (imho you agree on an assertion this
> does not make this assertion more valid) by the way when
> we split the gmpls signalling into gmpls-sonet-sdh you
> were much less shooting than today - and there the text
> was *really* different - what happened since then ? do i
> have to understand that you would like to build a car w/o
> its wheels (but... this is your *individual* choice)
> 
> thanks,
> - dimitri.
> 
> "Ong, Lyndon" wrote:
> >
> > Hi Kireeti,
> >
> > What is confusing people is that the new draft is not text
> > split off from the original LMP specification but almost
> > entirely new text and subject matter, as Zhi points out.
> >
> > Also, concerns were expressed on the mailing list that some
> > of the functions in LMP were not applicable in SONET/SDH,
> > _including_ link verification.  The new draft is basically
> > a set of extensions _to_ link verification.
> >
> > Cheers,
> >
> > L. Ong
> > Ciena
> >
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, September 11, 2002 9:06 AM
> > To: Bernstein, Greg
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> >
> > On Wed, 11 Sep 2002, Bernstein, Greg wrote:
> >
> > > This draft seems to contain new material not in LMP.  How can it be
> > already
> > > considered a working group item for CCAMP?
> >
> > draft-ietf-ccamp-lmp-01.txt had material that was not already in
> > draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
> > group document item for CCAMP?  und so weiter ...  Are you suggesting
> > a new process for documents in the IETF, or is it just for documents
> > whose name contains the string 'lmp'?
> >
> > <chair>
> > This draft is a separation of the original LMP draft into two documents,
> > as suggested by the primary AD: a *base* document, technology-agnostic,
> > and a SONET-SDH specific document.
> >
> > The fact that the latter document has new material is in response to
> > requests from folks in CCAMP.  Both documents will undergo another WG
> > Last Call.
> > </chair>
> >
> > Kireeti.



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 16:05:26 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD3364@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 16:02:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

This is not complicated, "separation" sounds like you take
an existing WG draft text and split some of it off into a
separate document, as was in fact done with the earlier
gmpls signaling documents that you pointed out.

Here, there was basically a new set of text created from
scratch, so it is more akin to a new individual draft
and the text has not been reviewed or endorsed by the WG.


Cheers,

Lyndon


-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Wednesday, September 11, 2002 11:10 AM
To: Ong, Lyndon
Cc: 'Kireeti Kompella'; Bernstein, Greg; ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt


hi,

i suggest that you take another look at the document
because it clearly says "In [LMP], a link verification 
procedure is defined whereby Test messages are transmitted 
in-band over the data links.  This is used for data plane 
discovery, Interface_Id exchange (Interface_Ids are used 
in GMPLS signaling, either as port labels [GMPLS-SIG] or 
component link identifiers [BUNDLE], depending on the 
configuration), and physical connectivity verification."

thus complete the sentence by saying that this document
uses a "generic mechanism" the link verification as
defined in [LMP], for (among other) discovery purposes 
and this i-d describes the way to achieve it for sonet/
sdh environments, thus we follow the ad's advices by 
meeting the mailing list comments ...

... by the way an update of the bootstrap document has
been issued addressing the valuable comments we have
received through the ccamp mailing list:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-01.txt

the first comment is difficult to understand from the 
technical viewpoint (imho you agree on an assertion this 
does not make this assertion more valid) by the way when 
we split the gmpls signalling into gmpls-sonet-sdh you 
were much less shooting than today - and there the text 
was *really* different - what happened since then ? do i 
have to understand that you would like to build a car w/o 
its wheels (but... this is your *individual* choice)

thanks,
- dimitri.

"Ong, Lyndon" wrote:
> 
> Hi Kireeti,
> 
> What is confusing people is that the new draft is not text
> split off from the original LMP specification but almost
> entirely new text and subject matter, as Zhi points out.
> 
> Also, concerns were expressed on the mailing list that some
> of the functions in LMP were not applicable in SONET/SDH,
> _including_ link verification.  The new draft is basically
> a set of extensions _to_ link verification.
> 
> Cheers,
> 
> L. Ong
> Ciena
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, September 11, 2002 9:06 AM
> To: Bernstein, Greg
> Cc: ccamp@ops.ietf.org
> Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> On Wed, 11 Sep 2002, Bernstein, Greg wrote:
> 
> > This draft seems to contain new material not in LMP.  How can it be
> already
> > considered a working group item for CCAMP?
> 
> draft-ietf-ccamp-lmp-01.txt had material that was not already in
> draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
> group document item for CCAMP?  und so weiter ...  Are you suggesting
> a new process for documents in the IETF, or is it just for documents
> whose name contains the string 'lmp'?
> 
> <chair>
> This draft is a separation of the original LMP draft into two documents,
> as suggested by the primary AD: a *base* document, technology-agnostic,
> and a SONET-SDH specific document.
> 
> The fact that the latter document has new material is in response to
> requests from folks in CCAMP.  Both documents will undergo another WG
> Last Call.
> </chair>
> 
> Kireeti.



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 11:11:21 -0700
Message-ID: <3D7F870A.B09BC977@alcatel.be>
Date: Wed, 11 Sep 2002 20:10:18 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: "Ong, Lyndon" <LyOng@ciena.com>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

hi,

i suggest that you take another look at the document
because it clearly says "In [LMP], a link verification 
procedure is defined whereby Test messages are transmitted 
in-band over the data links.  This is used for data plane 
discovery, Interface_Id exchange (Interface_Ids are used 
in GMPLS signaling, either as port labels [GMPLS-SIG] or 
component link identifiers [BUNDLE], depending on the 
configuration), and physical connectivity verification."

thus complete the sentence by saying that this document
uses a "generic mechanism" the link verification as
defined in [LMP], for (among other) discovery purposes 
and this i-d describes the way to achieve it for sonet/
sdh environments, thus we follow the ad's advices by 
meeting the mailing list comments ...

... by the way an update of the bootstrap document has
been issued addressing the valuable comments we have
received through the ccamp mailing list:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-01.txt

the first comment is difficult to understand from the 
technical viewpoint (imho you agree on an assertion this 
does not make this assertion more valid) by the way when 
we split the gmpls signalling into gmpls-sonet-sdh you 
were much less shooting than today - and there the text 
was *really* different - what happened since then ? do i 
have to understand that you would like to build a car w/o 
its wheels (but... this is your *individual* choice)

thanks,
- dimitri.

"Ong, Lyndon" wrote:
> 
> Hi Kireeti,
> 
> What is confusing people is that the new draft is not text
> split off from the original LMP specification but almost
> entirely new text and subject matter, as Zhi points out.
> 
> Also, concerns were expressed on the mailing list that some
> of the functions in LMP were not applicable in SONET/SDH,
> _including_ link verification.  The new draft is basically
> a set of extensions _to_ link verification.
> 
> Cheers,
> 
> L. Ong
> Ciena
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, September 11, 2002 9:06 AM
> To: Bernstein, Greg
> Cc: ccamp@ops.ietf.org
> Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
> 
> On Wed, 11 Sep 2002, Bernstein, Greg wrote:
> 
> > This draft seems to contain new material not in LMP.  How can it be
> already
> > considered a working group item for CCAMP?
> 
> draft-ietf-ccamp-lmp-01.txt had material that was not already in
> draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
> group document item for CCAMP?  und so weiter ...  Are you suggesting
> a new process for documents in the IETF, or is it just for documents
> whose name contains the string 'lmp'?
> 
> <chair>
> This draft is a separation of the original LMP draft into two documents,
> as suggested by the primary AD: a *base* document, technology-agnostic,
> and a SONET-SDH specific document.
> 
> The fact that the latter document has new material is in response to
> requests from folks in CCAMP.  Both documents will undergo another WG
> Last Call.
> </chair>
> 
> Kireeti.



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 10:26:55 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD3361@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, "Bernstein, Greg" <GregB@ciena.com>
Cc: ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 10:24:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

What is confusing people is that the new draft is not text 
split off from the original LMP specification but almost
entirely new text and subject matter, as Zhi points out.

Also, concerns were expressed on the mailing list that some
of the functions in LMP were not applicable in SONET/SDH,
_including_ link verification.  The new draft is basically
a set of extensions _to_ link verification.

Cheers,

L. Ong
Ciena

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Wednesday, September 11, 2002 9:06 AM
To: Bernstein, Greg
Cc: ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt


On Wed, 11 Sep 2002, Bernstein, Greg wrote:

> This draft seems to contain new material not in LMP.  How can it be
already
> considered a working group item for CCAMP?

draft-ietf-ccamp-lmp-01.txt had material that was not already in
draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
group document item for CCAMP?  und so weiter ...  Are you suggesting
a new process for documents in the IETF, or is it just for documents
whose name contains the string 'lmp'?

<chair>
This draft is a separation of the original LMP draft into two documents,
as suggested by the primary AD: a *base* document, technology-agnostic,
and a SONET-SDH specific document.

The fact that the latter document has new material is in response to
requests from folks in CCAMP.  Both documents will undergo another WG
Last Call.
</chair>

Kireeti.





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 09:28:38 -0700
Message-ID: <3D7F6EDF.5020703@lucent.com>
Date: Wed, 11 Sep 2002 12:27:11 -0400
From: Zhi-Wei Lin <zwlin@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: "Bernstein, Greg" <GregB@ciena.com>, ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Kireeti,

So you contend then that <draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt> 
was a result of pulling stuff out of LMP. Then can I ask you to provide 
references (specific sections) in the original LMP document where the 
bulk of the text was taken?

Also, based on what you say, no I don't think we're suggesting any 
change to IETF process. Changing an existing WG document from one 
version to another is always done and always will be done based on 
additional considerations and input from the WG based on consensus. 
However, when creating a completely new/separate document then there is 
a question of how that new document gets WG status while another 
document that was submitted that probably is more consistent with the 
transport technology was not made into a WG document.

Zhi


Kireeti Kompella wrote:

>On Wed, 11 Sep 2002, Bernstein, Greg wrote:
>
>  
>
>>This draft seems to contain new material not in LMP.  How can it be already
>>considered a working group item for CCAMP?
>>    
>>
>
>draft-ietf-ccamp-lmp-01.txt had material that was not already in
>draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
>group document item for CCAMP?  und so weiter ...  Are you suggesting
>a new process for documents in the IETF, or is it just for documents
>whose name contains the string 'lmp'?
>
><chair>
>This draft is a separation of the original LMP draft into two documents,
>as suggested by the primary AD: a *base* document, technology-agnostic,
>and a SONET-SDH specific document.
>
>The fact that the latter document has new material is in response to
>requests from folks in CCAMP.  Both documents will undergo another WG
>Last Call.
></chair>
>
>Kireeti.
>
>
>  
>




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 09:08:32 -0700
Date: Wed, 11 Sep 2002 09:06:23 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
To: "Bernstein, Greg" <GregB@ciena.com>
cc: <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Message-ID: <20020911085525.C70058-100000@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Sep 2002, Bernstein, Greg wrote:

> This draft seems to contain new material not in LMP.  How can it be already
> considered a working group item for CCAMP?

draft-ietf-ccamp-lmp-01.txt had material that was not already in
draft-ietf-ccamp-lmp-00.txt.  How can it be already considered a working
group document item for CCAMP?  und so weiter ...  Are you suggesting
a new process for documents in the IETF, or is it just for documents
whose name contains the string 'lmp'?

<chair>
This draft is a separation of the original LMP draft into two documents,
as suggested by the primary AD: a *base* document, technology-agnostic,
and a SONET-SDH specific document.

The fact that the latter document has new material is in response to
requests from folks in CCAMP.  Both documents will undergo another WG
Last Call.
</chair>

Kireeti.




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 08:28:14 -0700
Message-ID: <3D7F60B9.5090503@lucent.com>
Date: Wed, 11 Sep 2002 11:26:49 -0400
From: Zhi-Wei Lin <zwlin@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: "Bernstein, Greg" <GregB@ciena.com>
CC: ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Yes, similar question. If I compare 
<draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt> with 
<draft-everdingen-ccamp-lmp-update-00.txt>

I would consider the one submitted by Michiel and Greg as more 
consistent with the transport network operation, and would like to see 
draft-everdingen-... progressed forward instead.

Zhi


Bernstein, Greg wrote:

>This draft seems to contain new material not in LMP.  How can it be already
>considered a working group item for CCAMP?
>
>Greg B.
>
>-----Original Message-----
>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>Sent: Wednesday, September 11, 2002 5:01 AM
>To: IETF-Announce; @ops.ietf.org
>Cc: ccamp@ops.ietf.org
>Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
>
>
>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		: SONET/SDH Encoding for Link Management Protocol
>(LMP) 
>                          Test messages
>	Author(s)	: J. Lang, D. Papadimitriou
>	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
>	Pages		: 15
>	Date		: 2002-9-10
>	
>This document details the Synchronous Optical NETwork 
>(SONET)/Synchronous Digital Hierarchy (SDH) technology specific 
>information needed when sending Link Management Protocol (LMP) test 
>messages
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.t
>xt
>
>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-lmp-test-sonet-sdh-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>  
>




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 08:18:22 -0700
Message-ID: <2135200C183FD5119588009027DE572301F1AB30@wntcsdexg02.csd.ciena.com>
From: "Bernstein, Greg" <GregB@ciena.com>
To: ccamp@ops.ietf.org
Subject: RE: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 08:16:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

This draft seems to contain new material not in LMP.  How can it be already
considered a working group item for CCAMP?

Greg B.

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, September 11, 2002 5:01 AM
To: IETF-Announce; @ops.ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt


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		: SONET/SDH Encoding for Link Management Protocol
(LMP) 
                          Test messages
	Author(s)	: J. Lang, D. Papadimitriou
	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
	Pages		: 15
	Date		: 2002-9-10
	
This document details the Synchronous Optical NETwork 
(SONET)/Synchronous Digital Hierarchy (SDH) technology specific 
information needed when sending Link Management Protocol (LMP) test 
messages

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.t
xt

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-lmp-test-sonet-sdh-00.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 07:56:30 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE56E@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: Diego Caviglia <Diego.Caviglia@marconi.com>
Cc: ccamp <ccamp@ops.ietf.org>
Subject: RE: G.RSVP-TE in OTN - Refresh mechanism
Date: Wed, 11 Sep 2002 10:48:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Diego,

The full paragraph reads:

   During this waiting period, all Hello messages MUST be sent with a
   Dst_Instance value set to zero (0), and Src_Instance should be
   unchanged.  While waiting, the node SHOULD also preserve the RSVP and
   MPLS forwarding state for (already) established LSPs that traverse
   the link(s) between the node and the neighbor.  In a sense with
   respect to established LSPs the node behaves as if it continues to
   receive periodic RSVP refresh messages from the neighbor.  The node
   MAY clear RSVP and forwarding state for the LSPs that are in the
   process of being established when their refresh timers expire.
   Refreshing of Resv and Path state SHOULD be suppressed during this
   waiting period.



The clear intent is that established LSPs SHOULD not be torn down due to a
loss of refresh messages when RSVP knows that the control channel is not
functional. LSPs that are not yet fully established MAY be torn down.

Still, all of this is in the context of using this optional procedure. Does
this apply when the optional procedure is not used, but a control channel
failure is detected by other means, e.g. LMP?

Michael

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: Wednesday, September 11, 2002 3:14 AM
> To: mmandelberg@fwion.com
> Cc: ccamp
> Subject: RE: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> 
> Hi Michael,
>             thank you for your advice, but IMHO that section 
> postulates
> that refresh messages are in fact used(quoted from the draft)
> 
> "In a sense with respect to established LSPs the node behaves as if it
> continues to
>  receive periodic RSVP refresh messages from the neighbor."
> 
> that as fas as I understood means that refresh messages are 
> sent between
> two neighbouring TNEs.
> 
> My question is: is there a consensus in this WG to eliminate 
> this need, for
> those LSP that are inherently hard state (SDH/SONET, WDM, G.709)?
> 
> Best regards,
>              Diego.
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: diego.caviglia@marconi.com
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> ----------------------------------------------------------------
> Fatti non foste a viver come bruti
> ma per seguir virtute e canoscenza
> 
> Dante Alighieri Inferno Canto XXVI
> 
> 
> 
> "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>@ops.ietf.org on
> 10/09/2002 20.42.32
> 
> Sent by:  owner-ccamp@ops.ietf.org
> 
> 
> To:   ccamp@ops.ietf.org
> cc:
> 
> Subject:  RE: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> This is addressed in the case of a loss of the control 
> channel (section 9
> in
> draft-ietf-mpls-generalized-rsvp-te-08.txt). However, this is in the
> context
> of the RSVP Hello protocol.
> 
> I assume that the same rule applies if relying on LMP for 
> control channel
> management. I think that this should be stated explicitly in 
> the document.
> 
> 
> Michael Mandelberg
> FirstWave Intelligent Optical Networks, Inc.
> 11800 Sunrise Valley Drive, 15th floor
> Reston, Virginia 20191
> (703) 390 - 9401, x 1008
> mmandelberg@fwion.com
> 
> 
> 
> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: Tuesday, September 10, 2002 4:52 AM
> To: ccamp@ops.ietf.org
> Subject: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> Hi all,
>               some time ago there was an argument, on the ML (see
> http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) 
> about whether it
> was feasible to retain the possibilty to set the refresh 
> timer to infinite,
> a proposed alternative was to ignore the elapsing of the 
> refresh timer.
> 
> I feel these capacities are very useful especially in a 
> Transport Network
> enviroment.
> 
> What is the consensus on the possibility to eliminate the 
> need of refresh
> message in G.RSVP-TE?
> 
> Best Regards,
>                              Diego.
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: diego.caviglia@marconi.com
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> ----------------------------------------------------------------
> Fatti non foste a viver come bruti
> ma per seguir virtute e canoscenza
> 
> Dante Alighieri Inferno Canto XXVI
> 
> 
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 05:56:36 -0700
Message-ID: <031e01c25992$55b1ad00$8c56fea9@repligate>
From: "Jim Fleming" <JimFleming@ameritech.net>
To: "Zhi-Wei Lin" <zwlin@lucent.com>, "Soo-Hyun Choi" <soohyunc@etri.re.kr>, <richard.hill@itu.int>
Cc: <sergio.belotti@netit.alcatel.it>, <npl@dataconnection.com>, <Dimitri.Papadimitriou@alcatel.be>, <dpendarakis@tellium.com>, <xuyg@lucent.com>, <ccamp@ops.ietf.org>
Subject: Re: Questions on the i-d status
Date: Wed, 11 Sep 2002 07:54:14 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Zhi-Wei Lin" <zwlin@lucent.com>
> > Is there an apparent liaison with ITU-T?
> 
> This draft was created as a result of liaisons with ITU-T (more
> specifically a result of receiving a liaison from ITU-T on additional
> features of ASON that needs to be added). The content of the draft will
> also be submitted to ITU-T's upcoming October experts meeting targetting
> G.7713.2 (signaling using RSVP-TE)
> 

Will the "Spare" bit be impacted ?

128-bit (AAAA) DNS Flag Day Format

[YMDD]:[16-bits for the outer header]:[IPv4]:[48-bit Persistent Address+Port]

The 16-bits for the outer header are...

1-bit to set the "Spare" bit [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (8, 32, 128, 256) [LL]
1-bit to set No Options Supported [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) field [TTTT]

SDLL.OFFF.FFFF.TTTT

Given an AAAA DNS record, an IPv8 or IPv16 node can then specify,
a Flag Day [YMDD] to start using this particular record, an IPv4 address
for the site's gateway/firewall, 11 bits of extended IPv4++ addressing bits,
plus the spare bit can be controlled, the DF bit, and 4 common TTL values
can be recommended. Finally, the node can mark that it wants to not
support Options on the IPv4 encapsulating header. The node can also of
course include it's 48-bit persistent address and optional 16-bit Port value.

Note, there is only one "Spare" bit, it is not a [src][dst] arrangement.
It can be used to toggle traffic from one net layer to another, and not allow
traffic to flow between those layers. Traffic can be split at each side of the
legacy core IPv4 network, based on that bit.


Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 05:38:48 -0700
Message-ID: <3D7F38FF.8010307@lucent.com>
Date: Wed, 11 Sep 2002 08:37:19 -0400
From: Zhi-Wei Lin <zwlin@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Soo-Hyun Choi <soohyunc@etri.re.kr>
CC: sergio.belotti@netit.alcatel.it, npl@dataconnection.com, Dimitri.Papadimitriou@alcatel.be, dpendarakis@tellium.com, xuyg@lucent.com, ccamp@ops.ietf.org
Subject: Re: Questions on the i-d status
Content-Type: text/plain; charset=x-windows-949
Content-Transfer-Encoding: 7bit

Hello,

> What is the update status for this draft?

We're working on revising the draft to include additional information.
This includes further specifying the CALL_ID format for both operator
specific and globally unique case.

> Will the ccamp wg accept this main idea? (e.g., GMPLS should supports
> call & connection separation and soft permanent connection, and ect.)

This draft is targeted for the specific case of supporting the ASON
capabilities as specified within the ITU-T Recommendations. The base
GMPLS work is not impacted by this.

> Is there an apparent liaison with ITU-T?

This draft was created as a result of liaisons with ITU-T (more
specifically a result of receiving a liaison from ITU-T on additional
features of ASON that needs to be added). The content of the draft will
also be submitted to ITU-T's upcoming October experts meeting targetting
G.7713.2 (signaling using RSVP-TE)

Zhi





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 05:30:21 -0700
Message-ID: <007901c2598e$c4114750$96fdfe81@evergreen>
From: "Soo-Hyun Choi" <soohyunc@etri.re.kr>
To: "Soo-Hyun Choi" <soohyunc@etri.re.kr>, <sergio.belotti@netit.alcatel.it>, <npl@dataconnection.com>, "Zhi-Wei Lin" <zwlin@lucent.com>, <Dimitri.Papadimitriou@alcatel.be>, <dpendarakis@tellium.com>, <xuyg@lucent.com>
Cc: <ccamp@ops.ietf.org>
Subject: Re: Questions on the i-d status
Date: Wed, 11 Sep 2002 21:28:42 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Hi,

I've read
http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-01.txt
draft.

What is the update status for this draft?
Will the ccamp wg accept this main idea? (e.g., GMPLS should supports call &
connection separation and soft permanent connection, and ect.)

Is there an apparent liaison with ITU-T?

Regards,
-------------------------------------------
Soo-Hyun Choi
Network Research Lab.
ETRI (Elec. & Telecom. Research Inst.)

Office: +82.42.860.5607
Fax: +82.42.860.5440
Mobile: +82.11.421.0342
E-mail: soohyunc@etri.re.kr
http://soohyunc.oasis.re.kr/
-------------------------------------------




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 05:06:44 -0700
Message-Id: <200209111201.IAA05126@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Date: Wed, 11 Sep 2002 08:01:26 -0400

--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		: SONET/SDH Encoding for Link Management Protocol (LMP) 
                          Test messages
	Author(s)	: J. Lang, D. Papadimitriou
	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
	Pages		: 15
	Date		: 2002-9-10
	
This document details the Synchronous Optical NETwork 
(SONET)/Synchronous Digital Hierarchy (SDH) technology specific 
information needed when sending Link Management Protocol (LMP) test 
messages

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.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-lmp-test-sonet-sdh-00.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-10153655.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-10153655.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 11 Sep 2002 00:20:43 -0700
Subject: RE: G.RSVP-TE in OTN - Refresh mechanism
To: mmandelberg@fwion.com
Cc: "ccamp" <ccamp@ops.ietf.org>
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Wed, 11 Sep 2002 09:13:38 +0200
Message-ID: <OF22C56AED.6925A2EB-ONC1256C31.00237BBE@uk.marconicomms.com>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

Hi Michael,
            thank you for your advice, but IMHO that section postulates
that refresh messages are in fact used(quoted from the draft)

"In a sense with respect to established LSPs the node behaves as if it
continues to
 receive periodic RSVP refresh messages from the neighbor."

that as fas as I understood means that refresh messages are sent between
two neighbouring TNEs.

My question is: is there a consensus in this WG to eliminate this need, for
those LSP that are inherently hard state (SDH/SONET, WDM, G.709)?

Best regards,
             Diego.








----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: diego.caviglia@marconi.com
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI



"Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>@ops.ietf.org on
10/09/2002 20.42.32

Sent by:  owner-ccamp@ops.ietf.org


To:   ccamp@ops.ietf.org
cc:

Subject:  RE: G.RSVP-TE in OTN - Refresh mechanism


This is addressed in the case of a loss of the control channel (section 9
in
draft-ietf-mpls-generalized-rsvp-te-08.txt). However, this is in the
context
of the RSVP Hello protocol.

I assume that the same rule applies if relying on LMP for control channel
management. I think that this should be stated explicitly in the document.


Michael Mandelberg
FirstWave Intelligent Optical Networks, Inc.
11800 Sunrise Valley Drive, 15th floor
Reston, Virginia 20191
(703) 390 - 9401, x 1008
mmandelberg@fwion.com



-----Original Message-----
From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
Sent: Tuesday, September 10, 2002 4:52 AM
To: ccamp@ops.ietf.org
Subject: G.RSVP-TE in OTN - Refresh mechanism


Hi all,
              some time ago there was an argument, on the ML (see
http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) about whether it
was feasible to retain the possibilty to set the refresh timer to infinite,
a proposed alternative was to ignore the elapsing of the refresh timer.

I feel these capacities are very useful especially in a Transport Network
enviroment.

What is the consensus on the possibility to eliminate the need of refresh
message in G.RSVP-TE?

Best Regards,
                             Diego.






----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: diego.caviglia@marconi.com
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI








Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 10 Sep 2002 23:25:20 -0700
Message-ID: <017201c2595b$14b97670$1bbffe81@evergreen>
From: "Soo-Hyun Choi" <soohyunc@etri.re.kr>
To: <sergio.belotti@netit.alcatel.it>, <npl@dataconnection.com>, "Zhi-Wei Lin" <zwlin@lucent.com>, <Dimitri.Papadimitriou@alcatel.be>, <dpendarakis@tellium.com>, <xuyg@lucent.com>
Cc: <ccamp@ops.ietf.org>
Subject: Questions on the i-d status
Date: Wed, 11 Sep 2002 15:18:44 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01C259A6.84797230"

This is a multi-part message in MIME format.

------=_NextPart_000_016F_01C259A6.84797230
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGksDQoNCkkndmUgcmVhZCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm
dC1saW4tY2NhbXAtZ21wbHMtYXNvbi1yc3ZwdGUtMDEudHh0IGRyYWZ0Lg0KDQpXaGF0IGlzIHRo
ZSB1cGRhdGUgc3RhdHVzIGZvciB0aGlzIGRyYWZ0Pw0KV2lsbCB0aGUgY2NhbXAgd2cgYWNjZXB0
IHRoaXMgbWFpbiBpZGVhPyAoZS5nLiwgR01QTFMgc2hvdWxkIHN1cHBvcnRzIGNhbGwgJiBjb25u
ZWN0aW9uIHNlcGFyYXRpb24gYW5kIHNvZnQgcGVybWFuZW50IGNvbm5lY3Rpb24sIGFuZCBlY3Qu
KQ0KDQpJcyB0aGVyZSBhbiBhcHBhcmVudCBsaWFpc29uIHdpdGggSVRVLVQ/DQoNClJlZ2FyZHMs
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTb28tSHl1biBD
aG9pDQpOZXR3b3JrIFJlc2VhcmNoIExhYi4NCkVUUkkgKEVsZWMuICYgVGVsZWNvbS4gUmVzZWFy
Y2ggSW5zdC4pDQogDQpPZmZpY2U6ICs4Mi40Mi44NjAuNTYwNw0KRmF4OiArODIuNDIuODYwLjU0
NDANCk1vYmlsZTogKzgyLjExLjQyMS4wMzQyDQpFLW1haWw6IHNvb2h5dW5jQGV0cmkucmUua3IN
Cmh0dHA6Ly9zb29oeXVuYy5vYXNpcy5yZS5rci8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCg==

------=_NextPart_000_016F_01C259A6.84797230
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI3MTkuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj5IaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PkkndmUgcmVhZCA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWxpbi1jY2FtcC1nbXBscy1hc29uLXJzdnB0ZS0wMS50eHQiPmh0dHA6Ly93d3cuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpbi1jY2FtcC1nbXBscy1hc29uLXJzdnB0ZS0w
MS50eHQ8L0E+Jm5ic3A7ZHJhZnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1l
cyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj5XaGF0IGlzIHRoZSB1cGRhdGUgc3RhdHVzIGZvciB0aGlzIA0KZHJhZnQ/PC9G
T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldpbGwgdGhlIGNj
YW1wIHdnIGFjY2VwdCB0aGlzIG1haW4gDQppZGVhPyZuYnNwOyhlLmcuLCBHTVBMUyBzaG91bGQg
c3VwcG9ydHMgY2FsbCAmYW1wOyBjb25uZWN0aW9uIHNlcGFyYXRpb24gYW5kIA0Kc29mdCBwZXJt
YW5lbnQgY29ubmVjdGlvbiwgYW5kIGVjdC4pPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj5JcyB0aGVyZSBhbiBhcHBhcmVudCBsaWFpc29uIHdpdGggDQpJVFUt
VD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05U
PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJlZ2FyZHMs
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5Tb28tSHl1biANCkNob2k8
QlI+TmV0d29yayBSZXNlYXJjaCBMYWIuPEJSPkVUUkkgKEVsZWMuICZhbXA7IFRlbGVjb20uIFJl
c2VhcmNoIA0KSW5zdC4pPEJSPiZuYnNwOzxCUj5PZmZpY2U6ICs4Mi40Mi44NjAuNTYwNzxCUj5G
YXg6ICs4Mi40Mi44NjAuNTQ0MDxCUj5Nb2JpbGU6IA0KKzgyLjExLjQyMS4wMzQyPEJSPkUtbWFp
bDogPEEgDQpocmVmPSJtYWlsdG86c29vaHl1bmNAZXRyaS5yZS5rciI+c29vaHl1bmNAZXRyaS5y
ZS5rcjwvQT48QlI+PEEgDQpocmVmPSJodHRwOi8vc29vaHl1bmMub2FzaXMucmUua3IvIj5odHRw
Oi8vc29vaHl1bmMub2FzaXMucmUua3IvPC9BPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_016F_01C259A6.84797230--




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 10 Sep 2002 11:49:27 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE556@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: RE: G.RSVP-TE in OTN - Refresh mechanism
Date: Tue, 10 Sep 2002 14:42:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

This is addressed in the case of a loss of the control channel (section 9 in
draft-ietf-mpls-generalized-rsvp-te-08.txt). However, this is in the context
of the RSVP Hello protocol. 

I assume that the same rule applies if relying on LMP for control channel
management. I think that this should be stated explicitly in the document.


Michael Mandelberg
FirstWave Intelligent Optical Networks, Inc.
11800 Sunrise Valley Drive, 15th floor
Reston, Virginia 20191
(703) 390 - 9401, x 1008
mmandelberg@fwion.com



-----Original Message-----
From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
Sent: Tuesday, September 10, 2002 4:52 AM
To: ccamp@ops.ietf.org
Subject: G.RSVP-TE in OTN - Refresh mechanism


Hi all,
              some time ago there was an argument, on the ML (see
http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) about whether it
was feasible to retain the possibilty to set the refresh timer to infinite,
a proposed alternative was to ignore the elapsing of the refresh timer.

I feel these capacities are very useful especially in a Transport Network
enviroment.

What is the consensus on the possibility to eliminate the need of refresh
message in G.RSVP-TE?

Best Regards,
                             Diego.






----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: diego.caviglia@marconi.com
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 10 Sep 2002 05:46:37 -0700
Subject: Explicit Label Control with Bundled Link
To: ccamp@ops.ietf.org
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Tue, 10 Sep 2002 14:43:24 +0200
Message-ID: <OF01A3A259.34D33BB0-ONC1256C30.0045D037@uk.marconicomms.com>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

How can I associate the explicit labels defined in the ERO with the
Conponent Interface?

I'll try to explain my question better; suppose you want to detail an LSP
up to the Label level (this is foreseen by the Explicit Label Control
procedure) if the LSP  traverses a Bundle Link the Path sender has to
explicitly declare the component interface used in each direction.

I haven't found the objects needed to declare Upstream and Downstream
Component interfaces in the ERO.

Best Regards,
          Diego.







----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: diego.caviglia@marconi.com
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 10 Sep 2002 02:11:24 -0700
Subject: G.RSVP-TE in OTN - Refresh mechanism
To: ccamp@ops.ietf.org
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Tue, 10 Sep 2002 10:52:22 +0200
Message-ID: <OF2675B4C7.EC6DC4CD-ONC1256C30.003099F3@uk.marconicomms.com>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

Hi all,
              some time ago there was an argument, on the ML (see
http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) about whether it
was feasible to retain the possibilty to set the refresh timer to infinite,
a proposed alternative was to ignore the elapsing of the refresh timer.

I feel these capacities are very useful especially in a Transport Network
enviroment.

What is the consensus on the possibility to eliminate the need of refresh
message in G.RSVP-TE?

Best Regards,
                             Diego.






----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: diego.caviglia@marconi.com
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI




Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 09 Sep 2002 09:52:03 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8865836@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: 'gui' <xiaoguiwxd@21cn.com>, ccamp@ops.ietf.org
Subject: RE: TE-link's problem in LMP-0.5
Date: Mon, 9 Sep 2002 09:50:05 -0700 
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"

Gui,

> -----Original Message-----
> From: gui [mailto:xiaoguiwxd@21cn.com]
> Sent: Friday, September 06, 2002 4:40 AM
> To: ccamp@ops.ietf.org
> Subject: TE-link's problem in LMP-0.5
> 
> 
> Hi all,
> 
> I have some questions about TE links.
> 
> in [LMP] [Page 5]:
>    LMP can also tell the signaling module the 
>    mapping between TE links and control channels.
> Does the mapping is 1:1 or n:1?
the mapping can be n:m, n,m>=1.

> 
> The end nodes have the mapping of local/remote Link_Id
> for one TE link. If the TE link goes to state Down, 
> Should that local/remote Link_Id mapping be deleted?
The spec doesn't mandate that the mapping is deleted; however, the
LinkSummary message must be positively Acked (i.e., the mapping must be
validated) before bringing the link back up again.

Thanks,
Jonathan

> 
> Thanks,
> 
>             gui
>             xiaoguiwxd@21cn.com
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 09 Sep 2002 09:31:32 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE53E@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: Vendor-Specific Class-Num availability
Date: Mon, 9 Sep 2002 12:24:38 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I see from draft-ietf-rsvp-iana-00.txt the following:

      The following table shows the behavior and IANA assignment rule
      for each sub-range of the Class Number value:

         0-80        REJECT; assigned by IANA with IETF Consensus.
         81-127      REJECT; assigned by IANA using First-Come-First-Served
         128-159     (Reserved)
         160-191     IGNORE; assigned by IANA with IETF Consensus.
         192-223     FORWARD; assigned by IANA with IETF Consensus.
         224-255     FORWARD; assigned by IANA using First-Come-First-Served

   2.3 Class Type

      Class Type is an 8-bit number that is assigned distinctly for each
      Class Number.

         0           Illegal value
         1-127       Assigned by IANA with IETF Consensus.
         128-191     Assigned by IANA using First-Come-First-Served
         192-255     Private usage.

I'm wondering if any of these values have been assigned for vendor specific
object definitions. It seems that the range 192 - 255 is available for the
Type. What about for the Class? If you are curious, the purpose is to
provide a place to carry end-to-end OIF-UNI data.


Thanks,

> Michael Mandelberg
> FirstWave Intelligent Optical Networks, Inc.
> 11800 Sunrise Valley Drive, 15th floor
> Reston, Virginia 20191
> (703) 390 - 9401, x 1008
> mmandelberg@fwion.com
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 09 Sep 2002 08:53:09 -0700
Message-Id: <200209091551.g89FpKm65407@merlot.juniper.net>
To: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
cc: ccamp@ops.ietf.org
Subject: Re: Repost: Use of Unnumbered Interface ID 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <39328.1031586680.1@juniper.net>
Date: Mon, 09 Sep 2002 08:51:20 -0700
From: Yakov Rekhter <yakov@juniper.net>

Michael,

> draft-ietf-mpls-rsvp-unnum-07.txt states that:
> 
>    With this in mind, the ERO processing in the presence of the
>    Unnumbered Interface ID subobject follows the rules specified in
>    section 4.3.4.1 of [RSVP-TE].
> 
> If the Unnumbered Interface ID subobject is used, is the IPv4 Prefix
> subobject defined in 3209 still required?

The Unnumbered Interface ID subobject is used for unnumbered interfaces,
the IPv4 Prefix subobject is used for numbered interfaces.

Yakov.



Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 09 Sep 2002 08:33:58 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE536@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: Repost: Use of Unnumbered Interface ID
Date: Mon, 9 Sep 2002 11:25:57 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

draft-ietf-mpls-rsvp-unnum-07.txt states that:

   With this in mind, the ERO processing in the presence of the
   Unnumbered Interface ID subobject follows the rules specified in
   section 4.3.4.1 of [RSVP-TE].

If the Unnumbered Interface ID subobject is used, is the IPv4 Prefix
subobject defined in 3209 still required?

Thanks

Michael Mandelberg

FirstWave SION



Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 09 Sep 2002 05:25:11 -0700
Message-Id: <4.3.2.7.2.20020909081502.02901a20@mo-ex1>
Date: Mon, 09 Sep 2002 08:22:29 -0400
To: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
From: Lou Berger <lberger@movaz.com>
Subject: Re: No Upstream Uni-directional LSPs?
Cc: <ccamp@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Michael,

This question periodically resurfaces.  Such support is not technically 
challenging, the question is whether it's useful.

Such support was discussed at the time of merging all the drafts that fed 
into GMPLS.  At the time, it was excluded as no participating provider (or 
vendor, for that matter) believed that it would be used in any operational 
context.  Given this, there was consensus to not add complexity and 
mechanisms that would not actually be used.

Lou

At 11:57 PM 9/4/2002, Michael I Mandelberg(Isaac) wrote:

>It is my impression that GMPLS does not support unidirectional LSPs with
>upstream data flow (at least not RSVP). Is that correct?
>
>Thanks
>
>Michael Mandelberg
>FirstWave SION




Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 08 Sep 2002 18:18:05 -0700
Message-ID: <007401c2579d$c3b2eb80$1bbffe81@evergreen>
From: "Soo-Hyun Choi" <soohyunc@etri.re.kr>
To: <ccamp@ops.ietf.org>
Subject: call and connection separation
Date: Mon, 9 Sep 2002 10:11:01 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C257E9.32EC7930"

This is a multi-part message in MIME format.

------=_NextPart_000_0071_01C257E9.32EC7930
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

aGksIGFsbCwNCg0Kd2UndmUgd2l0bmVzc2VkIHRoYXQgdGhlIGNhbGwgYW5kIGNvbm5lY3Rpb24g
c2VwYXJhdGlvbiBjb25jZXB0IGhhcyBiZWVuIHdpZGVseSBhY2NlcHRlZCBpbiBjY2FtcCB3Zy4N
CnRoZW4sIHdpdGggcmVzcGVjdCB0byB0aGUgcmVhbCB3b3JsZCBwcm9ibGVtLCB3aGF0IGlzIHRo
ZSBhY3R1YWwgZXhhbXBsZSAoZS5nLiwgYXBwYXJlbnQgcHJvZHVjdCkgdGhhdCBjYW4gZXhwbGlj
aXRseSBhZGRyZXNzIHRoZSBjYWxsIGFuZCBjb25uZWN0aW9uIHNlcGFyYXRpb24uDQoNCg0KcmVn
YXJkcywNCnNvby1oeXVuIGNob2kNCg==

------=_NextPart_000_0071_01C257E9.32EC7930
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI3MTkuMjIwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj5oaSwgYWxsLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS
b21hbiI+d2UndmUgd2l0bmVzc2VkIHRoYXQgdGhlIGNhbGwgYW5kIGNvbm5lY3Rpb24gDQpzZXBh
cmF0aW9uIGNvbmNlcHQgaGFzIGJlZW4gd2lkZWx5IGFjY2VwdGVkIGluIGNjYW1wIHdnLjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj50aGVuLCB3aXRoIHJl
c3BlY3QgdG8gdGhlIHJlYWwgd29ybGQgcHJvYmxlbSwgDQp3aGF0IGlzIHRoZSBhY3R1YWwgZXhh
bXBsZSAoZS5nLiwmbmJzcDthcHBhcmVudCBwcm9kdWN0KSB0aGF0IGNhbiBleHBsaWNpdGx5IA0K
YWRkcmVzcyB0aGUgY2FsbCBhbmQgY29ubmVjdGlvbiBzZXBhcmF0aW9uLjwvRk9OVD48L0RJVj4N
CjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8
RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnNvby1oeXVuIGNob2k8L0ZPTlQ+PC9ESVY+
PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0071_01C257E9.32EC7930--




Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 06 Sep 2002 11:24:10 -0700
From: "Alexa Morris" <amorris@mplsforum.org>
To: <ccamp@ops.ietf.org>
Subject: Invitation to Participate in a MPLS Forum Sponsored GMPLS Demo at NGN
Date: Fri, 6 Sep 2002 11:21:00 -0700
Message-ID: <000301c255d2$279ae170$9100a8c0@Alexa>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C25597.7B3F16B0"

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C25597.7B3F16B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greetings,
 
This is to inform everyone that the MPLS Forum is facilitating the
world's first public GMPLS interoperability event at NGN 2002, Oct
13-16, in Boston, MA. The MPLS Forum has secured a special booth from
the organizers of NGN 2002.
 
I'd also like to take this opportunity to invite interested companies to
participate at this test event, if they have not signed up already.
 
Planning for this event has been going on for some time and the test
plans are finalized.  
 
Participation Criteria:
 
All participants must have paid the MPLS Forum's membership dues, even
if they do not choose to become members.  The membership fee will be
prorated for the half year. 
 
Participants must also sign a Non Disclosure Agreement and Demo
Contract.  For more information on any of the above, please feel free to
contact me at amorris@mplsforum.org or +1.510.608.5914. 
 
Participation Fees:
 
Prior to the event, there will be a hot staging done in the week of
September 30th for 5 working days. The pre-staging test event will be
held in the University of New Hampshire's Interoperability Laboratory. 
 
The MPLS Forum has made a deliberate effort to keep the fees at a
manageable level.  Companies will pay a total of $5,000 to participate
in the demo. $3,000 of this will go directly to the University of New
Hampshire to cover costs of the hot staging event; the remaining $2,000
will be paid to the MPLS Forum and will cover other organizational costs
involved. 
 
There is very limited space at the NGN 2002 host hotel and hence the
number of participating companies will be limited to a maximum of 12
(while the minimum number will be 8). While the spaces have been filling
up, companies are encouraged to enquire if they are interested in
participating at the event. Please contact Debbie Hetland, Event
Coordinator at the MPLS Forum at +1.510.608.5907 for further details.
She can also be reached by e-mail at dhetland@mplsforum.org.
 
Regards,
 
Alexa Morris
MPLS Forum Executive Director
 
 
 
Alexa Morris / Executive Director / MPLS Forum
39355 California Street/ Suite 307/ Fremont, CA  94538
Phone +1.510.608.5914 / Fax +1.510.608.5917 / Mobile +1.510.468.6514
 URL: http://www.mplsforum.org
 
Managed by Association Management Solutions (AMS);
Forum Management, Meeting and Event Planning
Website: http://www.amsl.com
 

------=_NextPart_000_0004_01C25597.7B3F16B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C25597.7994C210">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'>Greetings,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is to inform everyone that the MPLS Forum is
facilitating the world's first public GMPLS interoperability event at =
NGN 2002,
Oct 13-16, in </span></font><st1:place><st1:City><font =
face=3DArial><span
  style=3D'font-family:Arial'>Boston</span></font></st1:City><font =
face=3DArial><span
 style=3D'font-family:Arial'>, </span></font><st1:State><font =
face=3DArial><span
  =
style=3D'font-family:Arial'>MA</span></font></st1:State></st1:place><font=

face=3DArial><span style=3D'font-family:Arial'>.</span></font><font =
face=3DArial><span
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'> The MPLS =
Forum
has secured a special booth from the organizers of NGN =
2002.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I'd also like to take this opportunity to invite =
interested
companies to participate at this test event, if they have not signed up
already.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>Planning for this =
event
has been going on for some time and the test plans are finalized.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;mso-bidi-font-family:
"Courier =
New";font-weight:bold;mso-bidi-font-weight:normal'>Participation
Criteria:<o:p></o:p></span></font></b></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>All participants =
must
have paid the MPLS Forum's membership dues, even if they do not choose =
to
become members.<span style=3D'mso-spacerun:yes'>&nbsp; </span>The =
membership fee
will be prorated for the half year. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>Participants must =
also
sign a Non Disclosure Agreement and Demo Contract.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>For more information on any of =
the
above, please feel free to contact me at <a =
href=3D"mailto:amorris@mplsforum.org">amorris@mplsforum.org</a>
or +1.510.608.5914. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><b style=3D'mso-bidi-font-weight:normal'><font =
size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;mso-bidi-font-family:
"Courier =
New";font-weight:bold;mso-bidi-font-weight:normal'>Participation =
Fees:<o:p></o:p></span></font></b></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>Prior to the =
event, there
will be a hot staging done in the week of September 30th for 5 working =
days.
The pre-staging test event will be held in the =
</span></font><st1:place><st1:PlaceType><font
  face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier =
New"'>University</span></font></st1:PlaceType><font
 face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'>
 of </span></font><st1:PlaceName><font face=3DArial><span =
style=3D'font-family:
  Arial;mso-bidi-font-family:"Courier New"'>New =
Hampshire</span></font></st1:PlaceName></st1:place><font
face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'>'s
Interoperability Laboratory. <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>The MPLS Forum has =
made a
deliberate effort to keep the fees at a manageable level.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Companies will pay a total of =
$5,000 to
participate in the demo. $3,000 of this will go directly to the =
</span></font><st1:place><st1:PlaceType><font
  face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier =
New"'>University</span></font></st1:PlaceType><font
 face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'>
 of </span></font><st1:PlaceName><font face=3DArial><span =
style=3D'font-family:
  Arial;mso-bidi-font-family:"Courier New"'>New =
Hampshire</span></font></st1:PlaceName></st1:place><font
face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'>
to cover costs of the hot staging event; the remaining $2,000 will be =
paid to
the MPLS Forum and will cover other organizational costs involved. =
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>There is very =
limited
space at the NGN 2002 host hotel and hence the number of participating
companies will be limited to a maximum of 12 (while the minimum number =
will be
8). While the spaces have been filling up, companies are encouraged to =
enquire
if they are interested in participating at the event. Please contact =
</span></font><st1:PersonName><font
 face=3DArial><span =
style=3D'font-family:Arial;mso-bidi-font-family:"Courier New"'>Debbie
 Hetland</span></font></st1:PersonName><font face=3DArial><span =
style=3D'font-family:
Arial;mso-bidi-font-family:"Courier New"'>, Event Coordinator at the =
MPLS Forum
at +1.510.608.5907 for further details. She can also be reached by =
e-mail at <a
href=3D"mailto:dhetland@mplsforum.org">dhetland@mplsforum.org</a>.<o:p></=
o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>Alexa =
Morris<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-bidi-font-family:"Courier New"'>MPLS Forum =
Executive
Director<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'tab-stops:1.0in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-bottom:solid windowtext =
1.0pt;mso-border-bottom-alt:
solid windowtext .5pt;padding:0in 0in 1.0pt 0in'>

<p class=3DMsoNormal style=3D'border:none;mso-border-bottom-alt:solid =
windowtext .5pt;
padding:0in;mso-padding-alt:0in 0in 1.0pt 0in'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;mso-no-proof:yes'><o:p>&nbsp;=
</o:p></span></font></p>

</div>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>Alexa Morris / Executive =
Director /
MPLS Forum</span></font></i></em><font face=3DArial><span =
style=3D'font-family:
Arial;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>39355 California Street/ =
Suite 307/
Fremont, CA<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>94538</span></font></i></em><font
face=3DArial><span =
style=3D'font-family:Arial;mso-no-proof:yes'><o:p></o:p></span></font></p=
>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>Phone +1.510.608.5914 / Fax
+1.510.608.5917 / =
</span></font></i></em><st1:City><st1:place><em><i><font
  face=3DArial><span =
style=3D'font-family:Arial;mso-no-proof:yes'>Mobile</span></font></i></em=
></st1:place></st1:City><em><i><font
face=3DArial><span style=3D'font-family:Arial;mso-no-proof:yes'> =
+1.510.468.6514</span></font></i></em><font
face=3DArial><span =
style=3D'font-family:Arial;mso-no-proof:yes'><o:p></o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>&nbsp;<em><i><font =
face=3DArial><span
style=3D'font-family:Arial'>URL: <a =
href=3D"http://www.mplsforum.org">http://www.mplsforum.org</a></span></fo=
nt></i></em><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>Managed by Association =
Management
Solutions (AMS);</span></font></i></em><em><i><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p></o:p></span></font></i></em></p>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>Forum Management, Meeting and =
Event
Planning<o:p></o:p></span></font></i></em></p>

<p class=3DMsoPlainText><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;mso-no-proof:yes'>Website: <a
href=3D"http://www.amsl.com">http://www.amsl.com</a></span></font></i></e=
m><em><i><font
face=3DArial><span =
style=3D'font-family:Arial'><o:p></o:p></span></font></i></em></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C25597.7B3F16B0--





Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 06 Sep 2002 06:05:26 -0700
Date: Fri, 6 Sep 2002 21:9:31 +0800
From: gui <xiaoguiwxd@21cn.com>
To: ccamp@ops.ietf.org <ccamp@ops.ietf.org>
Subject: Re: TE-link's problem in LMP-0.5
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Message-ID: <IY979093789763.02055@send3.inner-21cn.com>

It is
draft-ietf-ccamp-lmp-05.txt

2002-09-06 19:39:00 
>Hi all,
>
>I have some questions about TE links.
>
>in [LMP] [Page 5]:
>   LMP can also tell the signaling module the 
>   mapping between TE links and control channels.
>Does the mapping is 1:1 or n:1?
>
>The end nodes have the mapping of local/remote Link_Id
>for one TE link. If the TE link goes to state Down, 
>Should that local/remote Link_Id mapping be deleted?
>
>Thanks,
>
>            gui
>            xiaoguiwxd@21cn.com
>
>
>
>.

                    =D6=C2
=C0=F1=A3=A1

            gui
            xiaoguiwxd@21cn.com





Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 06 Sep 2002 05:27:55 -0700
Message-Id: <5.0.2.7.2.20020906195253.00d341f0@img.m.ecl.ntt.co.jp>
Date: Fri, 06 Sep 2002 21:24:09 +0900
To: ccamp@ops.ietf.org
From: MATSUURA Nobuaki <matsuura.nobuaki@lab.ntt.co.jp>
Subject: RE: No Upstream Uni-directional LSPs?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

ERO label subobjects will be one with the U-bit set and one NULL label
without the U-bit set. I think ERO label subobjects are not mandatory though. 
By the way, if the last hop subobject in an ERO is followed by
label subobjects, are the label subobjects used for "LSP splicing"?
Also I should try to improve the description around hierarchical LSP
considerations including the deletion process.

Thanks,
 -Nobuaki

At 02/09/06 03:32, Michael I Mandelberg(Isaac) wrote:
>I have given a brief look at this draft. I think the ideas are interesting,
>but more work needs to be done to make it compatible with current rsvp-te
>work. One thing that is missing is a modification to the ERO object. The
>current draft mandates that there is either two label subobjects, one with
>the U-bit set, or else only one, without the U-bit set.
>
>Michael Mandelberg
>FirstWave SION
>
>-----Original Message-----
>From: Dimitri.Papadimitriou@alcatel.be
>[mailto:Dimitri.Papadimitriou@alcatel.be]
>Sent: Thursday, September 05, 2002 8:22 AM
>To: MATSUURA Nobuaki
>Cc: Michael I Mandelberg(Isaac); ccamp@ops.ietf.org
>Subject: Re: No Upstream Uni-directional LSPs?
>
>
>hi,
>
>from the i-d perspective most of the content deals with
>setup, it would also be good if some words concerning
>the deletion can be proposed (i mean the reference to 
>the method described in current gmpls signalling i-d)
>and also to clarify the following paragraph wrt to the 
>signalling procedure:
>"If a new FA-LSP is required to be set up between the 
>LSR and the other edge of the region, the LSR initiates 
>the setup of a new reserve-directional FA-LSP. At the 
>same time, the LSR may send the Path/Request message 
>for the original reverse-directional LSP to the other 
>edge of the region."
>
>another point is as follows: we have implementations
>ongoing within our community for the set of features that
>are described in the common control gmpls signalling i-d's
>-> therefore it would be of great interest to gather more
>information on deployment/utilisation (ie experimental
>i-ds) in the near future in order to be capable to assess 
>what might be further considered from that persceptive 
>for these i-d's - i think this may also be applied to 
>other items that may come out in the same register -
>
>thanks,
>- dimitri.
>
>MATSUURA Nobuaki wrote:
>> 
>> Hi Michael,
>> 
>> Current GMPLS specifications don't support the upstream unidirectional
>LSP.
>> But MPLS in principle doesn't restrict the direction of an LSP setup.
>> Therefore I think it is a reasonable generalization and posted an I-D for
>this matter.
>> 
>> Please refer,
>> http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt
>> 
>> (I'm going to revise this draft considering the discussion on the list.)
>> 
>> Regards,
>> 
>>  -Nobuaki
>> 
>> At 02/09/05 12:57, Michael I Mandelberg(Isaac) wrote:
>> >It is my impression that GMPLS does not support unidirectional LSPs with
>> >upstream data flow (at least not RSVP). Is that correct?
>> >
>> >Thanks
>> >
>> >Michael Mandelberg
>> >FirstWave SION
>
>-- 
>Papadimitriou Dimitri 
>E-mail : dimitri.papadimitriou@alcatel.be 
>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>E-mail : dpapadimitriou@psg.com
>Public : http://psg.com/~dpapadimitriou/
>Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
>         B-2018 Antwerpen, Belgium
>Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 06 Sep 2002 04:38:05 -0700
Date: Fri, 6 Sep 2002 19:39:51 +0800
From: gui <xiaoguiwxd@21cn.com>
To: ccamp@ops.ietf.org <ccamp@ops.ietf.org>
Subject: TE-link's problem in LMP-0.5
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-ID: <Ce979093806745.22451@send4.inner-21cn.com>

Hi all,

I have some questions about TE links.

in [LMP] [Page 5]:
   LMP can also tell the signaling module the 
   mapping between TE links and control channels.
Does the mapping is 1:1 or n:1?

The end nodes have the mapping of local/remote Link_Id
for one TE link. If the TE link goes to state Down, 
Should that local/remote Link_Id mapping be deleted?

Thanks,

            gui
            xiaoguiwxd@21cn.com





Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 05 Sep 2002 11:39:55 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE509@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: RE: No Upstream Uni-directional LSPs?
Date: Thu, 5 Sep 2002 14:32:43 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I have given a brief look at this draft. I think the ideas are interesting,
but more work needs to be done to make it compatible with current rsvp-te
work. One thing that is missing is a modification to the ERO object. The
current draft mandates that there is either two label subobjects, one with
the U-bit set, or else only one, without the U-bit set.

Michael Mandelberg
FirstWave SION

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, September 05, 2002 8:22 AM
To: MATSUURA Nobuaki
Cc: Michael I Mandelberg(Isaac); ccamp@ops.ietf.org
Subject: Re: No Upstream Uni-directional LSPs?


hi,

from the i-d perspective most of the content deals with
setup, it would also be good if some words concerning
the deletion can be proposed (i mean the reference to 
the method described in current gmpls signalling i-d)
and also to clarify the following paragraph wrt to the 
signalling procedure:
"If a new FA-LSP is required to be set up between the 
LSR and the other edge of the region, the LSR initiates 
the setup of a new reserve-directional FA-LSP. At the 
same time, the LSR may send the Path/Request message 
for the original reverse-directional LSP to the other 
edge of the region."

another point is as follows: we have implementations
ongoing within our community for the set of features that
are described in the common control gmpls signalling i-d's
-> therefore it would be of great interest to gather more
information on deployment/utilisation (ie experimental
i-ds) in the near future in order to be capable to assess 
what might be further considered from that persceptive 
for these i-d's - i think this may also be applied to 
other items that may come out in the same register -

thanks,
- dimitri.

MATSUURA Nobuaki wrote:
> 
> Hi Michael,
> 
> Current GMPLS specifications don't support the upstream unidirectional
LSP.
> But MPLS in principle doesn't restrict the direction of an LSP setup.
> Therefore I think it is a reasonable generalization and posted an I-D for
this matter.
> 
> Please refer,
> http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt
> 
> (I'm going to revise this draft considering the discussion on the list.)
> 
> Regards,
> 
>  -Nobuaki
> 
> At 02/09/05 12:57, Michael I Mandelberg(Isaac) wrote:
> >It is my impression that GMPLS does not support unidirectional LSPs with
> >upstream data flow (at least not RSVP). Is that correct?
> >
> >Thanks
> >
> >Michael Mandelberg
> >FirstWave SION

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 05 Sep 2002 10:00:18 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8865825@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'jonathan.sadler@tellabs.com'" <jonathan.sadler@tellabs.com>,  Dimitri.Papadimitriou@alcatel.be
Cc: Carmine Daloia <daloia@lucent.com>, Nik Langrind <nik@equipecom.com>,  "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Thu, 5 Sep 2002 09:53:53 -0700 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Jonathan,

<snip>
> 
> I am aware of
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-00.txt
> doing something similar to what G.7714 states, but unfortuantely no
> information has been provided on how to distinguish between the
> bootstrap and test messages when transported over certain bearers (ie.
> J0).
> 
> Please provide insight.
>
Thanks for pointing this out.  We've updated the text to address the
Test/Bootstrap message ambiguity in the special case where normal LMP
Test/Bootstrap messages can't be used due to byte limitations.

The new text for the 0x01 J0-16 Test message reads:

  "The Test message (i.e., the string inserted into the frame) is a 15-byte
message, where the 7 most significant bits (msb) of each byte are usable.
Due to the byte limitation, the LMP Header is not included.

  The first usable 4 bits are reserved.  These bits MUST be sent as zero and
ignored on receipt.  The next usable 2 bits are used to identify the message
type.  For the Test message, this value is 0.  The next usable bit is used
to determine the address type of the Interface_Id.  For IPv4, this value is
0.  For unnumbered, this value is 1.  The next usable 32 bits MUST be the
Interface_Id.  The next usable 32 bits MUST be the Verify_Id that was
received in the VERIFY_ID object of the BeginVerifyAck message.  The
remaining bits are reserved and should be sent as zero and ignored on
receipt.

  Note that this Test Message format is only valid when the Interface_Id is
either IPv4 or unnumbered."

The Bootstrap message has also been updated and will be identified will a
value of 1.			

Thanks,
Jonathan

> Jonathan Sadler
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> > 
> > hi,
> > 
> > imho i think it would be good if people discussing specific
> > i-ds on this mailing list could point out to the section of
> > the document providing the feature they speak about (or the
> > sections that does not contain it and that should ideally
> > do) but at least be more accurate about a specific item under
> > discussion (now that a terminology section has been delivered
> > in the last revision of the lmp i-d following this terminology
> > may help in achieving progress - but also clear understanding
> > of the mail discussions - by the ccamp community)
> > 
> > but let's take an example from the below e-mail:
> > 
> > > So basically LMP is used to verify that the datalink id 
> mappings stored
> > > in the neighboring nodes match eachother.
> > 
> > see Section 5 of
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt
> > 
> > in brief these mappings are "discovered" (link verification is
> > much more than just a consistency check mechanism)
> > 
> > > This type of capability would make more sense to be part 
> of the protocol
> > > that provided autodiscovery (i.e., discovered the 
> datalink id mappings).
> > 
> > thus the response to this question becomes clear (i think) and in
> > addition a proposal has been made to bootstrap out-of-band control
> > channels and discover the interface_id mappings (or associations)
> > before establishing a control channel see:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-00.txt
> > 
> > > In my opinion, it is the ability to autodiscover the id 
> mappings that is
> > > more useful than just verifying at a later time if the 
> mappings still match.
> > 
> > well from the structure of the BeginVerify/BeginVerifyAck Message
> > as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we
> > also see that the REMOTE_LINK_ID is an optional object such that
> > both features listed here above are supported
> > 
> > the Test message sent in-band being defined as in Section 12.5.6
> > consistency is also provided by this protocol
> > 
> > > Since LMP doesn't support autodiscovery, it doesn't seem 
> to be useful
> > > for LMP to check whether the mappings match or not.  This 
> check can be
> > > done via the autodiscovery protocol itself.
> > 
> > from the above discussion i think that LMP supports what you call
> > "auto-discovery" and (if the previous statement is true) we may
> > ask ourself to which protocol do you refer here and what's the
> > relevance of the content of this statement ?
> > 
> > thanks,
> > - dimitri.
> > 
> > Carmine Daloia wrote:
> > >
> > > Nik,
> > >
> > > Thanks for the clarification.
> > >
> > > So basically LMP is used to verify that the datalink id 
> mappings stored
> > > in the neighboring nodes match eachother.
> > >
> > > This type of capability would make more sense to be part 
> of the protocol
> > > that provided autodiscovery (i.e., discovered the 
> datalink id mappings).
> > >  After autodiscovery completes and the id mappings are stored, the
> > > protocol can subsequently verify whether the mappings 
> stored in the
> > > neighboring nodes match eachother.
> > >
> > > In my opinion, it is the ability to autodiscover the id 
> mappings that is
> > > more useful than just verifying at a later time if the 
> mappings still match.
> > >
> > > Since LMP doesn't support autodiscovery, it doesn't seem 
> to be useful
> > > for LMP to check whether the mappings match or not.  This 
> check can be
> > > done via the autodiscovery protocol itself.
> > >
> > > Carmine
> > >
> > > Nik Langrind wrote:
> > >
> > > >Carmine,
> > > >
> > > >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> > > >
> > > >As I understand it, the reason is to allow two systems 
> to exchange
> > > >identifiers of their mutual TE links and the component 
> datalinks of those TE
> > > >links.
> > > >
> > > >Nik
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Carmine Daloia [mailto:daloia@lucent.com]
> > > >>Sent: Tuesday, September 03, 2002 11:55 AM
> > > >>To: Nik Langrind
> > > >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> > > >>Subject: Re: Summary of LMP implementation/deployment reports
> > > >>
> > > >>
> > > >>Nik,
> > > >>
> > > >>What is meant by auto-configure?
> > > >>
> > > >>Thanks
> > > >>Carmine
> > > >>
> > > >>Nik Langrind wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi Zhi,
> > > >>>
> > > >>>I don't think that gaps in SONET/SDH fault management are
> > > >>>
> > > >>>
> > > >>the reason for
> > > >>
> > > >>
> > > >>>implementing LMP on SONET/SDH systems. As I understand it,
> > > >>>
> > > >>>
> > > >>the reason is to
> > > >>
> > > >>
> > > >>>allow two systems to auto-configure the component datalinks
> > > >>>
> > > >>>
> > > >>of their mutual
> > > >>
> > > >>
> > > >>>TE link.
> > > >>>
> > > >>>Nik
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>-----Original Message-----
> > > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > > >>>>Sent: Thursday, August 29, 2002 10:55 AM
> > > >>>>To: Wijnen, Bert (Bert)
> > > >>>>Cc: Ccamp-wg (E-mail)
> > > >>>>Subject: Re: Summary of LMP implementation/deployment reports
> > > >>>>
> > > >>>>
> > > >>>>Hi Bert,
> > > >>>>
> > > >>>>This is really illuminating. We've been discussing LMP and
> > > >>>>scope of LMP,
> > > >>>>and from what I gather (maybe I've misinterpreted or
> > > >>>>misunderstood what
> > > >>>>people say) was that LMP was supposed to be targetting pre-OTN
> > > >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> > > >>>>has quite a
> > > >>>>set of OAM capabilities that were much better (or at 
> very least
> > > >>>>comparable) to LMP (and they've been around more many 
> many years)...
> > > >>>>
> > > >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> > > >>>>what are
> > > >>>>the gaps they see in existing SONET/SDH fault management (as
> > > >>>>defined in
> > > >>>>G.783) that LMP is supposed to fill?
> > > >>>>
> > > >>>>Thanks for any additional insights.
> > > >>>>
> > > >>>>Zhi
> > > >>>>
> > > >>>>
> > > >>>>Wijnen, Bert (Bert) wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Here is the summary of the reports I have received.
> > > >>>>>
> > > >>>>>The questions to be answered were:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>Type: vendor/carrier
> > > >>>>>>Company: (to weed out duplicates)
> > > >>>>>>Interest level in LMP:
> > > >>>>>>  For vendors:  
> opposed/yawn/interested/implementing/released
> > > >>>>>>  For carriers: 
> useless/yawn/useful/testing/deploying/deployed
> > > >>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Type:                Equipment   TestEquip or   
> Carrier    ISP
> > > >>>>>                   Vendor      SourceVendor
> > > >>>>>
> > > >>>>>Responses:              10            2            2        1
> > > >>>>>
> > > >>>>>Interest level:
> > > >>>>>Released               2            2
> > > >>>>>Implementing           6
> > > >>>>>yawn                   1                                  1
> > > >>>>>testing                                          2
> > > >>>>>(very)usefull                                    1
> > > >>>>>
> > > >>>>>Technologies (not split by type)
> > > >>>>>SONET - SONET/SDH      10
> > > >>>>>Ethernet GigE           5
> > > >>>>>ATM                     2
> > > >>>>>MPLS                    1
> > > >>>>>PXC                     1
> > > >>>>>(D)WDM                  2
> > > >>>>>Fiber                   1
> > > >>>>>Transparent             1
> > > >>>>>Sonet DCC               1
> > > >>>>>POS                     1
> > > >>>>>OTN                     1
> > > >>>>>Lambda                  1
> > > >>>>>Port Switching          1
> > > >>>>>
> > > >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> > > >>>>>One implementation was O-UNI version of LMP, so does not do
> > > >>>>>all the things described in current LMP draft.
> > > >>>>>
> > > >>>>>All in all quite a set if "implementations underway".
> > > >>>>>
> > > >>>>>Would have been good to see some more responses from
> > > >>>>>
> > > >>>>>
> > > >>Carriers or ISPs
> > > >>
> > > >>
> > > >>>>>Feel free to send your continued responses and I 
> will try to keep
> > > >>>>>the list up to date.
> > > >>>>>
> > > >>>>>Bert
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 05 Sep 2002 05:25:42 -0700
Message-ID: <3D774C56.D85360C7@alcatel.be>
Date: Thu, 05 Sep 2002 14:21:42 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: MATSUURA Nobuaki <matsuura.nobuaki@lab.ntt.co.jp>
Cc: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>, ccamp@ops.ietf.org
Subject: Re: No Upstream Uni-directional LSPs?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

hi,

from the i-d perspective most of the content deals with
setup, it would also be good if some words concerning
the deletion can be proposed (i mean the reference to 
the method described in current gmpls signalling i-d)
and also to clarify the following paragraph wrt to the 
signalling procedure:
"If a new FA-LSP is required to be set up between the 
LSR and the other edge of the region, the LSR initiates 
the setup of a new reserve-directional FA-LSP. At the 
same time, the LSR may send the Path/Request message 
for the original reverse-directional LSP to the other 
edge of the region."

another point is as follows: we have implementations
ongoing within our community for the set of features that
are described in the common control gmpls signalling i-d's
-> therefore it would be of great interest to gather more
information on deployment/utilisation (ie experimental
i-ds) in the near future in order to be capable to assess 
what might be further considered from that persceptive 
for these i-d's - i think this may also be applied to 
other items that may come out in the same register -

thanks,
- dimitri.

MATSUURA Nobuaki wrote:
> 
> Hi Michael,
> 
> Current GMPLS specifications don't support the upstream unidirectional LSP.
> But MPLS in principle doesn't restrict the direction of an LSP setup.
> Therefore I think it is a reasonable generalization and posted an I-D for this matter.
> 
> Please refer,
> http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt
> 
> (I'm going to revise this draft considering the discussion on the list.)
> 
> Regards,
> 
>  -Nobuaki
> 
> At 02/09/05 12:57, Michael I Mandelberg(Isaac) wrote:
> >It is my impression that GMPLS does not support unidirectional LSPs with
> >upstream data flow (at least not RSVP). Is that correct?
> >
> >Thanks
> >
> >Michael Mandelberg
> >FirstWave SION

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 23:03:25 -0700
Message-Id: <5.0.2.7.2.20020905143710.045a7848@img.m.ecl.ntt.co.jp>
Date: Thu, 05 Sep 2002 14:58:48 +0900
To: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
From: MATSUURA Nobuaki <matsuura.nobuaki@lab.ntt.co.jp>
Subject: Re: No Upstream Uni-directional LSPs?
Cc: ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi Michael,

Current GMPLS specifications don't support the upstream unidirectional LSP.
But MPLS in principle doesn't restrict the direction of an LSP setup.
Therefore I think it is a reasonable generalization and posted an I-D for this matter.

Please refer,
http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt

(I'm going to revise this draft considering the discussion on the list.)

Regards,

 -Nobuaki


At 02/09/05 12:57, Michael I Mandelberg(Isaac) wrote:
>It is my impression that GMPLS does not support unidirectional LSPs with
>upstream data flow (at least not RSVP). Is that correct?
>
>Thanks
>
>Michael Mandelberg
>FirstWave SION



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 21:26:19 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE501@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: Use of Unnumbered Interface ID
Date: Thu, 5 Sep 2002 00:19:15 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

draft-ietf-mpls-rsvp-unnum-07.txt states that:

   With this in mind, the ERO processing in the presence of the
   Unnumbered Interface ID subobject follows the rules specified in
   section 4.3.4.1 of [RSVP-TE].

If the Unnumbered Interface ID subobject is used, is the IPv4 Prefix
subobject defined in 3209 still required?

Thanks

Michael Mandelberg

FirstWave SION



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 21:07:17 -0700
Message-ID: <A65124DA4C87D51180B100D0B7C9EB593FE500@mailsrv03>
From: "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>
To: ccamp@ops.ietf.org
Subject: No Upstream Uni-directional LSPs?
Date: Wed, 4 Sep 2002 23:57:27 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

It is my impression that GMPLS does not support unidirectional LSPs with
upstream data flow (at least not RSVP). Is that correct?

Thanks

Michael Mandelberg
FirstWave SION



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 13:34:11 -0700
Message-ID: <20020904131524.A20600@sprint.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Date: Wed, 4 Sep 2002 13:15:24 -0700
From: David Meyer <dmm@sprint.net>
To: Ron Bonica <Ronald.P.Bonica@wcom.com>
Cc: Tom Scott <telecomtom@vedatel.com>, ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt

Ron beat me to it. Thanks Ron.

Dave

On Wed, Sep 04, 2002 at 02:20:08PM -0400, Ron Bonica wrote:
>> Tom,
>> 
>> Measurement of one way delay and jitter are beyond the scope of this
>> document. Although one-way delay and jitter are very interesting metrics,
>> obtaining them is a non-trivial matter.
>> 
>> /speaking as individual contributor/
>> 
>>                                         Ron
>> 
>> 
>> > -----Original Message-----
>> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
>> > Behalf Of Tom Scott
>> > Sent: Wednesday, September 04, 2002 9:38 AM
>> > To: ccamp@ops.ietf.org
>> > Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
>> >
>> >
>> > [ post by non-subscriber.  with the massive amount of spam, it is easy to
>> >   miss and therefore delete mis-posts.  so fix subscription addresses! ]
>> >
>> > The draft addresses spatial tracing.
>> >
>> > Is there also interest in time? The only reference to temporal
>> > tracing is in
>> > section 6 item 5: "include tunnel components and round trip delay
>> > across each
>> > component". In this draft or possibly another it might be
>> > valuable to extend the
>> > granularity of the discussion to:
>> >
>> > * time: delay and jitter from one node to another.
>> >
>> > * space: what are the nodes? Reference to GMPLS in the draft indicate
>> >    that L1/L2 transport nodes are of interest.
>> >
>> > * space and time: within nodes, such as routers, would you extend the
>> >    spatial and temporal tracing to interfaces? to other logical /
>> > functional
>> >    components such as the "datapath elements" referenced in RFC 3290/89?
>> >    Timing in transport equipment at the sub-IP area and in
>> > datapath components
>> >    of those nodes?
>> >
>> > It's valuable to know not only where traffic goes but also the
>> > time it takes to
>> > get there, on all layers of the path, in equipment on each of
>> > those layers, and
>> > in functional components within those nodes. But these issues
>> > don't have to be
>> > covered in this draft. They might be addressed elsewhere by
>> > individuals whose
>> > daily work depends on multivendor multiprovider QoS tracing.
>> >
>> > -- TT
>> >
>> >
>> >
>> >
>> 





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 13:24:29 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Tom Scott <telecomtom@vedatel.com>
Cc: ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
Message-Id: <E17mgcE-0005sD-00@roam.psg.com>
Date: Wed, 04 Sep 2002 13:19:06 -0700

> * time: delay and jitter from one node to another.

you may find the work of the ippm wg useful

randy




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 13:09:15 -0700
Message-ID: <Pine.GSO.4.10.10209041345001.22392-100000@calipso.dt.fee.unicamp.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Date: Wed, 4 Sep 2002 13:53:29 -0300 (EST)
From: Marcos Antonio De Almeida Cora <cora@dt.fee.unicamp.br>
To: mpls@UU.NET, gmpls-ops@mplsrc.com, ccamp@ops.ietf.org
Subject: Doubt on OBGP

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

 Hi all, 

 My name is Marcos, I'm MSc Student of School of
Electrical and Computer Engineering (http://www.fee.unicamp.br) of State
University of Campinas (http://www.unicamp.br), Brazil.

 I have a doubt on OBGP. I'd like to know if GMPLS support OBGP as a
signaling protocol or only CR-LDP and RSVP-TE is used ???

 If yes, where can I find informations about it.

 Thanks, 

        Marcos

_________________________________________________________________

  Marcos Ant��nio de Almeida Cor��    
  School of Electrical and Computer Engineering
  Departament of Telematics
  State University of Campinas/Brazil - UNICAMP
  Phone: +55 (19) 3788.3711 - Branch: 73723   
  Home Page: www.dt.fee.unicamp.br/~cora
_________________________________________________________________








Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 11:39:53 -0700
Date: Wed, 04 Sep 2002 14:20:08 -0400
From: Ron Bonica <Ronald.P.Bonica@wcom.com>
Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
To: Tom Scott <telecomtom@vedatel.com>, ccamp@ops.ietf.org
Message-id: <DKEJJCOCJMHEFFNMLKMPKELJHFAA.Ronald.P.Bonica@wcom.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

Tom,

Measurement of one way delay and jitter are beyond the scope of this
document. Although one-way delay and jitter are very interesting metrics,
obtaining them is a non-trivial matter.

/speaking as individual contributor/

                                        Ron


> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Tom Scott
> Sent: Wednesday, September 04, 2002 9:38 AM
> To: ccamp@ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
>
>
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix subscription addresses! ]
>
> The draft addresses spatial tracing.
>
> Is there also interest in time? The only reference to temporal
> tracing is in
> section 6 item 5: "include tunnel components and round trip delay
> across each
> component". In this draft or possibly another it might be
> valuable to extend the
> granularity of the discussion to:
>
> * time: delay and jitter from one node to another.
>
> * space: what are the nodes? Reference to GMPLS in the draft indicate
>    that L1/L2 transport nodes are of interest.
>
> * space and time: within nodes, such as routers, would you extend the
>    spatial and temporal tracing to interfaces? to other logical /
> functional
>    components such as the "datapath elements" referenced in RFC 3290/89?
>    Timing in transport equipment at the sub-IP area and in
> datapath components
>    of those nodes?
>
> It's valuable to know not only where traffic goes but also the
> time it takes to
> get there, on all layers of the path, in equipment on each of
> those layers, and
> in functional components within those nodes. But these issues
> don't have to be
> covered in this draft. They might be addressed elsewhere by
> individuals whose
> daily work depends on multivendor multiprovider QoS tracing.
>
> -- TT
>
>
>
>




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 11:06:23 -0700
Message-ID: <2135200C183FD5119588009027DE5723FD3326@wntcsdexg02.csd.ciena.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Marcos Antonio De Almeida Cora'" <cora@dt.fee.unicamp.br>, mpls@UU.NET, gmpls-ops@mplsrc.com, ccamp@ops.ietf.org
Subject: RE: Doubt on OBGP
Date: Wed, 4 Sep 2002 11:00:09 -0700 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Marcos,

If you mean Optical BGP, this would be for multi-area
routing, not signaling.  I believe ccamp is not yet
chartered to address multi-area routing, or at least
has not seriously taken this issue up at this point.

Also, the status of CR-LDP extensions for GMPLS is not=20
clear given that there has been a push to cap work
on CR-LDP.  Is this still going for Proposed Standard,
or will this become Informational?

Cheers,

L. Ong
Ciena

-----Original Message-----
From: Marcos Antonio De Almeida Cora [mailto:cora@dt.fee.unicamp.br]
Sent: Wednesday, September 04, 2002 9:53 AM
To: mpls@UU.NET; gmpls-ops@mplsrc.com; ccamp@ops.ietf.org
Subject: Doubt on OBGP



 Hi all,=20

 My name is Marcos, I'm MSc Student of School of
Electrical and Computer Engineering (http://www.fee.unicamp.br) of =
State
University of Campinas (http://www.unicamp.br), Brazil.

 I have a doubt on OBGP. I'd like to know if GMPLS support OBGP as a
signaling protocol or only CR-LDP and RSVP-TE is used ???

 If yes, where can I find informations about it.

 Thanks,=20

        Marcos

_________________________________________________________________

  Marcos Ant=F4nio de Almeida Cor=E1   =20
  School of Electrical and Computer Engineering
  Departament of Telematics
  State University of Campinas/Brazil - UNICAMP
  Phone: +55 (19) 3788.3711 - Branch: 73723  =20
  Home Page: www.dt.fee.unicamp.br/~cora
_________________________________________________________________






Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 09:56:06 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8865806@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: 'Maarten Vissers' <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>
Cc: "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>,  "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>,  " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Wed, 4 Sep 2002 09:52:54 -0700 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Maarten,
  You might also want to look at
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt.


Thanks,
Jonathan

> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Wednesday, September 04, 2002 2:34 AM
> To: Diego Caviglia
> Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Diego,
> 
> Michiel and Greg proposed text for such section on neighbor 
> discovery in his lmp
> update draft
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> -update-00.txt
> Refer to section 3 in this contribution.
> 
> This proposal allows neighbor discovery at the 
> - STM-N level,
> - STS/HOVC level,
> - VT/LOVC level.
> 
> I.e it can be used to discover:
> - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via 
> DWDM system)
> - STM-N CTP - TTP neighbors 
> - STM-N CTP - CTP neighbors 
>     Note - STM-N CTP is located in a pre-OTN transparent 
> optical cross 
>            connect (do they still exist these days? :-( ), and in an 
>            OTN ODUk equipment's STM-N trib port interface.
> 
> - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N 
> interfaces 
>                         connected via non-ASON/GMPLS 
> SDH/SONET network)
> - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N 
> interface and SDH ADM)
> - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> 
> - VT/LOVC TTP - TTP neighbors
> - VT/LOVC CTP - TTP neighbors
> - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> 
> It can be used for neighbor discovery in 
> - (simple) link (G.805: link connection) cases and
> - serial-compound link (G.805: link connection) cases.
> 
> This particularly important for the roll out of ASON/GMPLS 
> networks. In this
> phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC 
> [VT/LOVC] connections
> is set up through such non-ASON/GMPLS SDH/SONET network as a 
> (serial-compound)
> link bundle (G.805: (serial-compound) link), then the 
> ASON/GMPLS neighbors are
> the last network element in the first ASON/GMPLS subnetwork 
> and the first
> network element in the second ASON/GMPLS subnetwork. The 
> non-ASON/GMPLS
> SDH/SONET network is now simply a part of the "data link" 
> between these two
> network elements. 
> 
> The ASON/GMPLS SDH/SONET network elements are also 
> "transparent devices" (in the
> sense of LMP section 5, par. 4) that do not "modify or 
> examine data in normal
> operation". As such, the the last sentence in the text in 
> par. 5 of section 5 is
> not correct.
> 
> 	LMP, v0.5, section 5, par. 5: "Furthermore, for the link 
> 	verification procedure it is assumed that the nodal 
> 	architecture is designed so that messages can be sent and
> 	received over any data link. Note that this requirement is 
> 	trivial for opaque devices since each data link is electrically
> 	terminated and processed before being forwarded to the next
> 	opaque device, but that in transparent devices this is an
> 	additional requirement."
> 
> A SDH/SONET cross connect or ADM seems to be such "opaque 
> device", but doesn't
> terminate the STS/HOVC or VT/LOVC "data link" that exists 
> between the two
> ASON/GMPLS neighbors.
> 
> Michiel and Greg's proposal support automatic discovery 
> between two neighbor
> nodes that are either at the end of the same fiber, or at the 
> end of different
> fibers (and have one or more "transparent devices" between 
> these fibers).
> 
> Regards,
> 
> Maarten
> PS. as there seems to be no willingness to address 
> Michiel/Greg's proposal in
> ccamp (is this a correct conclusion of the email 
> correspondence so far), it
> seems waste of time for all to continue this discussion over 
> here. Let's
> concentrate this work in Q.14/15 and include it in G.7714. 
> The market then must
> decide between LMP and G.7714.
> 
> Diego Caviglia wrote:
> > 
> > Hi Dimitri,
> >                           is neighbor discovery in the 
> scope of LMP?  I
> > suppose that it is.
> > 
> > With  Nbr  discovery  I'm referring to the scenario where a 
> TNE is attached
> > to, say 4, TNEs and doesn't know to which of these TNE its 
> TEs are attached
> > to.
> > 
> > Where is this discovery procedure described in the ID?
> > 
> > This  seems  to  me  one  of  the  major  advantages  of 
> LMP (for sure more
> > important  than  fault  management  which  in the transport 
> network is well
> > covered  by  inherent  Sonet/SDH  capabilities)  so a 
> specific section that
> > addresses neighbor discovery is needed, of course IMHO.
> > 
> > Some time ago I posted a mail on this topic, here is the reference:
> > 
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > 
> > Again from my point of view a section that describes in 
> detail this feature
> > is needed in the ID.
> > 
> > Best regards,
> > 
> >             Diego.
> > 
> > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> > 
> > Sent by:  owner-ccamp@ops.ietf.org
> > 
> > To:   Carmine Daloia <daloia@lucent.com>
> > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > 
> > Subject:  Re: Summary of LMP implementation/deployment reports
> > 
> > carmine,
> > 
> > just to be sure here we are on the same level of understanding
> > the bootstrap information that the receiver learn is the equivalent
> > of the one that you would normally provision, i refer you to the
> > following sentence of the Section 3 (of 
> draft-ietf-ccamp-lmp-05.txt):
> > 
> > "To establish a control channel, the destination IP address on the
> >  far end of the control channel must be known. This knowledge may be
> >  manually configured or automatically discovered."
> > 
> > and then you follow the procedure as described in this i-d (in
> > fact the bootstrap i-d also completes the second alternative of
> > the above sentence).
> > 
> > hope this clarifies,
> > - dimitri.
> > 
> > Carmine Daloia wrote:
> > >
> > > Dimitri,
> > >
> > > Thanks for the explanation for why it is left as a 
> separate document.
> > >
> > > I disagree with one point.  You say that the bootstrap 
> process would not
> > > cause anything in the lmp draft to be modified.
> > >
> > > Once the controll address of the neighbor is learned via 
> the bootstrap
> > > process, I don't see the purpose for Control Channel Management
> > Procedure.
> > >
> > > A link summary message can be sent directly to the 
> controll address
> > > learned via the bootstrap process.  Therefore I would 
> have expected the
> > > Control Channel Management Procedure to be removed 
> completely or at
> > > least made optional.
> > >
> > > Carmine
> > >
> > > Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > >carmine,
> > > >
> > > >1) this has been proposed in order to keep going with content
> > > >that has been discussed since more than two years now (and has
> > > >not been modified by the below mentioned document),
> > > >
> > > >2) since the result of the process (and the information it allows
> > > >to discover) is at the end the same than the one obtained when
> > > >applying the test message procedure no subsequent mechanisms
> > > >are modified by the bootstrap approach
> > > >
> > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > >from the mailing list discussions) to be useful (up to now) for
> > > >sonet/sdh or more generally for "optical" environments only.
> > > >
> > > >thus i think this may justify the (good imho) idea to have two
> > > >separate documents (it results from the above points to be thus
> > > >also justified from an implementation viewpoint)
> > > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Carmine Daloia wrote:
> > > >
> > > >
> > > >>Why is the procedure described in the lmp-bootstrap 
> draft not included
> > > >>in the lmp-draft?  Doesn't sound like lmp is complete 
> without this
> > > >>capability and therefore doesn't seem to make sense to 
> have these in
> > > >>separate drafts.
> > > >>
> > > >>Carmine
> > > >>
> > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Carmine,
> > > >>>
> > > >>>this is why i have previously mentioned in my response
> > > >>>that "a proposal has been made to bootstrap out-of-band
> > > >>>control channels and discover the interface_id mappings
> > > >>>(or associations) before establishing a control channel"
> > > >>>
> > > >>>see:
> > >
> > 
> >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> otstrap-00.txt
> > 
> > > >>>
> > > >>>thus the problem you've indicated in the below message is
> > > >>>also addressed -
> > > >>>
> > > >>>so
> > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>operator provisioning) if the operator has previously 
> provisioned the
> > > >>>>remote node addresses for each and every data link. "
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>may be now rephrased as
> > > >>>" LMP can *build* the mappings (i.e., reduce operator 
> provisioning)
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>without any provisioning of the remote node addresses for each
> > > >>>>and every data link"
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>thanks,
> > > >>>- dimitri.
> > > >>>
> > > >>>Carmine Daloia wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Kireeti, Dimitri,
> > > >>>>
> > > >>>>I realize that Section 5 in 
> draft-ietf-ccamp-lmp-05.txt states that
> > the
> > > >>>>Link Connectivity Verification procedure (which is 
> optional) may be
> > used
> > > >>>>to dynamically learn the id associations.  Is this 
> what you mean by
> > LMP
> > > >>>>being able to *build* the mappings?  However this 
> requires that an
> > > >>>>operator *PROVISION* for each and every data link the 
> remote node
> > > >>>>address that the data link is terminated on.  Only with this
> > > >>>>provisioning will the local node know the address to send the
> > > >>>>BeginVerify message to.   So LMP can *build* the 
> mappings (i.e.,
> > reduce
> > > >>>>operator provisioning) if the operator has previously 
> provisioned the
> > > >>>>remote node addresses for each and every data link.  
> Doesn't seem
> > like a
> > > >>>>useful capability.
> > > >>>>
> > > >>>>Carmine
> > > >>>>
> > > >>>>Kireeti Kompella wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Hi Carmine,
> > > >>>>>
> > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>So basically LMP is used to verify that the 
> datalink id mappings
> > stored
> > > >>>>>>in the neighboring nodes match eachother.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Actually, LMP is used to *build* the mappings, not 
> verify them.  If
> > the
> > > >>>>>mappings were already stored, LMP could be used to 
> verify them --
> > but
> > > >>>>>that is a secondary function.
> > > >>>>>
> > > >>>>>Kireeti (as a WG participant).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>
> > 
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : dpapadimitriou@psg.com
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 09:11:42 -0700
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BAC16C@mbddmknt01.nat.bt.com>
From: neil.2.harrison@bt.com
To: mvissers@lucent.com
Cc: ccamp@ops.ietf.org
Subject: RE: Summary of LMP implementation/deployment reports
Date: Wed, 4 Sep 2002 17:06:36 +0100 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Maarten...I think the URL you gave is wrong....I believe it should be this:
http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt

regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: 04 September 2002 14:05
> To: Wijnen, Bert
> Cc: ccamp
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Bert,
> 
> The technology specific part of the proposed neighbor 
> discovery is the bandwidth
> selected to transport the neighbor discovery message defined 
> in section 3 of
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> -00.txt. 
> I.e. the proposal suggests to use as bandwidth the SDH 
> overhead bytes J0 (STM-N
> link), J1 (STS/HOVC link), J2 (VT/LOVC link).
> 
> The discovery method and message itself are generic and can 
> be applied to
> multiple technologies.
> E.g. for an OTN ODUk link one could use as bandwidth the 
> bytes 32-63 in the ODUk
> TTI overhead.
> 
> Regards,
> 
> Maarten
> 
> 
> Wijnen, Bert (Bert)" wrote:
> > 
> > Guys... I have already strongly suggested that any 
> technology specific
> > stuff goes in a separate doc. Still need to check if and how this
> > has been teken care of in the new revision.
> > 
> > But if any of the technology specific stuff listed below were to be
> > accepted by the WG, I think it should be in a separate technology
> > specific document, and NOT in the COMMON CONTROL LMP document.
> > 
> > And if this is optical technology specific, does it then belong in
> > in CCAMP, or even in IETF or is it something to be done in another
> > WG or in another organisation?
> > 
> > Thanks,
> > Bert
> > 
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > > Sent: woensdag 4 september 2002 11:34
> > > To: Diego Caviglia
> > > Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; 
> Kireeti Kompella
> > > <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> > > Subject: Re: Summary of LMP implementation/deployment reports
> > >
> > >
> > > Diego,
> > >
> > > Michiel and Greg proposed text for such section on neighbor
> > > discovery in his lmp
> > > update draft
> > > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> > > -update-00.txt
> > > Refer to section 3 in this contribution.
> > >
> > > This proposal allows neighbor discovery at the
> > > - STM-N level,
> > > - STS/HOVC level,
> > > - VT/LOVC level.
> > >
> > > I.e it can be used to discover:
> > > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via
> > > DWDM system)
> > > - STM-N CTP - TTP neighbors
> > > - STM-N CTP - CTP neighbors
> > >     Note - STM-N CTP is located in a pre-OTN transparent
> > > optical cross
> > >            connect (do they still exist these days? :-( 
> ), and in an
> > >            OTN ODUk equipment's STM-N trib port interface.
> > >
> > > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N
> > > interfaces
> > >                         connected via non-ASON/GMPLS
> > > SDH/SONET network)
> > > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N
> > > interface and SDH ADM)
> > > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> > >
> > > - VT/LOVC TTP - TTP neighbors
> > > - VT/LOVC CTP - TTP neighbors
> > > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> > >
> > > It can be used for neighbor discovery in
> > > - (simple) link (G.805: link connection) cases and
> > > - serial-compound link (G.805: link connection) cases.
> > >
> > > This particularly important for the roll out of ASON/GMPLS
> > > networks. In this
> > > phase there will be many non-ASON/GMPLS SDH/SONET 
> networks which will
> > > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC
> > > [VT/LOVC] connections
> > > is set up through such non-ASON/GMPLS SDH/SONET network as a
> > > (serial-compound)
> > > link bundle (G.805: (serial-compound) link), then the
> > > ASON/GMPLS neighbors are
> > > the last network element in the first ASON/GMPLS subnetwork
> > > and the first
> > > network element in the second ASON/GMPLS subnetwork. The
> > > non-ASON/GMPLS
> > > SDH/SONET network is now simply a part of the "data link"
> > > between these two
> > > network elements.
> > >
> > > The ASON/GMPLS SDH/SONET network elements are also
> > > "transparent devices" (in the
> > > sense of LMP section 5, par. 4) that do not "modify or
> > > examine data in normal
> > > operation". As such, the the last sentence in the text in
> > > par. 5 of section 5 is
> > > not correct.
> > >
> > >       LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> > >       verification procedure it is assumed that the nodal
> > >       architecture is designed so that messages can be sent and
> > >       received over any data link. Note that this requirement is
> > >       trivial for opaque devices since each data link is 
> electrically
> > >       terminated and processed before being forwarded to the next
> > >       opaque device, but that in transparent devices this is an
> > >       additional requirement."
> > >
> > > A SDH/SONET cross connect or ADM seems to be such "opaque
> > > device", but doesn't
> > > terminate the STS/HOVC or VT/LOVC "data link" that exists
> > > between the two
> > > ASON/GMPLS neighbors.
> > >
> > > Michiel and Greg's proposal support automatic discovery
> > > between two neighbor
> > > nodes that are either at the end of the same fiber, or at the
> > > end of different
> > > fibers (and have one or more "transparent devices" between
> > > these fibers).
> > >
> > > Regards,
> > >
> > > Maarten
> > > PS. as there seems to be no willingness to address
> > > Michiel/Greg's proposal in
> > > ccamp (is this a correct conclusion of the email
> > > correspondence so far), it
> > > seems waste of time for all to continue this discussion over
> > > here. Let's
> > > concentrate this work in Q.14/15 and include it in G.7714.
> > > The market then must
> > > decide between LMP and G.7714.
> > >
> > > Diego Caviglia wrote:
> > > >
> > > > Hi Dimitri,
> > > >                           is neighbor discovery in the
> > > scope of LMP?  I
> > > > suppose that it is.
> > > >
> > > > With  Nbr  discovery  I'm referring to the scenario where a
> > > TNE is attached
> > > > to, say 4, TNEs and doesn't know to which of these TNE its
> > > TEs are attached
> > > > to.
> > > >
> > > > Where is this discovery procedure described in the ID?
> > > >
> > > > This  seems  to  me  one  of  the  major  advantages  of
> > > LMP (for sure more
> > > > important  than  fault  management  which  in the transport
> > > network is well
> > > > covered  by  inherent  Sonet/SDH  capabilities)  so a
> > > specific section that
> > > > addresses neighbor discovery is needed, of course IMHO.
> > > >
> > > > Some time ago I posted a mail on this topic, here is 
> the reference:
> > > >
> > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > > >
> > > > Again from my point of view a section that describes in
> > > detail this feature
> > > > is needed in the ID.
> > > >
> > > > Best regards,
> > > >
> > > >             Diego.
> > > >
> > > > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 
> 03/09/2002 22.06.43
> > > >
> > > > Sent by:  owner-ccamp@ops.ietf.org
> > > >
> > > > To:   Carmine Daloia <daloia@lucent.com>
> > > > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> > > >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" 
> <ccamp@ops.ietf.org>
> > > >
> > > > Subject:  Re: Summary of LMP implementation/deployment reports
> > > >
> > > > carmine,
> > > >
> > > > just to be sure here we are on the same level of understanding
> > > > the bootstrap information that the receiver learn is 
> the equivalent
> > > > of the one that you would normally provision, i refer you to the
> > > > following sentence of the Section 3 (of
> > > draft-ietf-ccamp-lmp-05.txt):
> > > >
> > > > "To establish a control channel, the destination IP 
> address on the
> > > >  far end of the control channel must be known. This 
> knowledge may be
> > > >  manually configured or automatically discovered."
> > > >
> > > > and then you follow the procedure as described in this i-d (in
> > > > fact the bootstrap i-d also completes the second alternative of
> > > > the above sentence).
> > > >
> > > > hope this clarifies,
> > > > - dimitri.
> > > >
> > > > Carmine Daloia wrote:
> > > > >
> > > > > Dimitri,
> > > > >
> > > > > Thanks for the explanation for why it is left as a
> > > separate document.
> > > > >
> > > > > I disagree with one point.  You say that the bootstrap
> > > process would not
> > > > > cause anything in the lmp draft to be modified.
> > > > >
> > > > > Once the controll address of the neighbor is learned via
> > > the bootstrap
> > > > > process, I don't see the purpose for Control Channel 
> Management
> > > > Procedure.
> > > > >
> > > > > A link summary message can be sent directly to the
> > > controll address
> > > > > learned via the bootstrap process.  Therefore I would
> > > have expected the
> > > > > Control Channel Management Procedure to be removed
> > > completely or at
> > > > > least made optional.
> > > > >
> > > > > Carmine
> > > > >
> > > > > Dimitri.Papadimitriou@alcatel.be wrote:
> > > > >
> > > > > >carmine,
> > > > > >
> > > > > >1) this has been proposed in order to keep going with content
> > > > > >that has been discussed since more than two years 
> now (and has
> > > > > >not been modified by the below mentioned document),
> > > > > >
> > > > > >2) since the result of the process (and the 
> information it allows
> > > > > >to discover) is at the end the same than the one 
> obtained when
> > > > > >applying the test message procedure no subsequent mechanisms
> > > > > >are modified by the bootstrap approach
> > > > > >
> > > > > >3) moreover, the bootstrap mechanisms have been 
> identified (this
> > > > > >from the mailing list discussions) to be useful (up 
> to now) for
> > > > > >sonet/sdh or more generally for "optical" environments only.
> > > > > >
> > > > > >thus i think this may justify the (good imho) idea 
> to have two
> > > > > >separate documents (it results from the above points 
> to be thus
> > > > > >also justified from an implementation viewpoint)
> > > > > >
> > > > > >thanks,
> > > > > >- dimitri.
> > > > > >
> > > > > >Carmine Daloia wrote:
> > > > > >
> > > > > >
> > > > > >>Why is the procedure described in the lmp-bootstrap
> > > draft not included
> > > > > >>in the lmp-draft?  Doesn't sound like lmp is complete
> > > without this
> > > > > >>capability and therefore doesn't seem to make sense to
> > > have these in
> > > > > >>separate drafts.
> > > > > >>
> > > > > >>Carmine
> > > > > >>
> > > > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>Carmine,
> > > > > >>>
> > > > > >>>this is why i have previously mentioned in my response
> > > > > >>>that "a proposal has been made to bootstrap out-of-band
> > > > > >>>control channels and discover the interface_id mappings
> > > > > >>>(or associations) before establishing a control channel"
> > > > > >>>
> > > > > >>>see:
> > > > >
> > > >
> > > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> > > otstrap-00.txt
> > > >
> > > > > >>>
> > > > > >>>thus the problem you've indicated in the below message is
> > > > > >>>also addressed -
> > > > > >>>
> > > > > >>>so
> > > > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>operator provisioning) if the operator has previously
> > > provisioned the
> > > > > >>>>remote node addresses for each and every data link. "
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>may be now rephrased as
> > > > > >>>" LMP can *build* the mappings (i.e., reduce operator
> > > provisioning)
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>without any provisioning of the remote node 
> addresses for each
> > > > > >>>>and every data link"
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>thanks,
> > > > > >>>- dimitri.
> > > > > >>>
> > > > > >>>Carmine Daloia wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>Kireeti, Dimitri,
> > > > > >>>>
> > > > > >>>>I realize that Section 5 in
> > > draft-ietf-ccamp-lmp-05.txt states that
> > > > the
> > > > > >>>>Link Connectivity Verification procedure (which is
> > > optional) may be
> > > > used
> > > > > >>>>to dynamically learn the id associations.  Is this
> > > what you mean by
> > > > LMP
> > > > > >>>>being able to *build* the mappings?  However this
> > > requires that an
> > > > > >>>>operator *PROVISION* for each and every data link the
> > > remote node
> > > > > >>>>address that the data link is terminated on.  
> Only with this
> > > > > >>>>provisioning will the local node know the address 
> to send the
> > > > > >>>>BeginVerify message to.   So LMP can *build* the
> > > mappings (i.e.,
> > > > reduce
> > > > > >>>>operator provisioning) if the operator has previously
> > > provisioned the
> > > > > >>>>remote node addresses for each and every data link.
> > > Doesn't seem
> > > > like a
> > > > > >>>>useful capability.
> > > > > >>>>
> > > > > >>>>Carmine
> > > > > >>>>
> > > > > >>>>Kireeti Kompella wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>>Hi Carmine,
> > > > > >>>>>
> > > > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>So basically LMP is used to verify that the
> > > datalink id mappings
> > > > stored
> > > > > >>>>>>in the neighboring nodes match eachother.
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>Actually, LMP is used to *build* the mappings, not
> > > verify them.  If
> > > > the
> > > > > >>>>>mappings were already stored, LMP could be used to
> > > verify them --
> > > > but
> > > > > >>>>>that is a secondary function.
> > > > > >>>>>
> > > > > >>>>>Kireeti (as a WG participant).
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > >
> > > > --
> > > > Papadimitriou Dimitri
> > > > E-mail : dimitri.papadimitriou@alcatel.be
> > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > E-mail : dpapadimitriou@psg.com
> > > > Public : http://psg.com/~dpapadimitriou/
> > > > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> > > >          B-2018 Antwerpen, Belgium
> > > > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 08:35:17 -0700
Message-ID: <3D760CBE.4030001@vedatel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 04 Sep 2002 09:38:06 -0400
From: Tom Scott <telecomtom@vedatel.com>
To: ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

The draft addresses spatial tracing.

Is there also interest in time? The only reference to temporal tracing is in
section 6 item 5: "include tunnel components and round trip delay across each
component". In this draft or possibly another it might be valuable to extend the
granularity of the discussion to:

* time: delay and jitter from one node to another.

* space: what are the nodes? Reference to GMPLS in the draft indicate
   that L1/L2 transport nodes are of interest.

* space and time: within nodes, such as routers, would you extend the
   spatial and temporal tracing to interfaces? to other logical / functional
   components such as the "datapath elements" referenced in RFC 3290/89?
   Timing in transport equipment at the sub-IP area and in datapath components
   of those nodes?

It's valuable to know not only where traffic goes but also the time it takes to
get there, on all layers of the path, in equipment on each of those layers, and
in functional components within those nodes. But these issues don't have to be
covered in this draft. They might be addressed elsewhere by individuals whose
daily work depends on multivendor multiprovider QoS tracing.

-- TT






Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 06:08:49 -0700
Cc: ccamp <ccamp@ops.ietf.org>
Message-ID: <3D76050A.9D69D540@lucent.com>
Date: Wed, 04 Sep 2002 15:05:14 +0200
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
MIME-Version: 1.0
To: "Wijnen, Bert" <bwijnen@lucent.com>
Original-CC: ccamp <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bert,

The technology specific part of the proposed neighbor discovery is the bandwidth
selected to transport the neighbor discovery message defined in section 3 of
http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-00.txt. 
I.e. the proposal suggests to use as bandwidth the SDH overhead bytes J0 (STM-N
link), J1 (STS/HOVC link), J2 (VT/LOVC link).

The discovery method and message itself are generic and can be applied to
multiple technologies.
E.g. for an OTN ODUk link one could use as bandwidth the bytes 32-63 in the ODUk
TTI overhead.

Regards,

Maarten


Wijnen, Bert (Bert)" wrote:
> 
> Guys... I have already strongly suggested that any technology specific
> stuff goes in a separate doc. Still need to check if and how this
> has been teken care of in the new revision.
> 
> But if any of the technology specific stuff listed below were to be
> accepted by the WG, I think it should be in a separate technology
> specific document, and NOT in the COMMON CONTROL LMP document.
> 
> And if this is optical technology specific, does it then belong in
> in CCAMP, or even in IETF or is it something to be done in another
> WG or in another organisation?
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: woensdag 4 september 2002 11:34
> > To: Diego Caviglia
> > Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> > <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> > Subject: Re: Summary of LMP implementation/deployment reports
> >
> >
> > Diego,
> >
> > Michiel and Greg proposed text for such section on neighbor
> > discovery in his lmp
> > update draft
> > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> > -update-00.txt
> > Refer to section 3 in this contribution.
> >
> > This proposal allows neighbor discovery at the
> > - STM-N level,
> > - STS/HOVC level,
> > - VT/LOVC level.
> >
> > I.e it can be used to discover:
> > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via
> > DWDM system)
> > - STM-N CTP - TTP neighbors
> > - STM-N CTP - CTP neighbors
> >     Note - STM-N CTP is located in a pre-OTN transparent
> > optical cross
> >            connect (do they still exist these days? :-( ), and in an
> >            OTN ODUk equipment's STM-N trib port interface.
> >
> > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N
> > interfaces
> >                         connected via non-ASON/GMPLS
> > SDH/SONET network)
> > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N
> > interface and SDH ADM)
> > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> >
> > - VT/LOVC TTP - TTP neighbors
> > - VT/LOVC CTP - TTP neighbors
> > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> >
> > It can be used for neighbor discovery in
> > - (simple) link (G.805: link connection) cases and
> > - serial-compound link (G.805: link connection) cases.
> >
> > This particularly important for the roll out of ASON/GMPLS
> > networks. In this
> > phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC
> > [VT/LOVC] connections
> > is set up through such non-ASON/GMPLS SDH/SONET network as a
> > (serial-compound)
> > link bundle (G.805: (serial-compound) link), then the
> > ASON/GMPLS neighbors are
> > the last network element in the first ASON/GMPLS subnetwork
> > and the first
> > network element in the second ASON/GMPLS subnetwork. The
> > non-ASON/GMPLS
> > SDH/SONET network is now simply a part of the "data link"
> > between these two
> > network elements.
> >
> > The ASON/GMPLS SDH/SONET network elements are also
> > "transparent devices" (in the
> > sense of LMP section 5, par. 4) that do not "modify or
> > examine data in normal
> > operation". As such, the the last sentence in the text in
> > par. 5 of section 5 is
> > not correct.
> >
> >       LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> >       verification procedure it is assumed that the nodal
> >       architecture is designed so that messages can be sent and
> >       received over any data link. Note that this requirement is
> >       trivial for opaque devices since each data link is electrically
> >       terminated and processed before being forwarded to the next
> >       opaque device, but that in transparent devices this is an
> >       additional requirement."
> >
> > A SDH/SONET cross connect or ADM seems to be such "opaque
> > device", but doesn't
> > terminate the STS/HOVC or VT/LOVC "data link" that exists
> > between the two
> > ASON/GMPLS neighbors.
> >
> > Michiel and Greg's proposal support automatic discovery
> > between two neighbor
> > nodes that are either at the end of the same fiber, or at the
> > end of different
> > fibers (and have one or more "transparent devices" between
> > these fibers).
> >
> > Regards,
> >
> > Maarten
> > PS. as there seems to be no willingness to address
> > Michiel/Greg's proposal in
> > ccamp (is this a correct conclusion of the email
> > correspondence so far), it
> > seems waste of time for all to continue this discussion over
> > here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714.
> > The market then must
> > decide between LMP and G.7714.
> >
> > Diego Caviglia wrote:
> > >
> > > Hi Dimitri,
> > >                           is neighbor discovery in the
> > scope of LMP?  I
> > > suppose that it is.
> > >
> > > With  Nbr  discovery  I'm referring to the scenario where a
> > TNE is attached
> > > to, say 4, TNEs and doesn't know to which of these TNE its
> > TEs are attached
> > > to.
> > >
> > > Where is this discovery procedure described in the ID?
> > >
> > > This  seems  to  me  one  of  the  major  advantages  of
> > LMP (for sure more
> > > important  than  fault  management  which  in the transport
> > network is well
> > > covered  by  inherent  Sonet/SDH  capabilities)  so a
> > specific section that
> > > addresses neighbor discovery is needed, of course IMHO.
> > >
> > > Some time ago I posted a mail on this topic, here is the reference:
> > >
> > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > >
> > > Again from my point of view a section that describes in
> > detail this feature
> > > is needed in the ID.
> > >
> > > Best regards,
> > >
> > >             Diego.
> > >
> > > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> > >
> > > Sent by:  owner-ccamp@ops.ietf.org
> > >
> > > To:   Carmine Daloia <daloia@lucent.com>
> > > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> > >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > >
> > > Subject:  Re: Summary of LMP implementation/deployment reports
> > >
> > > carmine,
> > >
> > > just to be sure here we are on the same level of understanding
> > > the bootstrap information that the receiver learn is the equivalent
> > > of the one that you would normally provision, i refer you to the
> > > following sentence of the Section 3 (of
> > draft-ietf-ccamp-lmp-05.txt):
> > >
> > > "To establish a control channel, the destination IP address on the
> > >  far end of the control channel must be known. This knowledge may be
> > >  manually configured or automatically discovered."
> > >
> > > and then you follow the procedure as described in this i-d (in
> > > fact the bootstrap i-d also completes the second alternative of
> > > the above sentence).
> > >
> > > hope this clarifies,
> > > - dimitri.
> > >
> > > Carmine Daloia wrote:
> > > >
> > > > Dimitri,
> > > >
> > > > Thanks for the explanation for why it is left as a
> > separate document.
> > > >
> > > > I disagree with one point.  You say that the bootstrap
> > process would not
> > > > cause anything in the lmp draft to be modified.
> > > >
> > > > Once the controll address of the neighbor is learned via
> > the bootstrap
> > > > process, I don't see the purpose for Control Channel Management
> > > Procedure.
> > > >
> > > > A link summary message can be sent directly to the
> > controll address
> > > > learned via the bootstrap process.  Therefore I would
> > have expected the
> > > > Control Channel Management Procedure to be removed
> > completely or at
> > > > least made optional.
> > > >
> > > > Carmine
> > > >
> > > > Dimitri.Papadimitriou@alcatel.be wrote:
> > > >
> > > > >carmine,
> > > > >
> > > > >1) this has been proposed in order to keep going with content
> > > > >that has been discussed since more than two years now (and has
> > > > >not been modified by the below mentioned document),
> > > > >
> > > > >2) since the result of the process (and the information it allows
> > > > >to discover) is at the end the same than the one obtained when
> > > > >applying the test message procedure no subsequent mechanisms
> > > > >are modified by the bootstrap approach
> > > > >
> > > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > > >from the mailing list discussions) to be useful (up to now) for
> > > > >sonet/sdh or more generally for "optical" environments only.
> > > > >
> > > > >thus i think this may justify the (good imho) idea to have two
> > > > >separate documents (it results from the above points to be thus
> > > > >also justified from an implementation viewpoint)
> > > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Carmine Daloia wrote:
> > > > >
> > > > >
> > > > >>Why is the procedure described in the lmp-bootstrap
> > draft not included
> > > > >>in the lmp-draft?  Doesn't sound like lmp is complete
> > without this
> > > > >>capability and therefore doesn't seem to make sense to
> > have these in
> > > > >>separate drafts.
> > > > >>
> > > > >>Carmine
> > > > >>
> > > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Carmine,
> > > > >>>
> > > > >>>this is why i have previously mentioned in my response
> > > > >>>that "a proposal has been made to bootstrap out-of-band
> > > > >>>control channels and discover the interface_id mappings
> > > > >>>(or associations) before establishing a control channel"
> > > > >>>
> > > > >>>see:
> > > >
> > >
> > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> > otstrap-00.txt
> > >
> > > > >>>
> > > > >>>thus the problem you've indicated in the below message is
> > > > >>>also addressed -
> > > > >>>
> > > > >>>so
> > > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>operator provisioning) if the operator has previously
> > provisioned the
> > > > >>>>remote node addresses for each and every data link. "
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>may be now rephrased as
> > > > >>>" LMP can *build* the mappings (i.e., reduce operator
> > provisioning)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>without any provisioning of the remote node addresses for each
> > > > >>>>and every data link"
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>thanks,
> > > > >>>- dimitri.
> > > > >>>
> > > > >>>Carmine Daloia wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>Kireeti, Dimitri,
> > > > >>>>
> > > > >>>>I realize that Section 5 in
> > draft-ietf-ccamp-lmp-05.txt states that
> > > the
> > > > >>>>Link Connectivity Verification procedure (which is
> > optional) may be
> > > used
> > > > >>>>to dynamically learn the id associations.  Is this
> > what you mean by
> > > LMP
> > > > >>>>being able to *build* the mappings?  However this
> > requires that an
> > > > >>>>operator *PROVISION* for each and every data link the
> > remote node
> > > > >>>>address that the data link is terminated on.  Only with this
> > > > >>>>provisioning will the local node know the address to send the
> > > > >>>>BeginVerify message to.   So LMP can *build* the
> > mappings (i.e.,
> > > reduce
> > > > >>>>operator provisioning) if the operator has previously
> > provisioned the
> > > > >>>>remote node addresses for each and every data link.
> > Doesn't seem
> > > like a
> > > > >>>>useful capability.
> > > > >>>>
> > > > >>>>Carmine
> > > > >>>>
> > > > >>>>Kireeti Kompella wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>Hi Carmine,
> > > > >>>>>
> > > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>So basically LMP is used to verify that the
> > datalink id mappings
> > > stored
> > > > >>>>>>in the neighboring nodes match eachother.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>Actually, LMP is used to *build* the mappings, not
> > verify them.  If
> > > the
> > > > >>>>>mappings were already stored, LMP could be used to
> > verify them --
> > > but
> > > > >>>>>that is a secondary function.
> > > > >>>>>
> > > > >>>>>Kireeti (as a WG participant).
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : dimitri.papadimitriou@alcatel.be
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : dpapadimitriou@psg.com
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> > >          B-2018 Antwerpen, Belgium
> > > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
> >



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 05:38:35 -0700
Message-ID: <3D75FE77.B6DE2D8F@alcatel.be>
Date: Wed, 04 Sep 2002 14:37:11 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
Cc: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

yangguang

you clearly understood what i mean, i just propose
to follow the rules applied to the other common 
control gmpls signalling i-d's following the well
known rough consensus achieved on the ccamp mailing 
list for these i-d's

thanks,
- dimitri.

Yangguang Xu wrote:
> 
> Dimitri,
> 
> >
> > clearly i just suggested to include the technology specifics
> > in separate technology specific i-d's, and not in the main
> > i-d (bert refers to it as the common control lmp i-d meaning
> > draft-ietf-ccamp-lmp-05.txt)
> >
> 
> How about the pre-OTN specific stuff in LMP?
> 
> Are you saying that you want different rules for different drafts?
> 
> Yangguang

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 05:24:00 -0700
Message-ID: <3D75FAE3.7A810896@lucent.com>
Date: Wed, 04 Sep 2002 08:21:55 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dimitri,

> 
> clearly i just suggested to include the technology specifics
> in separate technology specific i-d's, and not in the main
> i-d (bert refers to it as the common control lmp i-d meaning
> draft-ietf-ccamp-lmp-05.txt)
> 

How about the pre-OTN specific stuff in LMP? 

Are you saying that you want different rules for different drafts?

Yangguang



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 05:18:26 -0700
Message-ID: <3D75F9FB.340E8602@alcatel.be>
Date: Wed, 04 Sep 2002 14:18:03 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
Cc: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

yangguang,

clearly i just suggested to include the technology specifics
in separate technology specific i-d's, and not in the main 
i-d (bert refers to it as the common control lmp i-d meaning
draft-ietf-ccamp-lmp-05.txt)

example: put the sonet/sdh test message specifics to its own 
sonet/sdh dedicated i-d

thanks,
- dimitri

Yangguang Xu wrote:
> 
> Dimitri,
> 
> Following what you said, are you also proposing we should take technology
> specific stuff from the current LMP draft? Then I agree with you.
> 
> Thanks,
> 
> Yangguang
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > maarten, diego,
> >
> > the question of diego is "... a section that describes in
> > detail this feature (dixit neighbor discovery) is needed
> > in the ID." and the response is such description should
> > be imho in an applicability statement i-d (describing the
> > use of the lmp features), neighbor discovery as proposed
> > in your response is focusing on "sdh/sonet" environments
> > while as discussed many times lmp targeted more and the
> > community implements more - this is also clear from the
> > results of the implementation/deployment reports - i refer
> > you to the e-mail of kireeti (for more on hourglass):
> >
> > http://psg.com/lists/ccamp/ccamp.2002/msg01005.html
> >
> > further a dedicated i-d will address the specifics of
> > "sdh/sonet" environments that's from a practical viewpoint
> > the best way to proceed in order to keep a consistent/
> > modular approach while for the bootstrap i-d the valuable
> > comments as received since so far will also be addressed
> > - thus since so far all this should address the main
> > concerns of our community -
> >
> > note also that in general such applicability i-d starts
> > when most of the protocol details are known.
> >
> > your last point is also interesting - ditto:
> > "> PS. as there seems to be no willingness to address Michiel/Greg's
> > proposal in
> > > ccamp (is this a correct conclusion of the email correspondence so far), it
> > > seems waste of time for all to continue this discussion over here. Let's
> > > concentrate this work in Q.14/15 and include it in G.7714."
> >
> > first our community does not stricto sensu address proposals
> > (or i-ds) but consented items and corresponding solutions/
> > mechanisms in several levels of documents - the document is
> > a way to achieve interoperable running code not the ultimate
> > final goal in itself.
> >
> > but then:
> > > The market then must decide between LMP and G.7714."
> >
> > the response is imho related to last question in the greg's
> > e-mail (http://psg.com/lists/ccamp/ccamp.2002/msg01092.html):
> >
> > "> (c) Of the implementations that Bert listed, how many were being used
> > just
> > > for OIF UNI 1.0 discovery (SONET/SDH) interoperability rather than general
> > > LMP?"
> >
> > well the response is indicated in the bert's report:
> >
> > "One implementation was O-UNI version of LMP, so does not do
> > all the things described in current LMP draft."
> >
> > but i also think that it means more, it means that the ccamp
> > community majority is implementing the complete protocol and
> > not only its set of functions for sonet/sdh in a oif uni
> > context -> therefore may we not expect here the same kind of
> > response in the ason context (debate is open) what are the
> > rationale for a vendor to implement a version of lmp per
> > environment ? what will happen when this protocol will be
> > used in multi-service devices ? imho a practical view on
> > this problem gives many responses and insight for the future
> > but in any case i am not sure that some parts of you post-
> > scriptum are really in-line with the way of thinking of our
> > community (which i don't think targets any competition)
> >
> > thanks
> > - dimitri.
> >
> > Maarten Vissers wrote:
> > >
> > > Diego,
> > >
> > > Michiel and Greg proposed text for such section on neighbor discovery in his lmp
> > > update draft
> > > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
> > > Refer to section 3 in this contribution.
> > >
> > > This proposal allows neighbor discovery at the
> > > - STM-N level,
> > > - STS/HOVC level,
> > > - VT/LOVC level.
> > >
> > > I.e it can be used to discover:
> > > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via DWDM system)
> > > - STM-N CTP - TTP neighbors
> > > - STM-N CTP - CTP neighbors
> > >     Note - STM-N CTP is located in a pre-OTN transparent optical cross
> > >            connect (do they still exist these days? :-( ), and in an
> > >            OTN ODUk equipment's STM-N trib port interface.
> > >
> > > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N interfaces
> > >                         connected via non-ASON/GMPLS SDH/SONET network)
> > > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N interface and SDH ADM)
> > > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> > >
> > > - VT/LOVC TTP - TTP neighbors
> > > - VT/LOVC CTP - TTP neighbors
> > > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> > >
> > > It can be used for neighbor discovery in
> > > - (simple) link (G.805: link connection) cases and
> > > - serial-compound link (G.805: link connection) cases.
> > >
> > > This particularly important for the roll out of ASON/GMPLS networks. In this
> > > phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> > > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC [VT/LOVC] connections
> > > is set up through such non-ASON/GMPLS SDH/SONET network as a (serial-compound)
> > > link bundle (G.805: (serial-compound) link), then the ASON/GMPLS neighbors are
> > > the last network element in the first ASON/GMPLS subnetwork and the first
> > > network element in the second ASON/GMPLS subnetwork. The non-ASON/GMPLS
> > > SDH/SONET network is now simply a part of the "data link" between these two
> > > network elements.
> > >
> > > The ASON/GMPLS SDH/SONET network elements are also "transparent devices" (in the
> > > sense of LMP section 5, par. 4) that do not "modify or examine data in normal
> > > operation". As such, the the last sentence in the text in par. 5 of section 5 is
> > > not correct.
> > >
> > >         LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> > >         verification procedure it is assumed that the nodal
> > >         architecture is designed so that messages can be sent and
> > >         received over any data link. Note that this requirement is
> > >         trivial for opaque devices since each data link is electrically
> > >         terminated and processed before being forwarded to the next
> > >         opaque device, but that in transparent devices this is an
> > >         additional requirement."
> > >
> > > A SDH/SONET cross connect or ADM seems to be such "opaque device", but doesn't
> > > terminate the STS/HOVC or VT/LOVC "data link" that exists between the two
> > > ASON/GMPLS neighbors.
> > >
> > > Michiel and Greg's proposal support automatic discovery between two neighbor
> > > nodes that are either at the end of the same fiber, or at the end of different
> > > fibers (and have one or more "transparent devices" between these fibers).
> > >
> > > Regards,
> > >
> > > Maarten
> > > PS. as there seems to be no willingness to address Michiel/Greg's proposal in
> > > ccamp (is this a correct conclusion of the email correspondence so far), it
> > > seems waste of time for all to continue this discussion over here. Let's
> > > concentrate this work in Q.14/15 and include it in G.7714. The market then must
> > > decide between LMP and G.7714.
> > >
> > > Diego Caviglia wrote:
> > > >
> > > > Hi Dimitri,
> > > >                           is neighbor discovery in the scope of LMP?  I
> > > > suppose that it is.
> > > >
> > > > With  Nbr  discovery  I'm referring to the scenario where a TNE is attached
> > > > to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
> > > > to.
> > > >
> > > > Where is this discovery procedure described in the ID?
> > > >
> > > > This  seems  to  me  one  of  the  major  advantages  of LMP (for sure more
> > > > important  than  fault  management  which  in the transport network is well
> > > > covered  by  inherent  Sonet/SDH  capabilities)  so a specific section that
> > > > addresses neighbor discovery is needed, of course IMHO.
> > > >
> > > > Some time ago I posted a mail on this topic, here is the reference:
> > > >
> > > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > > >
> > > > Again from my point of view a section that describes in detail this feature
> > > > is needed in the ID.
> > > >
> > > > Best regards,
> > > >
> > > >             Diego.
> > > >
> > > > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> > > >
> > > > Sent by:  owner-ccamp@ops.ietf.org
> > > >
> > > > To:   Carmine Daloia <daloia@lucent.com>
> > > > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> > > >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > > >
> > > > Subject:  Re: Summary of LMP implementation/deployment reports
> > > >
> > > > carmine,
> > > >
> > > > just to be sure here we are on the same level of understanding
> > > > the bootstrap information that the receiver learn is the equivalent
> > > > of the one that you would normally provision, i refer you to the
> > > > following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):
> > > >
> > > > "To establish a control channel, the destination IP address on the
> > > >  far end of the control channel must be known. This knowledge may be
> > > >  manually configured or automatically discovered."
> > > >
> > > > and then you follow the procedure as described in this i-d (in
> > > > fact the bootstrap i-d also completes the second alternative of
> > > > the above sentence).
> > > >
> > > > hope this clarifies,
> > > > - dimitri.
> > > >
> > > > Carmine Daloia wrote:
> > > > >
> > > > > Dimitri,
> > > > >
> > > > > Thanks for the explanation for why it is left as a separate document.
> > > > >
> > > > > I disagree with one point.  You say that the bootstrap process would not
> > > > > cause anything in the lmp draft to be modified.
> > > > >
> > > > > Once the controll address of the neighbor is learned via the bootstrap
> > > > > process, I don't see the purpose for Control Channel Management
> > > > Procedure.
> > > > >
> > > > > A link summary message can be sent directly to the controll address
> > > > > learned via the bootstrap process.  Therefore I would have expected the
> > > > > Control Channel Management Procedure to be removed completely or at
> > > > > least made optional.
> > > > >
> > > > > Carmine
> > > > >
> > > > > Dimitri.Papadimitriou@alcatel.be wrote:
> > > > >
> > > > > >carmine,
> > > > > >
> > > > > >1) this has been proposed in order to keep going with content
> > > > > >that has been discussed since more than two years now (and has
> > > > > >not been modified by the below mentioned document),
> > > > > >
> > > > > >2) since the result of the process (and the information it allows
> > > > > >to discover) is at the end the same than the one obtained when
> > > > > >applying the test message procedure no subsequent mechanisms
> > > > > >are modified by the bootstrap approach
> > > > > >
> > > > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > > > >from the mailing list discussions) to be useful (up to now) for
> > > > > >sonet/sdh or more generally for "optical" environments only.
> > > > > >
> > > > > >thus i think this may justify the (good imho) idea to have two
> > > > > >separate documents (it results from the above points to be thus
> > > > > >also justified from an implementation viewpoint)
> > > > > >
> > > > > >thanks,
> > > > > >- dimitri.
> > > > > >
> > > > > >Carmine Daloia wrote:
> > > > > >
> > > > > >
> > > > > >>Why is the procedure described in the lmp-bootstrap draft not included
> > > > > >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> > > > > >>capability and therefore doesn't seem to make sense to have these in
> > > > > >>separate drafts.
> > > > > >>
> > > > > >>Carmine
> > > > > >>
> > > > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>Carmine,
> > > > > >>>
> > > > > >>>this is why i have previously mentioned in my response
> > > > > >>>that "a proposal has been made to bootstrap out-of-band
> > > > > >>>control channels and discover the interface_id mappings
> > > > > >>>(or associations) before establishing a control channel"
> > > > > >>>
> > > > > >>>see:
> > > > >
> > > > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > > >
> > > > > >>>
> > > > > >>>thus the problem you've indicated in the below message is
> > > > > >>>also addressed -
> > > > > >>>
> > > > > >>>so
> > > > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>operator provisioning) if the operator has previously provisioned the
> > > > > >>>>remote node addresses for each and every data link. "
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>may be now rephrased as
> > > > > >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>without any provisioning of the remote node addresses for each
> > > > > >>>>and every data link"
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>thanks,
> > > > > >>>- dimitri.
> > > > > >>>
> > > > > >>>Carmine Daloia wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>Kireeti, Dimitri,
> > > > > >>>>
> > > > > >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
> > > > the
> > > > > >>>>Link Connectivity Verification procedure (which is optional) may be
> > > > used
> > > > > >>>>to dynamically learn the id associations.  Is this what you mean by
> > > > LMP
> > > > > >>>>being able to *build* the mappings?  However this requires that an
> > > > > >>>>operator *PROVISION* for each and every data link the remote node
> > > > > >>>>address that the data link is terminated on.  Only with this
> > > > > >>>>provisioning will the local node know the address to send the
> > > > > >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e.,
> > > > reduce
> > > > > >>>>operator provisioning) if the operator has previously provisioned the
> > > > > >>>>remote node addresses for each and every data link.  Doesn't seem
> > > > like a
> > > > > >>>>useful capability.
> > > > > >>>>
> > > > > >>>>Carmine
> > > > > >>>>
> > > > > >>>>Kireeti Kompella wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>>Hi Carmine,
> > > > > >>>>>
> > > > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>So basically LMP is used to verify that the datalink id mappings
> > > > stored
> > > > > >>>>>>in the neighboring nodes match eachother.
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If
> > > > the
> > > > > >>>>>mappings were already stored, LMP could be used to verify them --
> > > > but
> > > > > >>>>>that is a secondary function.
> > > > > >>>>>
> > > > > >>>>>Kireeti (as a WG participant).
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 05:15:41 -0700
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0ED731FF@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Diego Caviglia <Diego.Caviglia@marconi.com>, bwijnen@lucent.com
Cc: "Maarten Vissers <mvissers" <mvissers@lucent.com>, ccamp@ops.ietf.org
Subject: RE: Summary of LMP implementation/deployment reports
Date: Wed, 4 Sep 2002 14:12:55 +0200 
MIME-Version: 1.0
Content-Type: text/plain

I was specifically referring to the stuff that Maarten was
listing, which (I guess) all seem to be sonet/sdh things?

Thanks,
Bert 

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: woensdag 4 september 2002 14:01
> To: bwijnen@lucent.com
> Cc: Maarten Vissers <mvissers; ccamp@ops.ietf.org
> Subject: RE: Summary of LMP implementation/deployment reports
> 
> 
> 
> Hi Bert,
>                   could you please point out where in my 
> e-mail there was a
> technology specific reference (apart from the sentence in brackets)?
> 
> Best regards,
> 
> Diego
> 
> 
> 
> 
> 
> "Wijnen, Bert (Bert)" <bwijnen@lucent.com> on 04/09/2002 13.43.21
> 
> To:   Maarten Vissers <mvissers@lucent.com>, Diego Caviglia
>       <Diego.Caviglia@marconi.com>
> cc:   "Dimitri.Papadimitriou" 
> <Dimitri.Papadimitriou@alcatel.be>, "Carmine
>       Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti"
>        <kireeti@juniper.net>, "Nik Langrind <nik" 
> <nik@equipecom.com>, "
>       Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
> 
> Subject:  RE: Summary of LMP implementation/deployment reports
> 
> 
> Guys... I have already strongly suggested that any technology specific
> stuff goes in a separate doc. Still need to check if and how this
> has been teken care of in the new revision.
> 
> But if any of the technology specific stuff listed below were to be
> accepted by the WG, I think it should be in a separate technology
> specific document, and NOT in the COMMON CONTROL LMP document.
> 
> And if this is optical technology specific, does it then belong in
> in CCAMP, or even in IETF or is it something to be done in another
> WG or in another organisation?
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: woensdag 4 september 2002 11:34
> > To: Diego Caviglia
> > Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> > <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> > Subject: Re: Summary of LMP implementation/deployment reports
> >
> >
> > Diego,
> >
> > Michiel and Greg proposed text for such section on neighbor
> > discovery in his lmp
> > update draft
> > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> > -update-00.txt
> > Refer to section 3 in this contribution.
> >
> > This proposal allows neighbor discovery at the
> > - STM-N level,
> > - STS/HOVC level,
> > - VT/LOVC level.
> >
> > I.e it can be used to discover:
> > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via
> > DWDM system)
> > - STM-N CTP - TTP neighbors
> > - STM-N CTP - CTP neighbors
> >     Note - STM-N CTP is located in a pre-OTN transparent
> > optical cross
> >            connect (do they still exist these days? :-( ), and in an
> >            OTN ODUk equipment's STM-N trib port interface.
> >
> > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N
> > interfaces
> >                         connected via non-ASON/GMPLS
> > SDH/SONET network)
> > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N
> > interface and SDH ADM)
> > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> >
> > - VT/LOVC TTP - TTP neighbors
> > - VT/LOVC CTP - TTP neighbors
> > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> >
> > It can be used for neighbor discovery in
> > - (simple) link (G.805: link connection) cases and
> > - serial-compound link (G.805: link connection) cases.
> >
> > This particularly important for the roll out of ASON/GMPLS
> > networks. In this
> > phase there will be many non-ASON/GMPLS SDH/SONET networks 
> which will
> > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC
> > [VT/LOVC] connections
> > is set up through such non-ASON/GMPLS SDH/SONET network as a
> > (serial-compound)
> > link bundle (G.805: (serial-compound) link), then the
> > ASON/GMPLS neighbors are
> > the last network element in the first ASON/GMPLS subnetwork
> > and the first
> > network element in the second ASON/GMPLS subnetwork. The
> > non-ASON/GMPLS
> > SDH/SONET network is now simply a part of the "data link"
> > between these two
> > network elements.
> >
> > The ASON/GMPLS SDH/SONET network elements are also
> > "transparent devices" (in the
> > sense of LMP section 5, par. 4) that do not "modify or
> > examine data in normal
> > operation". As such, the the last sentence in the text in
> > par. 5 of section 5 is
> > not correct.
> >
> >    LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> >    verification procedure it is assumed that the nodal
> >    architecture is designed so that messages can be sent and
> >    received over any data link. Note that this requirement is
> >    trivial for opaque devices since each data link is electrically
> >    terminated and processed before being forwarded to the next
> >    opaque device, but that in transparent devices this is an
> >    additional requirement."
> >
> > A SDH/SONET cross connect or ADM seems to be such "opaque
> > device", but doesn't
> > terminate the STS/HOVC or VT/LOVC "data link" that exists
> > between the two
> > ASON/GMPLS neighbors.
> >
> > Michiel and Greg's proposal support automatic discovery
> > between two neighbor
> > nodes that are either at the end of the same fiber, or at the
> > end of different
> > fibers (and have one or more "transparent devices" between
> > these fibers).
> >
> > Regards,
> >
> > Maarten
> > PS. as there seems to be no willingness to address
> > Michiel/Greg's proposal in
> > ccamp (is this a correct conclusion of the email
> > correspondence so far), it
> > seems waste of time for all to continue this discussion over
> > here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714.
> > The market then must
> > decide between LMP and G.7714.
> >
> > Diego Caviglia wrote:
> > >
> > > Hi Dimitri,
> > >                           is neighbor discovery in the
> > scope of LMP?  I
> > > suppose that it is.
> > >
> > > With  Nbr  discovery  I'm referring to the scenario where a
> > TNE is attached
> > > to, say 4, TNEs and doesn't know to which of these TNE its
> > TEs are attached
> > > to.
> > >
> > > Where is this discovery procedure described in the ID?
> > >
> > > This  seems  to  me  one  of  the  major  advantages  of
> > LMP (for sure more
> > > important  than  fault  management  which  in the transport
> > network is well
> > > covered  by  inherent  Sonet/SDH  capabilities)  so a
> > specific section that
> > > addresses neighbor discovery is needed, of course IMHO.
> > >
> > > Some time ago I posted a mail on this topic, here is the 
> reference:
> > >
> > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > >
> > > Again from my point of view a section that describes in
> > detail this feature
> > > is needed in the ID.
> > >
> > > Best regards,
> > >
> > >             Diego.
> > >
> > > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 
> 03/09/2002 22.06.43
> > >
> > > Sent by:  owner-ccamp@ops.ietf.org
> > >
> > > To:   Carmine Daloia <daloia@lucent.com>
> > > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> > >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" 
> <ccamp@ops.ietf.org>
> > >
> > > Subject:  Re: Summary of LMP implementation/deployment reports
> > >
> > > carmine,
> > >
> > > just to be sure here we are on the same level of understanding
> > > the bootstrap information that the receiver learn is the 
> equivalent
> > > of the one that you would normally provision, i refer you to the
> > > following sentence of the Section 3 (of
> > draft-ietf-ccamp-lmp-05.txt):
> > >
> > > "To establish a control channel, the destination IP address on the
> > >  far end of the control channel must be known. This 
> knowledge may be
> > >  manually configured or automatically discovered."
> > >
> > > and then you follow the procedure as described in this i-d (in
> > > fact the bootstrap i-d also completes the second alternative of
> > > the above sentence).
> > >
> > > hope this clarifies,
> > > - dimitri.
> > >
> > > Carmine Daloia wrote:
> > > >
> > > > Dimitri,
> > > >
> > > > Thanks for the explanation for why it is left as a
> > separate document.
> > > >
> > > > I disagree with one point.  You say that the bootstrap
> > process would not
> > > > cause anything in the lmp draft to be modified.
> > > >
> > > > Once the controll address of the neighbor is learned via
> > the bootstrap
> > > > process, I don't see the purpose for Control Channel Management
> > > Procedure.
> > > >
> > > > A link summary message can be sent directly to the
> > controll address
> > > > learned via the bootstrap process.  Therefore I would
> > have expected the
> > > > Control Channel Management Procedure to be removed
> > completely or at
> > > > least made optional.
> > > >
> > > > Carmine
> > > >
> > > > Dimitri.Papadimitriou@alcatel.be wrote:
> > > >
> > > > >carmine,
> > > > >
> > > > >1) this has been proposed in order to keep going with content
> > > > >that has been discussed since more than two years now (and has
> > > > >not been modified by the below mentioned document),
> > > > >
> > > > >2) since the result of the process (and the 
> information it allows
> > > > >to discover) is at the end the same than the one obtained when
> > > > >applying the test message procedure no subsequent mechanisms
> > > > >are modified by the bootstrap approach
> > > > >
> > > > >3) moreover, the bootstrap mechanisms have been 
> identified (this
> > > > >from the mailing list discussions) to be useful (up to now) for
> > > > >sonet/sdh or more generally for "optical" environments only.
> > > > >
> > > > >thus i think this may justify the (good imho) idea to have two
> > > > >separate documents (it results from the above points to be thus
> > > > >also justified from an implementation viewpoint)
> > > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Carmine Daloia wrote:
> > > > >
> > > > >
> > > > >>Why is the procedure described in the lmp-bootstrap
> > draft not included
> > > > >>in the lmp-draft?  Doesn't sound like lmp is complete
> > without this
> > > > >>capability and therefore doesn't seem to make sense to
> > have these in
> > > > >>separate drafts.
> > > > >>
> > > > >>Carmine
> > > > >>
> > > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Carmine,
> > > > >>>
> > > > >>>this is why i have previously mentioned in my response
> > > > >>>that "a proposal has been made to bootstrap out-of-band
> > > > >>>control channels and discover the interface_id mappings
> > > > >>>(or associations) before establishing a control channel"
> > > > >>>
> > > > >>>see:
> > > >
> > >
> > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> > otstrap-00.txt
> > >
> > > > >>>
> > > > >>>thus the problem you've indicated in the below message is
> > > > >>>also addressed -
> > > > >>>
> > > > >>>so
> > > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>operator provisioning) if the operator has previously
> > provisioned the
> > > > >>>>remote node addresses for each and every data link. "
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>may be now rephrased as
> > > > >>>" LMP can *build* the mappings (i.e., reduce operator
> > provisioning)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>without any provisioning of the remote node 
> addresses for each
> > > > >>>>and every data link"
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>thanks,
> > > > >>>- dimitri.
> > > > >>>
> > > > >>>Carmine Daloia wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>Kireeti, Dimitri,
> > > > >>>>
> > > > >>>>I realize that Section 5 in
> > draft-ietf-ccamp-lmp-05.txt states that
> > > the
> > > > >>>>Link Connectivity Verification procedure (which is
> > optional) may be
> > > used
> > > > >>>>to dynamically learn the id associations.  Is this
> > what you mean by
> > > LMP
> > > > >>>>being able to *build* the mappings?  However this
> > requires that an
> > > > >>>>operator *PROVISION* for each and every data link the
> > remote node
> > > > >>>>address that the data link is terminated on.  Only with this
> > > > >>>>provisioning will the local node know the address 
> to send the
> > > > >>>>BeginVerify message to.   So LMP can *build* the
> > mappings (i.e.,
> > > reduce
> > > > >>>>operator provisioning) if the operator has previously
> > provisioned the
> > > > >>>>remote node addresses for each and every data link.
> > Doesn't seem
> > > like a
> > > > >>>>useful capability.
> > > > >>>>
> > > > >>>>Carmine
> > > > >>>>
> > > > >>>>Kireeti Kompella wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>Hi Carmine,
> > > > >>>>>
> > > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>So basically LMP is used to verify that the
> > datalink id mappings
> > > stored
> > > > >>>>>>in the neighboring nodes match eachother.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>Actually, LMP is used to *build* the mappings, not
> > verify them.  If
> > > the
> > > > >>>>>mappings were already stored, LMP could be used to
> > verify them --
> > > but
> > > > >>>>>that is a secondary function.
> > > > >>>>>
> > > > >>>>>Kireeti (as a WG participant).
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : dimitri.papadimitriou@alcatel.be
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : dpapadimitriou@psg.com
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> > >          B-2018 Antwerpen, Belgium
> > > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
> >
> 
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 05:05:48 -0700
Subject: RE: Summary of LMP implementation/deployment reports
To: bwijnen@lucent.com
Cc: "Maarten Vissers <mvissers" <mvissers@lucent.com>, ccamp@ops.ietf.org
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Wed, 4 Sep 2002 14:00:51 +0200
Message-ID: <OFC1D4B325.0277C7EF-ONC1256C2A.00415C77@uk.marconicomms.com>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

Hi Bert,
                  could you please point out where in my e-mail there was a
technology specific reference (apart from the sentence in brackets)?

Best regards,

Diego





"Wijnen, Bert (Bert)" <bwijnen@lucent.com> on 04/09/2002 13.43.21

To:   Maarten Vissers <mvissers@lucent.com>, Diego Caviglia
      <Diego.Caviglia@marconi.com>
cc:   "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Carmine
      Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti"
       <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, "
      Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>

Subject:  RE: Summary of LMP implementation/deployment reports


Guys... I have already strongly suggested that any technology specific
stuff goes in a separate doc. Still need to check if and how this
has been teken care of in the new revision.

But if any of the technology specific stuff listed below were to be
accepted by the WG, I think it should be in a separate technology
specific document, and NOT in the COMMON CONTROL LMP document.

And if this is optical technology specific, does it then belong in
in CCAMP, or even in IETF or is it something to be done in another
WG or in another organisation?

Thanks,
Bert

> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: woensdag 4 september 2002 11:34
> To: Diego Caviglia
> Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> Subject: Re: Summary of LMP implementation/deployment reports
>
>
> Diego,
>
> Michiel and Greg proposed text for such section on neighbor
> discovery in his lmp
> update draft
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> -update-00.txt
> Refer to section 3 in this contribution.
>
> This proposal allows neighbor discovery at the
> - STM-N level,
> - STS/HOVC level,
> - VT/LOVC level.
>
> I.e it can be used to discover:
> - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via
> DWDM system)
> - STM-N CTP - TTP neighbors
> - STM-N CTP - CTP neighbors
>     Note - STM-N CTP is located in a pre-OTN transparent
> optical cross
>            connect (do they still exist these days? :-( ), and in an
>            OTN ODUk equipment's STM-N trib port interface.
>
> - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N
> interfaces
>                         connected via non-ASON/GMPLS
> SDH/SONET network)
> - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N
> interface and SDH ADM)
> - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
>
> - VT/LOVC TTP - TTP neighbors
> - VT/LOVC CTP - TTP neighbors
> - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
>
> It can be used for neighbor discovery in
> - (simple) link (G.805: link connection) cases and
> - serial-compound link (G.805: link connection) cases.
>
> This particularly important for the roll out of ASON/GMPLS
> networks. In this
> phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC
> [VT/LOVC] connections
> is set up through such non-ASON/GMPLS SDH/SONET network as a
> (serial-compound)
> link bundle (G.805: (serial-compound) link), then the
> ASON/GMPLS neighbors are
> the last network element in the first ASON/GMPLS subnetwork
> and the first
> network element in the second ASON/GMPLS subnetwork. The
> non-ASON/GMPLS
> SDH/SONET network is now simply a part of the "data link"
> between these two
> network elements.
>
> The ASON/GMPLS SDH/SONET network elements are also
> "transparent devices" (in the
> sense of LMP section 5, par. 4) that do not "modify or
> examine data in normal
> operation". As such, the the last sentence in the text in
> par. 5 of section 5 is
> not correct.
>
>    LMP, v0.5, section 5, par. 5: "Furthermore, for the link
>    verification procedure it is assumed that the nodal
>    architecture is designed so that messages can be sent and
>    received over any data link. Note that this requirement is
>    trivial for opaque devices since each data link is electrically
>    terminated and processed before being forwarded to the next
>    opaque device, but that in transparent devices this is an
>    additional requirement."
>
> A SDH/SONET cross connect or ADM seems to be such "opaque
> device", but doesn't
> terminate the STS/HOVC or VT/LOVC "data link" that exists
> between the two
> ASON/GMPLS neighbors.
>
> Michiel and Greg's proposal support automatic discovery
> between two neighbor
> nodes that are either at the end of the same fiber, or at the
> end of different
> fibers (and have one or more "transparent devices" between
> these fibers).
>
> Regards,
>
> Maarten
> PS. as there seems to be no willingness to address
> Michiel/Greg's proposal in
> ccamp (is this a correct conclusion of the email
> correspondence so far), it
> seems waste of time for all to continue this discussion over
> here. Let's
> concentrate this work in Q.14/15 and include it in G.7714.
> The market then must
> decide between LMP and G.7714.
>
> Diego Caviglia wrote:
> >
> > Hi Dimitri,
> >                           is neighbor discovery in the
> scope of LMP?  I
> > suppose that it is.
> >
> > With  Nbr  discovery  I'm referring to the scenario where a
> TNE is attached
> > to, say 4, TNEs and doesn't know to which of these TNE its
> TEs are attached
> > to.
> >
> > Where is this discovery procedure described in the ID?
> >
> > This  seems  to  me  one  of  the  major  advantages  of
> LMP (for sure more
> > important  than  fault  management  which  in the transport
> network is well
> > covered  by  inherent  Sonet/SDH  capabilities)  so a
> specific section that
> > addresses neighbor discovery is needed, of course IMHO.
> >
> > Some time ago I posted a mail on this topic, here is the reference:
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> >
> > Again from my point of view a section that describes in
> detail this feature
> > is needed in the ID.
> >
> > Best regards,
> >
> >             Diego.
> >
> > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> >
> > Sent by:  owner-ccamp@ops.ietf.org
> >
> > To:   Carmine Daloia <daloia@lucent.com>
> > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> >
> > Subject:  Re: Summary of LMP implementation/deployment reports
> >
> > carmine,
> >
> > just to be sure here we are on the same level of understanding
> > the bootstrap information that the receiver learn is the equivalent
> > of the one that you would normally provision, i refer you to the
> > following sentence of the Section 3 (of
> draft-ietf-ccamp-lmp-05.txt):
> >
> > "To establish a control channel, the destination IP address on the
> >  far end of the control channel must be known. This knowledge may be
> >  manually configured or automatically discovered."
> >
> > and then you follow the procedure as described in this i-d (in
> > fact the bootstrap i-d also completes the second alternative of
> > the above sentence).
> >
> > hope this clarifies,
> > - dimitri.
> >
> > Carmine Daloia wrote:
> > >
> > > Dimitri,
> > >
> > > Thanks for the explanation for why it is left as a
> separate document.
> > >
> > > I disagree with one point.  You say that the bootstrap
> process would not
> > > cause anything in the lmp draft to be modified.
> > >
> > > Once the controll address of the neighbor is learned via
> the bootstrap
> > > process, I don't see the purpose for Control Channel Management
> > Procedure.
> > >
> > > A link summary message can be sent directly to the
> controll address
> > > learned via the bootstrap process.  Therefore I would
> have expected the
> > > Control Channel Management Procedure to be removed
> completely or at
> > > least made optional.
> > >
> > > Carmine
> > >
> > > Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > >carmine,
> > > >
> > > >1) this has been proposed in order to keep going with content
> > > >that has been discussed since more than two years now (and has
> > > >not been modified by the below mentioned document),
> > > >
> > > >2) since the result of the process (and the information it allows
> > > >to discover) is at the end the same than the one obtained when
> > > >applying the test message procedure no subsequent mechanisms
> > > >are modified by the bootstrap approach
> > > >
> > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > >from the mailing list discussions) to be useful (up to now) for
> > > >sonet/sdh or more generally for "optical" environments only.
> > > >
> > > >thus i think this may justify the (good imho) idea to have two
> > > >separate documents (it results from the above points to be thus
> > > >also justified from an implementation viewpoint)
> > > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Carmine Daloia wrote:
> > > >
> > > >
> > > >>Why is the procedure described in the lmp-bootstrap
> draft not included
> > > >>in the lmp-draft?  Doesn't sound like lmp is complete
> without this
> > > >>capability and therefore doesn't seem to make sense to
> have these in
> > > >>separate drafts.
> > > >>
> > > >>Carmine
> > > >>
> > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Carmine,
> > > >>>
> > > >>>this is why i have previously mentioned in my response
> > > >>>that "a proposal has been made to bootstrap out-of-band
> > > >>>control channels and discover the interface_id mappings
> > > >>>(or associations) before establishing a control channel"
> > > >>>
> > > >>>see:
> > >
> >
> >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> otstrap-00.txt
> >
> > > >>>
> > > >>>thus the problem you've indicated in the below message is
> > > >>>also addressed -
> > > >>>
> > > >>>so
> > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>operator provisioning) if the operator has previously
> provisioned the
> > > >>>>remote node addresses for each and every data link. "
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>may be now rephrased as
> > > >>>" LMP can *build* the mappings (i.e., reduce operator
> provisioning)
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>without any provisioning of the remote node addresses for each
> > > >>>>and every data link"
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>thanks,
> > > >>>- dimitri.
> > > >>>
> > > >>>Carmine Daloia wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Kireeti, Dimitri,
> > > >>>>
> > > >>>>I realize that Section 5 in
> draft-ietf-ccamp-lmp-05.txt states that
> > the
> > > >>>>Link Connectivity Verification procedure (which is
> optional) may be
> > used
> > > >>>>to dynamically learn the id associations.  Is this
> what you mean by
> > LMP
> > > >>>>being able to *build* the mappings?  However this
> requires that an
> > > >>>>operator *PROVISION* for each and every data link the
> remote node
> > > >>>>address that the data link is terminated on.  Only with this
> > > >>>>provisioning will the local node know the address to send the
> > > >>>>BeginVerify message to.   So LMP can *build* the
> mappings (i.e.,
> > reduce
> > > >>>>operator provisioning) if the operator has previously
> provisioned the
> > > >>>>remote node addresses for each and every data link.
> Doesn't seem
> > like a
> > > >>>>useful capability.
> > > >>>>
> > > >>>>Carmine
> > > >>>>
> > > >>>>Kireeti Kompella wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Hi Carmine,
> > > >>>>>
> > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>So basically LMP is used to verify that the
> datalink id mappings
> > stored
> > > >>>>>>in the neighboring nodes match eachother.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Actually, LMP is used to *build* the mappings, not
> verify them.  If
> > the
> > > >>>>>mappings were already stored, LMP could be used to
> verify them --
> > but
> > > >>>>>that is a secondary function.
> > > >>>>>
> > > >>>>>Kireeti (as a WG participant).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : dpapadimitriou@psg.com
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
>







Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 04:59:48 -0700
Message-Id: <200209041155.HAA23195@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-03.txt
Date: Wed, 04 Sep 2002 07:55:21 -0400

--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		: Generalized Multi-Protocol Label Switching (GMPLS) 
                          Architecture
	Author(s)	: E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-architecture-03.txt
	Pages		: 58
	Date		: 2002-9-3
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-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-gmpls-architecture-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-3150800.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-03.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-3150800.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 04:59:23 -0700
Message-Id: <200209041155.HAA23212@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
Date: Wed, 04 Sep 2002 07:55:26 -0400

--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		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-ietf-ccamp-tracereq-00.txt
	Pages		: 0
	Date		: 2002-9-3
	
This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support the generic route-tracing application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-00.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-tracereq-00.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-3150816.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-tracereq-00.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-3150816.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 04:58:51 -0700
Message-ID: <3D75F4FE.F623A657@lucent.com>
Date: Wed, 04 Sep 2002 07:56:46 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies ,  Optical Networking Group, MV
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

Dimitri,

Following what you said, are you also proposing we should take technology
specific stuff from the current LMP draft? Then I agree with you.

Thanks,

Yangguang

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> maarten, diego,
> 
> the question of diego is "... a section that describes in
> detail this feature (dixit neighbor discovery) is needed
> in the ID." and the response is such description should
> be imho in an applicability statement i-d (describing the
> use of the lmp features), neighbor discovery as proposed
> in your response is focusing on "sdh/sonet" environments
> while as discussed many times lmp targeted more and the
> community implements more - this is also clear from the
> results of the implementation/deployment reports - i refer
> you to the e-mail of kireeti (for more on hourglass):
> 
> http://psg.com/lists/ccamp/ccamp.2002/msg01005.html
> 
> further a dedicated i-d will address the specifics of
> "sdh/sonet" environments that's from a practical viewpoint
> the best way to proceed in order to keep a consistent/
> modular approach while for the bootstrap i-d the valuable
> comments as received since so far will also be addressed
> - thus since so far all this should address the main
> concerns of our community -
> 
> note also that in general such applicability i-d starts
> when most of the protocol details are known.
> 
> your last point is also interesting - ditto:
> "> PS. as there seems to be no willingness to address Michiel/Greg's
> proposal in
> > ccamp (is this a correct conclusion of the email correspondence so far), it
> > seems waste of time for all to continue this discussion over here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714."
> 
> first our community does not stricto sensu address proposals
> (or i-ds) but consented items and corresponding solutions/
> mechanisms in several levels of documents - the document is
> a way to achieve interoperable running code not the ultimate
> final goal in itself.
> 
> but then:
> > The market then must decide between LMP and G.7714."
> 
> the response is imho related to last question in the greg's
> e-mail (http://psg.com/lists/ccamp/ccamp.2002/msg01092.html):
> 
> "> (c) Of the implementations that Bert listed, how many were being used
> just
> > for OIF UNI 1.0 discovery (SONET/SDH) interoperability rather than general
> > LMP?"
> 
> well the response is indicated in the bert's report:
> 
> "One implementation was O-UNI version of LMP, so does not do
> all the things described in current LMP draft."
> 
> but i also think that it means more, it means that the ccamp
> community majority is implementing the complete protocol and
> not only its set of functions for sonet/sdh in a oif uni
> context -> therefore may we not expect here the same kind of
> response in the ason context (debate is open) what are the
> rationale for a vendor to implement a version of lmp per
> environment ? what will happen when this protocol will be
> used in multi-service devices ? imho a practical view on
> this problem gives many responses and insight for the future
> but in any case i am not sure that some parts of you post-
> scriptum are really in-line with the way of thinking of our
> community (which i don't think targets any competition)
> 
> thanks
> - dimitri.
> 
> Maarten Vissers wrote:
> >
> > Diego,
> >
> > Michiel and Greg proposed text for such section on neighbor discovery in his lmp
> > update draft
> > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
> > Refer to section 3 in this contribution.
> >
> > This proposal allows neighbor discovery at the
> > - STM-N level,
> > - STS/HOVC level,
> > - VT/LOVC level.
> >
> > I.e it can be used to discover:
> > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via DWDM system)
> > - STM-N CTP - TTP neighbors
> > - STM-N CTP - CTP neighbors
> >     Note - STM-N CTP is located in a pre-OTN transparent optical cross
> >            connect (do they still exist these days? :-( ), and in an
> >            OTN ODUk equipment's STM-N trib port interface.
> >
> > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N interfaces
> >                         connected via non-ASON/GMPLS SDH/SONET network)
> > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N interface and SDH ADM)
> > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> >
> > - VT/LOVC TTP - TTP neighbors
> > - VT/LOVC CTP - TTP neighbors
> > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> >
> > It can be used for neighbor discovery in
> > - (simple) link (G.805: link connection) cases and
> > - serial-compound link (G.805: link connection) cases.
> >
> > This particularly important for the roll out of ASON/GMPLS networks. In this
> > phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC [VT/LOVC] connections
> > is set up through such non-ASON/GMPLS SDH/SONET network as a (serial-compound)
> > link bundle (G.805: (serial-compound) link), then the ASON/GMPLS neighbors are
> > the last network element in the first ASON/GMPLS subnetwork and the first
> > network element in the second ASON/GMPLS subnetwork. The non-ASON/GMPLS
> > SDH/SONET network is now simply a part of the "data link" between these two
> > network elements.
> >
> > The ASON/GMPLS SDH/SONET network elements are also "transparent devices" (in the
> > sense of LMP section 5, par. 4) that do not "modify or examine data in normal
> > operation". As such, the the last sentence in the text in par. 5 of section 5 is
> > not correct.
> >
> >         LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> >         verification procedure it is assumed that the nodal
> >         architecture is designed so that messages can be sent and
> >         received over any data link. Note that this requirement is
> >         trivial for opaque devices since each data link is electrically
> >         terminated and processed before being forwarded to the next
> >         opaque device, but that in transparent devices this is an
> >         additional requirement."
> >
> > A SDH/SONET cross connect or ADM seems to be such "opaque device", but doesn't
> > terminate the STS/HOVC or VT/LOVC "data link" that exists between the two
> > ASON/GMPLS neighbors.
> >
> > Michiel and Greg's proposal support automatic discovery between two neighbor
> > nodes that are either at the end of the same fiber, or at the end of different
> > fibers (and have one or more "transparent devices" between these fibers).
> >
> > Regards,
> >
> > Maarten
> > PS. as there seems to be no willingness to address Michiel/Greg's proposal in
> > ccamp (is this a correct conclusion of the email correspondence so far), it
> > seems waste of time for all to continue this discussion over here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714. The market then must
> > decide between LMP and G.7714.
> >
> > Diego Caviglia wrote:
> > >
> > > Hi Dimitri,
> > >                           is neighbor discovery in the scope of LMP?  I
> > > suppose that it is.
> > >
> > > With  Nbr  discovery  I'm referring to the scenario where a TNE is attached
> > > to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
> > > to.
> > >
> > > Where is this discovery procedure described in the ID?
> > >
> > > This  seems  to  me  one  of  the  major  advantages  of LMP (for sure more
> > > important  than  fault  management  which  in the transport network is well
> > > covered  by  inherent  Sonet/SDH  capabilities)  so a specific section that
> > > addresses neighbor discovery is needed, of course IMHO.
> > >
> > > Some time ago I posted a mail on this topic, here is the reference:
> > >
> > > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > >
> > > Again from my point of view a section that describes in detail this feature
> > > is needed in the ID.
> > >
> > > Best regards,
> > >
> > >             Diego.
> > >
> > > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> > >
> > > Sent by:  owner-ccamp@ops.ietf.org
> > >
> > > To:   Carmine Daloia <daloia@lucent.com>
> > > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> > >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > >
> > > Subject:  Re: Summary of LMP implementation/deployment reports
> > >
> > > carmine,
> > >
> > > just to be sure here we are on the same level of understanding
> > > the bootstrap information that the receiver learn is the equivalent
> > > of the one that you would normally provision, i refer you to the
> > > following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):
> > >
> > > "To establish a control channel, the destination IP address on the
> > >  far end of the control channel must be known. This knowledge may be
> > >  manually configured or automatically discovered."
> > >
> > > and then you follow the procedure as described in this i-d (in
> > > fact the bootstrap i-d also completes the second alternative of
> > > the above sentence).
> > >
> > > hope this clarifies,
> > > - dimitri.
> > >
> > > Carmine Daloia wrote:
> > > >
> > > > Dimitri,
> > > >
> > > > Thanks for the explanation for why it is left as a separate document.
> > > >
> > > > I disagree with one point.  You say that the bootstrap process would not
> > > > cause anything in the lmp draft to be modified.
> > > >
> > > > Once the controll address of the neighbor is learned via the bootstrap
> > > > process, I don't see the purpose for Control Channel Management
> > > Procedure.
> > > >
> > > > A link summary message can be sent directly to the controll address
> > > > learned via the bootstrap process.  Therefore I would have expected the
> > > > Control Channel Management Procedure to be removed completely or at
> > > > least made optional.
> > > >
> > > > Carmine
> > > >
> > > > Dimitri.Papadimitriou@alcatel.be wrote:
> > > >
> > > > >carmine,
> > > > >
> > > > >1) this has been proposed in order to keep going with content
> > > > >that has been discussed since more than two years now (and has
> > > > >not been modified by the below mentioned document),
> > > > >
> > > > >2) since the result of the process (and the information it allows
> > > > >to discover) is at the end the same than the one obtained when
> > > > >applying the test message procedure no subsequent mechanisms
> > > > >are modified by the bootstrap approach
> > > > >
> > > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > > >from the mailing list discussions) to be useful (up to now) for
> > > > >sonet/sdh or more generally for "optical" environments only.
> > > > >
> > > > >thus i think this may justify the (good imho) idea to have two
> > > > >separate documents (it results from the above points to be thus
> > > > >also justified from an implementation viewpoint)
> > > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Carmine Daloia wrote:
> > > > >
> > > > >
> > > > >>Why is the procedure described in the lmp-bootstrap draft not included
> > > > >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> > > > >>capability and therefore doesn't seem to make sense to have these in
> > > > >>separate drafts.
> > > > >>
> > > > >>Carmine
> > > > >>
> > > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Carmine,
> > > > >>>
> > > > >>>this is why i have previously mentioned in my response
> > > > >>>that "a proposal has been made to bootstrap out-of-band
> > > > >>>control channels and discover the interface_id mappings
> > > > >>>(or associations) before establishing a control channel"
> > > > >>>
> > > > >>>see:
> > > >
> > > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > >
> > > > >>>
> > > > >>>thus the problem you've indicated in the below message is
> > > > >>>also addressed -
> > > > >>>
> > > > >>>so
> > > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>operator provisioning) if the operator has previously provisioned the
> > > > >>>>remote node addresses for each and every data link. "
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>may be now rephrased as
> > > > >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>without any provisioning of the remote node addresses for each
> > > > >>>>and every data link"
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>thanks,
> > > > >>>- dimitri.
> > > > >>>
> > > > >>>Carmine Daloia wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>Kireeti, Dimitri,
> > > > >>>>
> > > > >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
> > > the
> > > > >>>>Link Connectivity Verification procedure (which is optional) may be
> > > used
> > > > >>>>to dynamically learn the id associations.  Is this what you mean by
> > > LMP
> > > > >>>>being able to *build* the mappings?  However this requires that an
> > > > >>>>operator *PROVISION* for each and every data link the remote node
> > > > >>>>address that the data link is terminated on.  Only with this
> > > > >>>>provisioning will the local node know the address to send the
> > > > >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e.,
> > > reduce
> > > > >>>>operator provisioning) if the operator has previously provisioned the
> > > > >>>>remote node addresses for each and every data link.  Doesn't seem
> > > like a
> > > > >>>>useful capability.
> > > > >>>>
> > > > >>>>Carmine
> > > > >>>>
> > > > >>>>Kireeti Kompella wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>Hi Carmine,
> > > > >>>>>
> > > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>So basically LMP is used to verify that the datalink id mappings
> > > stored
> > > > >>>>>>in the neighboring nodes match eachother.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If
> > > the
> > > > >>>>>mappings were already stored, LMP could be used to verify them --
> > > but
> > > > >>>>>that is a secondary function.
> > > > >>>>>
> > > > >>>>>Kireeti (as a WG participant).
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>
> > > > >>>
> > > > >>>



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 04:48:58 -0700
Message-ID: <3D75F323.AC2A5682@alcatel.be>
Date: Wed, 04 Sep 2002 13:48:51 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Maarten Vissers <mvissers@lucent.com>
Cc: Diego Caviglia <Diego.Caviglia@marconi.com>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

maarten, diego,

the question of diego is "... a section that describes in 
detail this feature (dixit neighbor discovery) is needed 
in the ID." and the response is such description should
be imho in an applicability statement i-d (describing the
use of the lmp features), neighbor discovery as proposed
in your response is focusing on "sdh/sonet" environments
while as discussed many times lmp targeted more and the
community implements more - this is also clear from the 
results of the implementation/deployment reports - i refer 
you to the e-mail of kireeti (for more on hourglass):

http://psg.com/lists/ccamp/ccamp.2002/msg01005.html

further a dedicated i-d will address the specifics of 
"sdh/sonet" environments that's from a practical viewpoint 
the best way to proceed in order to keep a consistent/
modular approach while for the bootstrap i-d the valuable 
comments as received since so far will also be addressed 
- thus since so far all this should address the main 
concerns of our community -

note also that in general such applicability i-d starts
when most of the protocol details are known.

your last point is also interesting - ditto:
"> PS. as there seems to be no willingness to address Michiel/Greg's
proposal in
> ccamp (is this a correct conclusion of the email correspondence so far), it
> seems waste of time for all to continue this discussion over here. Let's
> concentrate this work in Q.14/15 and include it in G.7714." 

first our community does not stricto sensu address proposals
(or i-ds) but consented items and corresponding solutions/
mechanisms in several levels of documents - the document is
a way to achieve interoperable running code not the ultimate
final goal in itself.

but then:
> The market then must decide between LMP and G.7714."

the response is imho related to last question in the greg's
e-mail (http://psg.com/lists/ccamp/ccamp.2002/msg01092.html):

"> (c) Of the implementations that Bert listed, how many were being used
just
> for OIF UNI 1.0 discovery (SONET/SDH) interoperability rather than general
> LMP?"

well the response is indicated in the bert's report:

"One implementation was O-UNI version of LMP, so does not do
all the things described in current LMP draft."

but i also think that it means more, it means that the ccamp 
community majority is implementing the complete protocol and 
not only its set of functions for sonet/sdh in a oif uni 
context -> therefore may we not expect here the same kind of 
response in the ason context (debate is open) what are the
rationale for a vendor to implement a version of lmp per
environment ? what will happen when this protocol will be
used in multi-service devices ? imho a practical view on
this problem gives many responses and insight for the future 
but in any case i am not sure that some parts of you post-
scriptum are really in-line with the way of thinking of our 
community (which i don't think targets any competition)

thanks
- dimitri.

Maarten Vissers wrote:
> 
> Diego,
> 
> Michiel and Greg proposed text for such section on neighbor discovery in his lmp
> update draft
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
> Refer to section 3 in this contribution.
> 
> This proposal allows neighbor discovery at the
> - STM-N level,
> - STS/HOVC level,
> - VT/LOVC level.
> 
> I.e it can be used to discover:
> - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via DWDM system)
> - STM-N CTP - TTP neighbors
> - STM-N CTP - CTP neighbors
>     Note - STM-N CTP is located in a pre-OTN transparent optical cross
>            connect (do they still exist these days? :-( ), and in an
>            OTN ODUk equipment's STM-N trib port interface.
> 
> - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N interfaces
>                         connected via non-ASON/GMPLS SDH/SONET network)
> - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N interface and SDH ADM)
> - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> 
> - VT/LOVC TTP - TTP neighbors
> - VT/LOVC CTP - TTP neighbors
> - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> 
> It can be used for neighbor discovery in
> - (simple) link (G.805: link connection) cases and
> - serial-compound link (G.805: link connection) cases.
> 
> This particularly important for the roll out of ASON/GMPLS networks. In this
> phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC [VT/LOVC] connections
> is set up through such non-ASON/GMPLS SDH/SONET network as a (serial-compound)
> link bundle (G.805: (serial-compound) link), then the ASON/GMPLS neighbors are
> the last network element in the first ASON/GMPLS subnetwork and the first
> network element in the second ASON/GMPLS subnetwork. The non-ASON/GMPLS
> SDH/SONET network is now simply a part of the "data link" between these two
> network elements.
> 
> The ASON/GMPLS SDH/SONET network elements are also "transparent devices" (in the
> sense of LMP section 5, par. 4) that do not "modify or examine data in normal
> operation". As such, the the last sentence in the text in par. 5 of section 5 is
> not correct.
> 
>         LMP, v0.5, section 5, par. 5: "Furthermore, for the link
>         verification procedure it is assumed that the nodal
>         architecture is designed so that messages can be sent and
>         received over any data link. Note that this requirement is
>         trivial for opaque devices since each data link is electrically
>         terminated and processed before being forwarded to the next
>         opaque device, but that in transparent devices this is an
>         additional requirement."
> 
> A SDH/SONET cross connect or ADM seems to be such "opaque device", but doesn't
> terminate the STS/HOVC or VT/LOVC "data link" that exists between the two
> ASON/GMPLS neighbors.
> 
> Michiel and Greg's proposal support automatic discovery between two neighbor
> nodes that are either at the end of the same fiber, or at the end of different
> fibers (and have one or more "transparent devices" between these fibers).
> 
> Regards,
> 
> Maarten
> PS. as there seems to be no willingness to address Michiel/Greg's proposal in
> ccamp (is this a correct conclusion of the email correspondence so far), it
> seems waste of time for all to continue this discussion over here. Let's
> concentrate this work in Q.14/15 and include it in G.7714. The market then must
> decide between LMP and G.7714.
> 
> Diego Caviglia wrote:
> >
> > Hi Dimitri,
> >                           is neighbor discovery in the scope of LMP?  I
> > suppose that it is.
> >
> > With  Nbr  discovery  I'm referring to the scenario where a TNE is attached
> > to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
> > to.
> >
> > Where is this discovery procedure described in the ID?
> >
> > This  seems  to  me  one  of  the  major  advantages  of LMP (for sure more
> > important  than  fault  management  which  in the transport network is well
> > covered  by  inherent  Sonet/SDH  capabilities)  so a specific section that
> > addresses neighbor discovery is needed, of course IMHO.
> >
> > Some time ago I posted a mail on this topic, here is the reference:
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> >
> > Again from my point of view a section that describes in detail this feature
> > is needed in the ID.
> >
> > Best regards,
> >
> >             Diego.
> >
> > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> >
> > Sent by:  owner-ccamp@ops.ietf.org
> >
> > To:   Carmine Daloia <daloia@lucent.com>
> > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> >
> > Subject:  Re: Summary of LMP implementation/deployment reports
> >
> > carmine,
> >
> > just to be sure here we are on the same level of understanding
> > the bootstrap information that the receiver learn is the equivalent
> > of the one that you would normally provision, i refer you to the
> > following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):
> >
> > "To establish a control channel, the destination IP address on the
> >  far end of the control channel must be known. This knowledge may be
> >  manually configured or automatically discovered."
> >
> > and then you follow the procedure as described in this i-d (in
> > fact the bootstrap i-d also completes the second alternative of
> > the above sentence).
> >
> > hope this clarifies,
> > - dimitri.
> >
> > Carmine Daloia wrote:
> > >
> > > Dimitri,
> > >
> > > Thanks for the explanation for why it is left as a separate document.
> > >
> > > I disagree with one point.  You say that the bootstrap process would not
> > > cause anything in the lmp draft to be modified.
> > >
> > > Once the controll address of the neighbor is learned via the bootstrap
> > > process, I don't see the purpose for Control Channel Management
> > Procedure.
> > >
> > > A link summary message can be sent directly to the controll address
> > > learned via the bootstrap process.  Therefore I would have expected the
> > > Control Channel Management Procedure to be removed completely or at
> > > least made optional.
> > >
> > > Carmine
> > >
> > > Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > >carmine,
> > > >
> > > >1) this has been proposed in order to keep going with content
> > > >that has been discussed since more than two years now (and has
> > > >not been modified by the below mentioned document),
> > > >
> > > >2) since the result of the process (and the information it allows
> > > >to discover) is at the end the same than the one obtained when
> > > >applying the test message procedure no subsequent mechanisms
> > > >are modified by the bootstrap approach
> > > >
> > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > >from the mailing list discussions) to be useful (up to now) for
> > > >sonet/sdh or more generally for "optical" environments only.
> > > >
> > > >thus i think this may justify the (good imho) idea to have two
> > > >separate documents (it results from the above points to be thus
> > > >also justified from an implementation viewpoint)
> > > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Carmine Daloia wrote:
> > > >
> > > >
> > > >>Why is the procedure described in the lmp-bootstrap draft not included
> > > >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> > > >>capability and therefore doesn't seem to make sense to have these in
> > > >>separate drafts.
> > > >>
> > > >>Carmine
> > > >>
> > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Carmine,
> > > >>>
> > > >>>this is why i have previously mentioned in my response
> > > >>>that "a proposal has been made to bootstrap out-of-band
> > > >>>control channels and discover the interface_id mappings
> > > >>>(or associations) before establishing a control channel"
> > > >>>
> > > >>>see:
> > >
> > >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> >
> > > >>>
> > > >>>thus the problem you've indicated in the below message is
> > > >>>also addressed -
> > > >>>
> > > >>>so
> > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>operator provisioning) if the operator has previously provisioned the
> > > >>>>remote node addresses for each and every data link. "
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>may be now rephrased as
> > > >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>without any provisioning of the remote node addresses for each
> > > >>>>and every data link"
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>thanks,
> > > >>>- dimitri.
> > > >>>
> > > >>>Carmine Daloia wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Kireeti, Dimitri,
> > > >>>>
> > > >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
> > the
> > > >>>>Link Connectivity Verification procedure (which is optional) may be
> > used
> > > >>>>to dynamically learn the id associations.  Is this what you mean by
> > LMP
> > > >>>>being able to *build* the mappings?  However this requires that an
> > > >>>>operator *PROVISION* for each and every data link the remote node
> > > >>>>address that the data link is terminated on.  Only with this
> > > >>>>provisioning will the local node know the address to send the
> > > >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e.,
> > reduce
> > > >>>>operator provisioning) if the operator has previously provisioned the
> > > >>>>remote node addresses for each and every data link.  Doesn't seem
> > like a
> > > >>>>useful capability.
> > > >>>>
> > > >>>>Carmine
> > > >>>>
> > > >>>>Kireeti Kompella wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Hi Carmine,
> > > >>>>>
> > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>So basically LMP is used to verify that the datalink id mappings
> > stored
> > > >>>>>>in the neighboring nodes match eachother.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If
> > the
> > > >>>>>mappings were already stored, LMP could be used to verify them --
> > but
> > > >>>>>that is a secondary function.
> > > >>>>>
> > > >>>>>Kireeti (as a WG participant).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 04:46:41 -0700
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0ED731A7@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia <Diego.Caviglia@marconi.com>
Cc: "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Wed, 4 Sep 2002 13:43:21 +0200 
MIME-Version: 1.0
Content-Type: text/plain

Guys... I have already strongly suggested that any technology specific
stuff goes in a separate doc. Still need to check if and how this
has been teken care of in the new revision.

But if any of the technology specific stuff listed below were to be
accepted by the WG, I think it should be in a separate technology
specific document, and NOT in the COMMON CONTROL LMP document.

And if this is optical technology specific, does it then belong in
in CCAMP, or even in IETF or is it something to be done in another
WG or in another organisation?

Thanks,
Bert 

> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: woensdag 4 september 2002 11:34
> To: Diego Caviglia
> Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Diego,
> 
> Michiel and Greg proposed text for such section on neighbor 
> discovery in his lmp
> update draft
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> -update-00.txt
> Refer to section 3 in this contribution.
> 
> This proposal allows neighbor discovery at the 
> - STM-N level,
> - STS/HOVC level,
> - VT/LOVC level.
> 
> I.e it can be used to discover:
> - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via 
> DWDM system)
> - STM-N CTP - TTP neighbors 
> - STM-N CTP - CTP neighbors 
>     Note - STM-N CTP is located in a pre-OTN transparent 
> optical cross 
>            connect (do they still exist these days? :-( ), and in an 
>            OTN ODUk equipment's STM-N trib port interface.
> 
> - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N 
> interfaces 
>                         connected via non-ASON/GMPLS 
> SDH/SONET network)
> - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N 
> interface and SDH ADM)
> - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> 
> - VT/LOVC TTP - TTP neighbors
> - VT/LOVC CTP - TTP neighbors
> - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> 
> It can be used for neighbor discovery in 
> - (simple) link (G.805: link connection) cases and
> - serial-compound link (G.805: link connection) cases.
> 
> This particularly important for the roll out of ASON/GMPLS 
> networks. In this
> phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC 
> [VT/LOVC] connections
> is set up through such non-ASON/GMPLS SDH/SONET network as a 
> (serial-compound)
> link bundle (G.805: (serial-compound) link), then the 
> ASON/GMPLS neighbors are
> the last network element in the first ASON/GMPLS subnetwork 
> and the first
> network element in the second ASON/GMPLS subnetwork. The 
> non-ASON/GMPLS
> SDH/SONET network is now simply a part of the "data link" 
> between these two
> network elements. 
> 
> The ASON/GMPLS SDH/SONET network elements are also 
> "transparent devices" (in the
> sense of LMP section 5, par. 4) that do not "modify or 
> examine data in normal
> operation". As such, the the last sentence in the text in 
> par. 5 of section 5 is
> not correct.
> 
> 	LMP, v0.5, section 5, par. 5: "Furthermore, for the link 
> 	verification procedure it is assumed that the nodal 
> 	architecture is designed so that messages can be sent and
> 	received over any data link. Note that this requirement is 
> 	trivial for opaque devices since each data link is electrically
> 	terminated and processed before being forwarded to the next
> 	opaque device, but that in transparent devices this is an
> 	additional requirement."
> 
> A SDH/SONET cross connect or ADM seems to be such "opaque 
> device", but doesn't
> terminate the STS/HOVC or VT/LOVC "data link" that exists 
> between the two
> ASON/GMPLS neighbors.
> 
> Michiel and Greg's proposal support automatic discovery 
> between two neighbor
> nodes that are either at the end of the same fiber, or at the 
> end of different
> fibers (and have one or more "transparent devices" between 
> these fibers).
> 
> Regards,
> 
> Maarten
> PS. as there seems to be no willingness to address 
> Michiel/Greg's proposal in
> ccamp (is this a correct conclusion of the email 
> correspondence so far), it
> seems waste of time for all to continue this discussion over 
> here. Let's
> concentrate this work in Q.14/15 and include it in G.7714. 
> The market then must
> decide between LMP and G.7714.
> 
> Diego Caviglia wrote:
> > 
> > Hi Dimitri,
> >                           is neighbor discovery in the 
> scope of LMP?  I
> > suppose that it is.
> > 
> > With  Nbr  discovery  I'm referring to the scenario where a 
> TNE is attached
> > to, say 4, TNEs and doesn't know to which of these TNE its 
> TEs are attached
> > to.
> > 
> > Where is this discovery procedure described in the ID?
> > 
> > This  seems  to  me  one  of  the  major  advantages  of 
> LMP (for sure more
> > important  than  fault  management  which  in the transport 
> network is well
> > covered  by  inherent  Sonet/SDH  capabilities)  so a 
> specific section that
> > addresses neighbor discovery is needed, of course IMHO.
> > 
> > Some time ago I posted a mail on this topic, here is the reference:
> > 
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> > 
> > Again from my point of view a section that describes in 
> detail this feature
> > is needed in the ID.
> > 
> > Best regards,
> > 
> >             Diego.
> > 
> > Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> > 
> > Sent by:  owner-ccamp@ops.ietf.org
> > 
> > To:   Carmine Daloia <daloia@lucent.com>
> > cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
> >       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > 
> > Subject:  Re: Summary of LMP implementation/deployment reports
> > 
> > carmine,
> > 
> > just to be sure here we are on the same level of understanding
> > the bootstrap information that the receiver learn is the equivalent
> > of the one that you would normally provision, i refer you to the
> > following sentence of the Section 3 (of 
> draft-ietf-ccamp-lmp-05.txt):
> > 
> > "To establish a control channel, the destination IP address on the
> >  far end of the control channel must be known. This knowledge may be
> >  manually configured or automatically discovered."
> > 
> > and then you follow the procedure as described in this i-d (in
> > fact the bootstrap i-d also completes the second alternative of
> > the above sentence).
> > 
> > hope this clarifies,
> > - dimitri.
> > 
> > Carmine Daloia wrote:
> > >
> > > Dimitri,
> > >
> > > Thanks for the explanation for why it is left as a 
> separate document.
> > >
> > > I disagree with one point.  You say that the bootstrap 
> process would not
> > > cause anything in the lmp draft to be modified.
> > >
> > > Once the controll address of the neighbor is learned via 
> the bootstrap
> > > process, I don't see the purpose for Control Channel Management
> > Procedure.
> > >
> > > A link summary message can be sent directly to the 
> controll address
> > > learned via the bootstrap process.  Therefore I would 
> have expected the
> > > Control Channel Management Procedure to be removed 
> completely or at
> > > least made optional.
> > >
> > > Carmine
> > >
> > > Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > >carmine,
> > > >
> > > >1) this has been proposed in order to keep going with content
> > > >that has been discussed since more than two years now (and has
> > > >not been modified by the below mentioned document),
> > > >
> > > >2) since the result of the process (and the information it allows
> > > >to discover) is at the end the same than the one obtained when
> > > >applying the test message procedure no subsequent mechanisms
> > > >are modified by the bootstrap approach
> > > >
> > > >3) moreover, the bootstrap mechanisms have been identified (this
> > > >from the mailing list discussions) to be useful (up to now) for
> > > >sonet/sdh or more generally for "optical" environments only.
> > > >
> > > >thus i think this may justify the (good imho) idea to have two
> > > >separate documents (it results from the above points to be thus
> > > >also justified from an implementation viewpoint)
> > > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Carmine Daloia wrote:
> > > >
> > > >
> > > >>Why is the procedure described in the lmp-bootstrap 
> draft not included
> > > >>in the lmp-draft?  Doesn't sound like lmp is complete 
> without this
> > > >>capability and therefore doesn't seem to make sense to 
> have these in
> > > >>separate drafts.
> > > >>
> > > >>Carmine
> > > >>
> > > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Carmine,
> > > >>>
> > > >>>this is why i have previously mentioned in my response
> > > >>>that "a proposal has been made to bootstrap out-of-band
> > > >>>control channels and discover the interface_id mappings
> > > >>>(or associations) before establishing a control channel"
> > > >>>
> > > >>>see:
> > >
> > 
> >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bo
> otstrap-00.txt
> > 
> > > >>>
> > > >>>thus the problem you've indicated in the below message is
> > > >>>also addressed -
> > > >>>
> > > >>>so
> > > >>>" So LMP can *build* the mappings (i.e., reduce
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>operator provisioning) if the operator has previously 
> provisioned the
> > > >>>>remote node addresses for each and every data link. "
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>may be now rephrased as
> > > >>>" LMP can *build* the mappings (i.e., reduce operator 
> provisioning)
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>without any provisioning of the remote node addresses for each
> > > >>>>and every data link"
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>thanks,
> > > >>>- dimitri.
> > > >>>
> > > >>>Carmine Daloia wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Kireeti, Dimitri,
> > > >>>>
> > > >>>>I realize that Section 5 in 
> draft-ietf-ccamp-lmp-05.txt states that
> > the
> > > >>>>Link Connectivity Verification procedure (which is 
> optional) may be
> > used
> > > >>>>to dynamically learn the id associations.  Is this 
> what you mean by
> > LMP
> > > >>>>being able to *build* the mappings?  However this 
> requires that an
> > > >>>>operator *PROVISION* for each and every data link the 
> remote node
> > > >>>>address that the data link is terminated on.  Only with this
> > > >>>>provisioning will the local node know the address to send the
> > > >>>>BeginVerify message to.   So LMP can *build* the 
> mappings (i.e.,
> > reduce
> > > >>>>operator provisioning) if the operator has previously 
> provisioned the
> > > >>>>remote node addresses for each and every data link.  
> Doesn't seem
> > like a
> > > >>>>useful capability.
> > > >>>>
> > > >>>>Carmine
> > > >>>>
> > > >>>>Kireeti Kompella wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Hi Carmine,
> > > >>>>>
> > > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>So basically LMP is used to verify that the 
> datalink id mappings
> > stored
> > > >>>>>>in the neighboring nodes match eachother.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Actually, LMP is used to *build* the mappings, not 
> verify them.  If
> > the
> > > >>>>>mappings were already stored, LMP could be used to 
> verify them --
> > but
> > > >>>>>that is a secondary function.
> > > >>>>>
> > > >>>>>Kireeti (as a WG participant).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>
> > 
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : dpapadimitriou@psg.com
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 02:36:39 -0700
Cc: "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Message-ID: <3D75D390.C1BEB6FD@lucent.com>
Date: Wed, 04 Sep 2002 11:34:08 +0200
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
MIME-Version: 1.0
To: Diego Caviglia <Diego.Caviglia@marconi.com>
Original-CC: "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti" <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, " Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: multipart/mixed; boundary="------------D17AE4DB480C0AD918CD9234"

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

Diego,

Michiel and Greg proposed text for such section on neighbor discovery in his lmp
update draft
http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
Refer to section 3 in this contribution.

This proposal allows neighbor discovery at the 
- STM-N level,
- STS/HOVC level,
- VT/LOVC level.

I.e it can be used to discover:
- STM-N TTP - TTP neighbors (e.g. two SDH eq connected via DWDM system)
- STM-N CTP - TTP neighbors 
- STM-N CTP - CTP neighbors 
    Note - STM-N CTP is located in a pre-OTN transparent optical cross 
           connect (do they still exist these days? :-( ), and in an 
           OTN ODUk equipment's STM-N trib port interface.

- STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N interfaces 
                        connected via non-ASON/GMPLS SDH/SONET network)
- STS/HOVC CTP - TTP neighbors (e.g. router with STM-N interface and SDH ADM)
- STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)

- VT/LOVC TTP - TTP neighbors
- VT/LOVC CTP - TTP neighbors
- VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)

It can be used for neighbor discovery in 
- (simple) link (G.805: link connection) cases and
- serial-compound link (G.805: link connection) cases.

This particularly important for the roll out of ASON/GMPLS networks. In this
phase there will be many non-ASON/GMPLS SDH/SONET networks which will
interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC [VT/LOVC] connections
is set up through such non-ASON/GMPLS SDH/SONET network as a (serial-compound)
link bundle (G.805: (serial-compound) link), then the ASON/GMPLS neighbors are
the last network element in the first ASON/GMPLS subnetwork and the first
network element in the second ASON/GMPLS subnetwork. The non-ASON/GMPLS
SDH/SONET network is now simply a part of the "data link" between these two
network elements. 

The ASON/GMPLS SDH/SONET network elements are also "transparent devices" (in the
sense of LMP section 5, par. 4) that do not "modify or examine data in normal
operation". As such, the the last sentence in the text in par. 5 of section 5 is
not correct.

	LMP, v0.5, section 5, par. 5: "Furthermore, for the link 
	verification procedure it is assumed that the nodal 
	architecture is designed so that messages can be sent and
	received over any data link. Note that this requirement is 
	trivial for opaque devices since each data link is electrically
	terminated and processed before being forwarded to the next
	opaque device, but that in transparent devices this is an
	additional requirement."

A SDH/SONET cross connect or ADM seems to be such "opaque device", but doesn't
terminate the STS/HOVC or VT/LOVC "data link" that exists between the two
ASON/GMPLS neighbors.

Michiel and Greg's proposal support automatic discovery between two neighbor
nodes that are either at the end of the same fiber, or at the end of different
fibers (and have one or more "transparent devices" between these fibers).

Regards,

Maarten
PS. as there seems to be no willingness to address Michiel/Greg's proposal in
ccamp (is this a correct conclusion of the email correspondence so far), it
seems waste of time for all to continue this discussion over here. Let's
concentrate this work in Q.14/15 and include it in G.7714. The market then must
decide between LMP and G.7714.

Diego Caviglia wrote:
> 
> Hi Dimitri,
>                           is neighbor discovery in the scope of LMP?  I
> suppose that it is.
> 
> With  Nbr  discovery  I'm referring to the scenario where a TNE is attached
> to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
> to.
> 
> Where is this discovery procedure described in the ID?
> 
> This  seems  to  me  one  of  the  major  advantages  of LMP (for sure more
> important  than  fault  management  which  in the transport network is well
> covered  by  inherent  Sonet/SDH  capabilities)  so a specific section that
> addresses neighbor discovery is needed, of course IMHO.
> 
> Some time ago I posted a mail on this topic, here is the reference:
> 
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
> 
> Again from my point of view a section that describes in detail this feature
> is needed in the ID.
> 
> Best regards,
> 
>             Diego.
> 
> Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
> 
> Sent by:  owner-ccamp@ops.ietf.org
> 
> To:   Carmine Daloia <daloia@lucent.com>
> cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
>       <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> 
> Subject:  Re: Summary of LMP implementation/deployment reports
> 
> carmine,
> 
> just to be sure here we are on the same level of understanding
> the bootstrap information that the receiver learn is the equivalent
> of the one that you would normally provision, i refer you to the
> following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):
> 
> "To establish a control channel, the destination IP address on the
>  far end of the control channel must be known. This knowledge may be
>  manually configured or automatically discovered."
> 
> and then you follow the procedure as described in this i-d (in
> fact the bootstrap i-d also completes the second alternative of
> the above sentence).
> 
> hope this clarifies,
> - dimitri.
> 
> Carmine Daloia wrote:
> >
> > Dimitri,
> >
> > Thanks for the explanation for why it is left as a separate document.
> >
> > I disagree with one point.  You say that the bootstrap process would not
> > cause anything in the lmp draft to be modified.
> >
> > Once the controll address of the neighbor is learned via the bootstrap
> > process, I don't see the purpose for Control Channel Management
> Procedure.
> >
> > A link summary message can be sent directly to the controll address
> > learned via the bootstrap process.  Therefore I would have expected the
> > Control Channel Management Procedure to be removed completely or at
> > least made optional.
> >
> > Carmine
> >
> > Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > >carmine,
> > >
> > >1) this has been proposed in order to keep going with content
> > >that has been discussed since more than two years now (and has
> > >not been modified by the below mentioned document),
> > >
> > >2) since the result of the process (and the information it allows
> > >to discover) is at the end the same than the one obtained when
> > >applying the test message procedure no subsequent mechanisms
> > >are modified by the bootstrap approach
> > >
> > >3) moreover, the bootstrap mechanisms have been identified (this
> > >from the mailing list discussions) to be useful (up to now) for
> > >sonet/sdh or more generally for "optical" environments only.
> > >
> > >thus i think this may justify the (good imho) idea to have two
> > >separate documents (it results from the above points to be thus
> > >also justified from an implementation viewpoint)
> > >
> > >thanks,
> > >- dimitri.
> > >
> > >Carmine Daloia wrote:
> > >
> > >
> > >>Why is the procedure described in the lmp-bootstrap draft not included
> > >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> > >>capability and therefore doesn't seem to make sense to have these in
> > >>separate drafts.
> > >>
> > >>Carmine
> > >>
> > >>Dimitri.Papadimitriou@alcatel.be wrote:
> > >>
> > >>
> > >>
> > >>>Carmine,
> > >>>
> > >>>this is why i have previously mentioned in my response
> > >>>that "a proposal has been made to bootstrap out-of-band
> > >>>control channels and discover the interface_id mappings
> > >>>(or associations) before establishing a control channel"
> > >>>
> > >>>see:
> >
> >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> > >>>
> > >>>thus the problem you've indicated in the below message is
> > >>>also addressed -
> > >>>
> > >>>so
> > >>>" So LMP can *build* the mappings (i.e., reduce
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>operator provisioning) if the operator has previously provisioned the
> > >>>>remote node addresses for each and every data link. "
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>may be now rephrased as
> > >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>without any provisioning of the remote node addresses for each
> > >>>>and every data link"
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>thanks,
> > >>>- dimitri.
> > >>>
> > >>>Carmine Daloia wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Kireeti, Dimitri,
> > >>>>
> > >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
> the
> > >>>>Link Connectivity Verification procedure (which is optional) may be
> used
> > >>>>to dynamically learn the id associations.  Is this what you mean by
> LMP
> > >>>>being able to *build* the mappings?  However this requires that an
> > >>>>operator *PROVISION* for each and every data link the remote node
> > >>>>address that the data link is terminated on.  Only with this
> > >>>>provisioning will the local node know the address to send the
> > >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e.,
> reduce
> > >>>>operator provisioning) if the operator has previously provisioned the
> > >>>>remote node addresses for each and every data link.  Doesn't seem
> like a
> > >>>>useful capability.
> > >>>>
> > >>>>Carmine
> > >>>>
> > >>>>Kireeti Kompella wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Hi Carmine,
> > >>>>>
> > >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>So basically LMP is used to verify that the datalink id mappings
> stored
> > >>>>>>in the neighboring nodes match eachother.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If
> the
> > >>>>>mappings were already stored, LMP could be used to verify them --
> but
> > >>>>>that is a secondary function.
> > >>>>>
> > >>>>>Kireeti (as a WG participant).
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>>
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
--------------D17AE4DB480C0AD918CD9234
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;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard

--------------D17AE4DB480C0AD918CD9234--




Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 04 Sep 2002 00:24:32 -0700
Subject: Re: Summary of LMP implementation/deployment reports
To: "Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>
Cc: "Carmine Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti"  <kireeti@juniper.net>, "Nik Langrind <nik" <nik@equipecom.com>, ""  Ccamp-wg (E-mail) " <ccamp" <ccamp@ops.ietf.org>
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Wed, 4 Sep 2002 09:21:07 +0200
Message-ID: <OF250DC1FB.EF63040D-ONC1256C2A.00245409@uk.marconicomms.com>
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"

Hi Dimitri,
                          is neighbor discovery in the scope of LMP?  I
suppose that it is.

With  Nbr  discovery  I'm referring to the scenario where a TNE is attached
to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
to.

Where is this discovery procedure described in the ID?

This  seems  to  me  one  of  the  major  advantages  of LMP (for sure more
important  than  fault  management  which  in the transport network is well
covered  by  inherent  Sonet/SDH  capabilities)  so a specific section that
addresses neighbor discovery is needed, of course IMHO.

Some time ago I posted a mail on this topic, here is the reference:

http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html

Again from my point of view a section that describes in detail this feature
is needed in the ID.

Best regards,

            Diego.



Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43

Sent by:  owner-ccamp@ops.ietf.org


To:   Carmine Daloia <daloia@lucent.com>
cc:   Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
      <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>

Subject:  Re: Summary of LMP implementation/deployment reports


carmine,

just to be sure here we are on the same level of understanding
the bootstrap information that the receiver learn is the equivalent
of the one that you would normally provision, i refer you to the
following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):

"To establish a control channel, the destination IP address on the
 far end of the control channel must be known. This knowledge may be
 manually configured or automatically discovered."

and then you follow the procedure as described in this i-d (in
fact the bootstrap i-d also completes the second alternative of
the above sentence).

hope this clarifies,
- dimitri.

Carmine Daloia wrote:
>
> Dimitri,
>
> Thanks for the explanation for why it is left as a separate document.
>
> I disagree with one point.  You say that the bootstrap process would not
> cause anything in the lmp draft to be modified.
>
> Once the controll address of the neighbor is learned via the bootstrap
> process, I don't see the purpose for Control Channel Management
Procedure.
>
> A link summary message can be sent directly to the controll address
> learned via the bootstrap process.  Therefore I would have expected the
> Control Channel Management Procedure to be removed completely or at
> least made optional.
>
> Carmine
>
> Dimitri.Papadimitriou@alcatel.be wrote:
>
> >carmine,
> >
> >1) this has been proposed in order to keep going with content
> >that has been discussed since more than two years now (and has
> >not been modified by the below mentioned document),
> >
> >2) since the result of the process (and the information it allows
> >to discover) is at the end the same than the one obtained when
> >applying the test message procedure no subsequent mechanisms
> >are modified by the bootstrap approach
> >
> >3) moreover, the bootstrap mechanisms have been identified (this
> >from the mailing list discussions) to be useful (up to now) for
> >sonet/sdh or more generally for "optical" environments only.
> >
> >thus i think this may justify the (good imho) idea to have two
> >separate documents (it results from the above points to be thus
> >also justified from an implementation viewpoint)
> >
> >thanks,
> >- dimitri.
> >
> >Carmine Daloia wrote:
> >
> >
> >>Why is the procedure described in the lmp-bootstrap draft not included
> >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> >>capability and therefore doesn't seem to make sense to have these in
> >>separate drafts.
> >>
> >>Carmine
> >>
> >>Dimitri.Papadimitriou@alcatel.be wrote:
> >>
> >>
> >>
> >>>Carmine,
> >>>
> >>>this is why i have previously mentioned in my response
> >>>that "a proposal has been made to bootstrap out-of-band
> >>>control channels and discover the interface_id mappings
> >>>(or associations) before establishing a control channel"
> >>>
> >>>see:
>
>>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

> >>>
> >>>thus the problem you've indicated in the below message is
> >>>also addressed -
> >>>
> >>>so
> >>>" So LMP can *build* the mappings (i.e., reduce
> >>>
> >>>
> >>>
> >>>
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link. "
> >>>>
> >>>>
> >>>>
> >>>>
> >>>may be now rephrased as
> >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> >>>
> >>>
> >>>
> >>>
> >>>>without any provisioning of the remote node addresses for each
> >>>>and every data link"
> >>>>
> >>>>
> >>>>
> >>>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>Carmine Daloia wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Kireeti, Dimitri,
> >>>>
> >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
the
> >>>>Link Connectivity Verification procedure (which is optional) may be
used
> >>>>to dynamically learn the id associations.  Is this what you mean by
LMP
> >>>>being able to *build* the mappings?  However this requires that an
> >>>>operator *PROVISION* for each and every data link the remote node
> >>>>address that the data link is terminated on.  Only with this
> >>>>provisioning will the local node know the address to send the
> >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e.,
reduce
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link.  Doesn't seem
like a
> >>>>useful capability.
> >>>>
> >>>>Carmine
> >>>>
> >>>>Kireeti Kompella wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi Carmine,
> >>>>>
> >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>So basically LMP is used to verify that the datalink id mappings
stored
> >>>>>>in the neighboring nodes match eachother.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If
the
> >>>>>mappings were already stored, LMP could be used to verify them --
but
> >>>>>that is a secondary function.
> >>>>>
> >>>>>Kireeti (as a WG participant).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>

--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361







Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 14:26:10 -0700
Message-ID: <3D752839.521292B4@tellabs.com>
Date: Tue, 03 Sep 2002 16:23:05 -0500
From: Jonathan Sadler <jonathan.sadler@tellabs.com>
Reply-To: jonathan.sadler@tellabs.com
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be, ccamp@ops.ietf.org
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(Sorry if this is a duplicate, my response did not go to the list...)

Dimitri -

This message is in regards your previous message.

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> jonathan,
> 
> > I am aware of
> > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > doing something similar to what G.7714 states, but unfortuantely no
> > information has been provided on how to distinguish between the
> > bootstrap and test messages when transported over certain bearers (ie.
> > J0).
> 
> the bootstrap message definition when transported over J0:
> " The first usable bit is used to identify the type of
>   Interface Id: if set, the Interface Id is numbered (IPv4);
>   if clear, the Interface Id is unnumbered. The next usable 32
>   bits MUST be the Interface Id. The next usable 32 bits MUST
>   be the Node Id. The next usable bit is used to identify the
>   type of Control Address: if set, the Interface Id is
>   numbered (IPv4); if clear, the Control Address is
>   unnumbered. The next usable 32 bits MUST be the Control
>   Address. The remaining bits are Reserved. "
> 
> the test message definition when transported over J0:
> " The first usable 8 bits are used to determine the address
>   type of the Interface_Id.  For IPv4, this value is 1. For
>   unnumbered, this value is 3.  The next usable 32 bits MUST
>   be the Interface_Id.  The next usable 32 bits MUST be the
>   Verify_Id that was received in the VERIFY_ID object of the
>   BeginVerifyAck message  The remaining bits are reserved and
>   should be sent as zero and ignored on receipt."

Thanks for quoting the text I already had read.  As stated, there is no
mechanism to distinguish the two messages from each other autonomously.

> thus the second message includes a VERIFY_ID that the
> first one (the bootstrap one) does not contain - moreover
> the first one indicates the Node Id (as requested by a
> bootstrap mechanism) - note: it is also clear that if
> you have a prior BeginVerify/BeginVerifyAck negotiation
> you expect a Test message pattern to be received (thus
> one has a consistency check mechanisms: thus, first do i
> recognize the "pattern" sent and then correlation w/
> the information exchanged (if any) through the control
> plane

Actually, I didn't see any specific text that stated it is assumed that
the state machines on both endpoints of a direction of communication
were synchronized.  Unfortunately, there are half duplex miswiring
situations where that will not be a safe assumption.  As an example, if
you have three nodes/ports A, B, and C that are miswired with A xmit
connected B rcv, and B xmit -> C rcv, then A sending out a control
channel bootstrap will cause an A-B control channel, but the test
messages intended to go B->A will instead go to C.  Since C has not
received any control channel messages stating there is a Verification in
process, it will interpret it as a Bootstrap message as there is no way
to determine from the message what type of message was sent...

> in brief you have the following cases:
>   Data plane            Prior exchange at Control Plane
>   -----------------------------------------------------
> - Test message      <-> BeginVerify exchange
> - Bootstrap message <-> nothing (having initiated the
>                         exchange of the Bootstrap message)
> 
> i think this respond to the question you have asked (at
> least as far as i understood it) - if yes then is there
> an issue with the current way the content of the above
> mentioned i-d describes this ?

As stated above, the mechanism needs to allow the two message types to
be distinguished without presuming the state of the receiver.  The text
does not provide for it.

> thanks,
> - dimitri.
> 
> Jonathan Sadler wrote:
> >
> > Dimitri -
> >
> > The first part of this message pertains to section 5
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt.
> >
> > As stated, section 5 requires a BeginVerify to be sent after a control
> > channel is set up.  Consequently, it is not possible to use the Test
> > messages as the basis of setting up a control channel.
> >
> > Since a control channel requires explicit identification of the peer
> > controller, there is no "discovery" going on.
> >
> > An alternate approach, which is included in G.7714, is that the in-band
> > messages (eg. the LMP test messages) should contain the controller ID
> > allowing the controller to be identified, and therefore seed the control
> > channel setup.
> >
> > I am aware of
> > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > doing something similar to what G.7714 states, but unfortuantely no
> > information has been provided on how to distinguish between the
> > bootstrap and test messages when transported over certain bearers (ie.
> > J0).
> >
> > Please provide insight.
> >
> > Jonathan Sadler
> >
> > Dimitri.Papadimitriou@alcatel.be wrote:
> > >
> > > hi,
> > >
> > > imho i think it would be good if people discussing specific
> > > i-ds on this mailing list could point out to the section of
> > > the document providing the feature they speak about (or the
> > > sections that does not contain it and that should ideally
> > > do) but at least be more accurate about a specific item under
> > > discussion (now that a terminology section has been delivered
> > > in the last revision of the lmp i-d following this terminology
> > > may help in achieving progress - but also clear understanding
> > > of the mail discussions - by the ccamp community)
> > >
> > > but let's take an example from the below e-mail:
> > >
> > > > So basically LMP is used to verify that the datalink id mappings stored
> > > > in the neighboring nodes match eachother.
> > >
> > > see Section 5 of
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt
> > >
> > > in brief these mappings are "discovered" (link verification is
> > > much more than just a consistency check mechanism)
> > >
> > > > This type of capability would make more sense to be part of the protocol
> > > > that provided autodiscovery (i.e., discovered the datalink id mappings).
> > >
> > > thus the response to this question becomes clear (i think) and in
> > > addition a proposal has been made to bootstrap out-of-band control
> > > channels and discover the interface_id mappings (or associations)
> > > before establishing a control channel see:
> > >
> > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > >
> > > > In my opinion, it is the ability to autodiscover the id mappings that is
> > > > more useful than just verifying at a later time if the mappings still match.
> > >
> > > well from the structure of the BeginVerify/BeginVerifyAck Message
> > > as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we
> > > also see that the REMOTE_LINK_ID is an optional object such that
> > > both features listed here above are supported
> > >
> > > the Test message sent in-band being defined as in Section 12.5.6
> > > consistency is also provided by this protocol
> > >
> > > > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > > > for LMP to check whether the mappings match or not.  This check can be
> > > > done via the autodiscovery protocol itself.
> > >
> > > from the above discussion i think that LMP supports what you call
> > > "auto-discovery" and (if the previous statement is true) we may
> > > ask ourself to which protocol do you refer here and what's the
> > > relevance of the content of this statement ?
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Carmine Daloia wrote:
> > > >
> > > > Nik,
> > > >
> > > > Thanks for the clarification.
> > > >
> > > > So basically LMP is used to verify that the datalink id mappings stored
> > > > in the neighboring nodes match eachother.
> > > >
> > > > This type of capability would make more sense to be part of the protocol
> > > > that provided autodiscovery (i.e., discovered the datalink id mappings).
> > > >  After autodiscovery completes and the id mappings are stored, the
> > > > protocol can subsequently verify whether the mappings stored in the
> > > > neighboring nodes match eachother.
> > > >
> > > > In my opinion, it is the ability to autodiscover the id mappings that is
> > > > more useful than just verifying at a later time if the mappings still match.
> > > >
> > > > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > > > for LMP to check whether the mappings match or not.  This check can be
> > > > done via the autodiscovery protocol itself.
> > > >
> > > > Carmine
> > > >
> > > > Nik Langrind wrote:
> > > >
> > > > >Carmine,
> > > > >
> > > > >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> > > > >
> > > > >As I understand it, the reason is to allow two systems to exchange
> > > > >identifiers of their mutual TE links and the component datalinks of those TE
> > > > >links.
> > > > >
> > > > >Nik
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Carmine Daloia [mailto:daloia@lucent.com]
> > > > >>Sent: Tuesday, September 03, 2002 11:55 AM
> > > > >>To: Nik Langrind
> > > > >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> > > > >>Subject: Re: Summary of LMP implementation/deployment reports
> > > > >>
> > > > >>
> > > > >>Nik,
> > > > >>
> > > > >>What is meant by auto-configure?
> > > > >>
> > > > >>Thanks
> > > > >>Carmine
> > > > >>
> > > > >>Nik Langrind wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Hi Zhi,
> > > > >>>
> > > > >>>I don't think that gaps in SONET/SDH fault management are
> > > > >>>
> > > > >>>
> > > > >>the reason for
> > > > >>
> > > > >>
> > > > >>>implementing LMP on SONET/SDH systems. As I understand it,
> > > > >>>
> > > > >>>
> > > > >>the reason is to
> > > > >>
> > > > >>
> > > > >>>allow two systems to auto-configure the component datalinks
> > > > >>>
> > > > >>>
> > > > >>of their mutual
> > > > >>
> > > > >>
> > > > >>>TE link.
> > > > >>>
> > > > >>>Nik
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>-----Original Message-----
> > > > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > > > >>>>Sent: Thursday, August 29, 2002 10:55 AM
> > > > >>>>To: Wijnen, Bert (Bert)
> > > > >>>>Cc: Ccamp-wg (E-mail)
> > > > >>>>Subject: Re: Summary of LMP implementation/deployment reports
> > > > >>>>
> > > > >>>>
> > > > >>>>Hi Bert,
> > > > >>>>
> > > > >>>>This is really illuminating. We've been discussing LMP and
> > > > >>>>scope of LMP,
> > > > >>>>and from what I gather (maybe I've misinterpreted or
> > > > >>>>misunderstood what
> > > > >>>>people say) was that LMP was supposed to be targetting pre-OTN
> > > > >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> > > > >>>>has quite a
> > > > >>>>set of OAM capabilities that were much better (or at very least
> > > > >>>>comparable) to LMP (and they've been around more many many years)...
> > > > >>>>
> > > > >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> > > > >>>>what are
> > > > >>>>the gaps they see in existing SONET/SDH fault management (as
> > > > >>>>defined in
> > > > >>>>G.783) that LMP is supposed to fill?
> > > > >>>>
> > > > >>>>Thanks for any additional insights.
> > > > >>>>
> > > > >>>>Zhi
> > > > >>>>
> > > > >>>>
> > > > >>>>Wijnen, Bert (Bert) wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>Here is the summary of the reports I have received.
> > > > >>>>>
> > > > >>>>>The questions to be answered were:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>Type: vendor/carrier
> > > > >>>>>>Company: (to weed out duplicates)
> > > > >>>>>>Interest level in LMP:
> > > > >>>>>>  For vendors:  opposed/yawn/interested/implementing/released
> > > > >>>>>>  For carriers: useless/yawn/useful/testing/deploying/deployed
> > > > >>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>Type:                Equipment   TestEquip or   Carrier    ISP
> > > > >>>>>                   Vendor      SourceVendor
> > > > >>>>>
> > > > >>>>>Responses:              10            2            2        1
> > > > >>>>>
> > > > >>>>>Interest level:
> > > > >>>>>Released               2            2
> > > > >>>>>Implementing           6
> > > > >>>>>yawn                   1                                  1
> > > > >>>>>testing                                          2
> > > > >>>>>(very)usefull                                    1
> > > > >>>>>
> > > > >>>>>Technologies (not split by type)
> > > > >>>>>SONET - SONET/SDH      10
> > > > >>>>>Ethernet GigE           5
> > > > >>>>>ATM                     2
> > > > >>>>>MPLS                    1
> > > > >>>>>PXC                     1
> > > > >>>>>(D)WDM                  2
> > > > >>>>>Fiber                   1
> > > > >>>>>Transparent             1
> > > > >>>>>Sonet DCC               1
> > > > >>>>>POS                     1
> > > > >>>>>OTN                     1
> > > > >>>>>Lambda                  1
> > > > >>>>>Port Switching          1
> > > > >>>>>
> > > > >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> > > > >>>>>One implementation was O-UNI version of LMP, so does not do
> > > > >>>>>all the things described in current LMP draft.
> > > > >>>>>
> > > > >>>>>All in all quite a set if "implementations underway".
> > > > >>>>>
> > > > >>>>>Would have been good to see some more responses from
> > > > >>>>>
> > > > >>>>>
> > > > >>Carriers or ISPs
> > > > >>
> > > > >>
> > > > >>>>>Feel free to send your continued responses and I will try to keep
> > > > >>>>>the list up to date.
> > > > >>>>>
> > > > >>>>>Bert
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > ============================================================
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 13:06:45 -0700
Message-ID: <3D751653.6D036026@alcatel.be>
Date: Tue, 03 Sep 2002 22:06:43 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Carmine Daloia <daloia@lucent.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

carmine,

just to be sure here we are on the same level of understanding
the bootstrap information that the receiver learn is the equivalent 
of the one that you would normally provision, i refer you to the
following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):

"To establish a control channel, the destination IP address on the 
 far end of the control channel must be known. This knowledge may be 
 manually configured or automatically discovered." 

and then you follow the procedure as described in this i-d (in
fact the bootstrap i-d also completes the second alternative of 
the above sentence).

hope this clarifies,
- dimitri.

Carmine Daloia wrote:
> 
> Dimitri,
> 
> Thanks for the explanation for why it is left as a separate document.
> 
> I disagree with one point.  You say that the bootstrap process would not
> cause anything in the lmp draft to be modified.
> 
> Once the controll address of the neighbor is learned via the bootstrap
> process, I don't see the purpose for Control Channel Management Procedure.
> 
> A link summary message can be sent directly to the controll address
> learned via the bootstrap process.  Therefore I would have expected the
> Control Channel Management Procedure to be removed completely or at
> least made optional.
> 
> Carmine
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> 
> >carmine,
> >
> >1) this has been proposed in order to keep going with content
> >that has been discussed since more than two years now (and has
> >not been modified by the below mentioned document),
> >
> >2) since the result of the process (and the information it allows
> >to discover) is at the end the same than the one obtained when
> >applying the test message procedure no subsequent mechanisms
> >are modified by the bootstrap approach
> >
> >3) moreover, the bootstrap mechanisms have been identified (this
> >from the mailing list discussions) to be useful (up to now) for
> >sonet/sdh or more generally for "optical" environments only.
> >
> >thus i think this may justify the (good imho) idea to have two
> >separate documents (it results from the above points to be thus
> >also justified from an implementation viewpoint)
> >
> >thanks,
> >- dimitri.
> >
> >Carmine Daloia wrote:
> >
> >
> >>Why is the procedure described in the lmp-bootstrap draft not included
> >>in the lmp-draft?  Doesn't sound like lmp is complete without this
> >>capability and therefore doesn't seem to make sense to have these in
> >>separate drafts.
> >>
> >>Carmine
> >>
> >>Dimitri.Papadimitriou@alcatel.be wrote:
> >>
> >>
> >>
> >>>Carmine,
> >>>
> >>>this is why i have previously mentioned in my response
> >>>that "a proposal has been made to bootstrap out-of-band
> >>>control channels and discover the interface_id mappings
> >>>(or associations) before establishing a control channel"
> >>>
> >>>see:
> >>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> >>>
> >>>thus the problem you've indicated in the below message is
> >>>also addressed -
> >>>
> >>>so
> >>>" So LMP can *build* the mappings (i.e., reduce
> >>>
> >>>
> >>>
> >>>
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link. "
> >>>>
> >>>>
> >>>>
> >>>>
> >>>may be now rephrased as
> >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> >>>
> >>>
> >>>
> >>>
> >>>>without any provisioning of the remote node addresses for each
> >>>>and every data link"
> >>>>
> >>>>
> >>>>
> >>>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>Carmine Daloia wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Kireeti, Dimitri,
> >>>>
> >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
> >>>>Link Connectivity Verification procedure (which is optional) may be used
> >>>>to dynamically learn the id associations.  Is this what you mean by LMP
> >>>>being able to *build* the mappings?  However this requires that an
> >>>>operator *PROVISION* for each and every data link the remote node
> >>>>address that the data link is terminated on.  Only with this
> >>>>provisioning will the local node know the address to send the
> >>>>BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link.  Doesn't seem like a
> >>>>useful capability.
> >>>>
> >>>>Carmine
> >>>>
> >>>>Kireeti Kompella wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi Carmine,
> >>>>>
> >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>So basically LMP is used to verify that the datalink id mappings stored
> >>>>>>in the neighboring nodes match eachother.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Actually, LMP is used to *build* the mappings, not verify them.  If the
> >>>>>mappings were already stored, LMP could be used to verify them -- but
> >>>>>that is a secondary function.
> >>>>>
> >>>>>Kireeti (as a WG participant).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 12:42:28 -0700
Message-ID: <3D7510F5.4000006@lucent.com>
Date: Tue, 03 Sep 2002 15:43:49 -0400
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dimitri,

Thanks for the explanation for why it is left as a separate document.

I disagree with one point.  You say that the bootstrap process would not 
cause anything in the lmp draft to be modified.

Once the controll address of the neighbor is learned via the bootstrap 
process, I don't see the purpose for Control Channel Management Procedure.

A link summary message can be sent directly to the controll address 
learned via the bootstrap process.  Therefore I would have expected the 
Control Channel Management Procedure to be removed completely or at 
least made optional.

Carmine

Dimitri.Papadimitriou@alcatel.be wrote:

>carmine,
>
>1) this has been proposed in order to keep going with content 
>that has been discussed since more than two years now (and has 
>not been modified by the below mentioned document), 
>
>2) since the result of the process (and the information it allows
>to discover) is at the end the same than the one obtained when 
>applying the test message procedure no subsequent mechanisms 
>are modified by the bootstrap approach
>
>3) moreover, the bootstrap mechanisms have been identified (this 
>from the mailing list discussions) to be useful (up to now) for 
>sonet/sdh or more generally for "optical" environments only.
>
>thus i think this may justify the (good imho) idea to have two 
>separate documents (it results from the above points to be thus
>also justified from an implementation viewpoint) 
>
>thanks,
>- dimitri.
>
>Carmine Daloia wrote:
>  
>
>>Why is the procedure described in the lmp-bootstrap draft not included
>>in the lmp-draft?  Doesn't sound like lmp is complete without this
>>capability and therefore doesn't seem to make sense to have these in
>>separate drafts.
>>
>>Carmine
>>
>>Dimitri.Papadimitriou@alcatel.be wrote:
>>
>>    
>>
>>>Carmine,
>>>
>>>this is why i have previously mentioned in my response
>>>that "a proposal has been made to bootstrap out-of-band
>>>control channels and discover the interface_id mappings
>>>(or associations) before establishing a control channel"
>>>
>>>see:
>>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
>>>
>>>thus the problem you've indicated in the below message is
>>>also addressed -
>>>
>>>so
>>>" So LMP can *build* the mappings (i.e., reduce
>>>
>>>
>>>      
>>>
>>>>operator provisioning) if the operator has previously provisioned the
>>>>remote node addresses for each and every data link. "
>>>>
>>>>
>>>>        
>>>>
>>>may be now rephrased as
>>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
>>>
>>>
>>>      
>>>
>>>>without any provisioning of the remote node addresses for each
>>>>and every data link"
>>>>
>>>>
>>>>        
>>>>
>>>thanks,
>>>- dimitri.
>>>
>>>Carmine Daloia wrote:
>>>
>>>
>>>      
>>>
>>>>Kireeti, Dimitri,
>>>>
>>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
>>>>Link Connectivity Verification procedure (which is optional) may be used
>>>>to dynamically learn the id associations.  Is this what you mean by LMP
>>>>being able to *build* the mappings?  However this requires that an
>>>>operator *PROVISION* for each and every data link the remote node
>>>>address that the data link is terminated on.  Only with this
>>>>provisioning will the local node know the address to send the
>>>>BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
>>>>operator provisioning) if the operator has previously provisioned the
>>>>remote node addresses for each and every data link.  Doesn't seem like a
>>>>useful capability.
>>>>
>>>>Carmine
>>>>
>>>>Kireeti Kompella wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi Carmine,
>>>>>
>>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>So basically LMP is used to verify that the datalink id mappings stored
>>>>>>in the neighboring nodes match eachother.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Actually, LMP is used to *build* the mappings, not verify them.  If the
>>>>>mappings were already stored, LMP could be used to verify them -- but
>>>>>that is a secondary function.
>>>>>
>>>>>Kireeti (as a WG participant).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>
>>>      
>>>






Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 12:22:29 -0700
Message-ID: <3D750BF9.E2BB721F@alcatel.be>
Date: Tue, 03 Sep 2002 21:22:33 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Carmine Daloia <daloia@lucent.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

carmine,

1) this has been proposed in order to keep going with content 
that has been discussed since more than two years now (and has 
not been modified by the below mentioned document), 

2) since the result of the process (and the information it allows
to discover) is at the end the same than the one obtained when 
applying the test message procedure no subsequent mechanisms 
are modified by the bootstrap approach

3) moreover, the bootstrap mechanisms have been identified (this 
from the mailing list discussions) to be useful (up to now) for 
sonet/sdh or more generally for "optical" environments only.

thus i think this may justify the (good imho) idea to have two 
separate documents (it results from the above points to be thus
also justified from an implementation viewpoint) 

thanks,
- dimitri.

Carmine Daloia wrote:
> 
> Why is the procedure described in the lmp-bootstrap draft not included
> in the lmp-draft?  Doesn't sound like lmp is complete without this
> capability and therefore doesn't seem to make sense to have these in
> separate drafts.
> 
> Carmine
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> 
> >Carmine,
> >
> >this is why i have previously mentioned in my response
> >that "a proposal has been made to bootstrap out-of-band
> >control channels and discover the interface_id mappings
> >(or associations) before establishing a control channel"
> >
> >see:
> >http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> >
> >thus the problem you've indicated in the below message is
> >also addressed -
> >
> >so
> >" So LMP can *build* the mappings (i.e., reduce
> >
> >
> >>operator provisioning) if the operator has previously provisioned the
> >>remote node addresses for each and every data link. "
> >>
> >>
> >
> >may be now rephrased as
> >" LMP can *build* the mappings (i.e., reduce operator provisioning)
> >
> >
> >>without any provisioning of the remote node addresses for each
> >>and every data link"
> >>
> >>
> >
> >thanks,
> >- dimitri.
> >
> >Carmine Daloia wrote:
> >
> >
> >>Kireeti, Dimitri,
> >>
> >>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
> >>Link Connectivity Verification procedure (which is optional) may be used
> >>to dynamically learn the id associations.  Is this what you mean by LMP
> >>being able to *build* the mappings?  However this requires that an
> >>operator *PROVISION* for each and every data link the remote node
> >>address that the data link is terminated on.  Only with this
> >>provisioning will the local node know the address to send the
> >>BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
> >>operator provisioning) if the operator has previously provisioned the
> >>remote node addresses for each and every data link.  Doesn't seem like a
> >>useful capability.
> >>
> >>Carmine
> >>
> >>Kireeti Kompella wrote:
> >>
> >>
> >>
> >>>Hi Carmine,
> >>>
> >>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>So basically LMP is used to verify that the datalink id mappings stored
> >>>>in the neighboring nodes match eachother.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Actually, LMP is used to *build* the mappings, not verify them.  If the
> >>>mappings were already stored, LMP could be used to verify them -- but
> >>>that is a secondary function.
> >>>
> >>>Kireeti (as a WG participant).
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 12:10:10 -0700
Message-ID: <3D7508BF.49B17000@alcatel.be>
Date: Tue, 03 Sep 2002 21:08:47 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: jonathan.sadler@tellabs.com
Cc: Carmine Daloia <daloia@lucent.com>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

jonathan,

> I am aware of
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> doing something similar to what G.7714 states, but unfortuantely no
> information has been provided on how to distinguish between the
> bootstrap and test messages when transported over certain bearers (ie.
> J0).

the bootstrap message definition when transported over J0:
" The first usable bit is used to identify the type of 
  Interface Id: if set, the Interface Id is numbered (IPv4); 
  if clear, the Interface Id is unnumbered. The next usable 32 
  bits MUST be the Interface Id. The next usable 32 bits MUST 
  be the Node Id. The next usable bit is used to identify the 
  type of Control Address: if set, the Interface Id is 
  numbered (IPv4); if clear, the Control Address is 
  unnumbered. The next usable 32 bits MUST be the Control 
  Address. The remaining bits are Reserved. "

the test message definition when transported over J0:
" The first usable 8 bits are used to determine the address 
  type of the Interface_Id.  For IPv4, this value is 1. For 
  unnumbered, this value is 3.  The next usable 32 bits MUST 
  be the Interface_Id.  The next usable 32 bits MUST be the 
  Verify_Id that was received in the VERIFY_ID object of the 
  BeginVerifyAck message  The remaining bits are reserved and 
  should be sent as zero and ignored on receipt."

thus the second message includes a VERIFY_ID that the
first one (the bootstrap one) does not contain - moreover
the first one indicates the Node Id (as requested by a
bootstrap mechanism) - note: it is also clear that if 
you have a prior BeginVerify/BeginVerifyAck negotiation 
you expect a Test message pattern to be received (thus
one has a consistency check mechanisms: thus, first do i 
recognize the "pattern" sent and then correlation w/ 
the information exchanged (if any) through the control 
plane

in brief you have the following cases:
  Data plane            Prior exchange at Control Plane
  -----------------------------------------------------
- Test message      <-> BeginVerify exchange 
- Bootstrap message <-> nothing (having initiated the
                        exchange of the Bootstrap message)

i think this respond to the question you have asked (at
least as far as i understood it) - if yes then is there
an issue with the current way the content of the above
mentioned i-d describes this ?

thanks,
- dimitri.

Jonathan Sadler wrote:
> 
> Dimitri -
> 
> The first part of this message pertains to section 5
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt.
> 
> As stated, section 5 requires a BeginVerify to be sent after a control
> channel is set up.  Consequently, it is not possible to use the Test
> messages as the basis of setting up a control channel.
> 
> Since a control channel requires explicit identification of the peer
> controller, there is no "discovery" going on.
> 
> An alternate approach, which is included in G.7714, is that the in-band
> messages (eg. the LMP test messages) should contain the controller ID
> allowing the controller to be identified, and therefore seed the control
> channel setup.
> 
> I am aware of
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> doing something similar to what G.7714 states, but unfortuantely no
> information has been provided on how to distinguish between the
> bootstrap and test messages when transported over certain bearers (ie.
> J0).
> 
> Please provide insight.
> 
> Jonathan Sadler
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > hi,
> >
> > imho i think it would be good if people discussing specific
> > i-ds on this mailing list could point out to the section of
> > the document providing the feature they speak about (or the
> > sections that does not contain it and that should ideally
> > do) but at least be more accurate about a specific item under
> > discussion (now that a terminology section has been delivered
> > in the last revision of the lmp i-d following this terminology
> > may help in achieving progress - but also clear understanding
> > of the mail discussions - by the ccamp community)
> >
> > but let's take an example from the below e-mail:
> >
> > > So basically LMP is used to verify that the datalink id mappings stored
> > > in the neighboring nodes match eachother.
> >
> > see Section 5 of
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt
> >
> > in brief these mappings are "discovered" (link verification is
> > much more than just a consistency check mechanism)
> >
> > > This type of capability would make more sense to be part of the protocol
> > > that provided autodiscovery (i.e., discovered the datalink id mappings).
> >
> > thus the response to this question becomes clear (i think) and in
> > addition a proposal has been made to bootstrap out-of-band control
> > channels and discover the interface_id mappings (or associations)
> > before establishing a control channel see:
> >
> > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> >
> > > In my opinion, it is the ability to autodiscover the id mappings that is
> > > more useful than just verifying at a later time if the mappings still match.
> >
> > well from the structure of the BeginVerify/BeginVerifyAck Message
> > as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we
> > also see that the REMOTE_LINK_ID is an optional object such that
> > both features listed here above are supported
> >
> > the Test message sent in-band being defined as in Section 12.5.6
> > consistency is also provided by this protocol
> >
> > > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > > for LMP to check whether the mappings match or not.  This check can be
> > > done via the autodiscovery protocol itself.
> >
> > from the above discussion i think that LMP supports what you call
> > "auto-discovery" and (if the previous statement is true) we may
> > ask ourself to which protocol do you refer here and what's the
> > relevance of the content of this statement ?
> >
> > thanks,
> > - dimitri.
> >
> > Carmine Daloia wrote:
> > >
> > > Nik,
> > >
> > > Thanks for the clarification.
> > >
> > > So basically LMP is used to verify that the datalink id mappings stored
> > > in the neighboring nodes match eachother.
> > >
> > > This type of capability would make more sense to be part of the protocol
> > > that provided autodiscovery (i.e., discovered the datalink id mappings).
> > >  After autodiscovery completes and the id mappings are stored, the
> > > protocol can subsequently verify whether the mappings stored in the
> > > neighboring nodes match eachother.
> > >
> > > In my opinion, it is the ability to autodiscover the id mappings that is
> > > more useful than just verifying at a later time if the mappings still match.
> > >
> > > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > > for LMP to check whether the mappings match or not.  This check can be
> > > done via the autodiscovery protocol itself.
> > >
> > > Carmine
> > >
> > > Nik Langrind wrote:
> > >
> > > >Carmine,
> > > >
> > > >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> > > >
> > > >As I understand it, the reason is to allow two systems to exchange
> > > >identifiers of their mutual TE links and the component datalinks of those TE
> > > >links.
> > > >
> > > >Nik
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Carmine Daloia [mailto:daloia@lucent.com]
> > > >>Sent: Tuesday, September 03, 2002 11:55 AM
> > > >>To: Nik Langrind
> > > >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> > > >>Subject: Re: Summary of LMP implementation/deployment reports
> > > >>
> > > >>
> > > >>Nik,
> > > >>
> > > >>What is meant by auto-configure?
> > > >>
> > > >>Thanks
> > > >>Carmine
> > > >>
> > > >>Nik Langrind wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi Zhi,
> > > >>>
> > > >>>I don't think that gaps in SONET/SDH fault management are
> > > >>>
> > > >>>
> > > >>the reason for
> > > >>
> > > >>
> > > >>>implementing LMP on SONET/SDH systems. As I understand it,
> > > >>>
> > > >>>
> > > >>the reason is to
> > > >>
> > > >>
> > > >>>allow two systems to auto-configure the component datalinks
> > > >>>
> > > >>>
> > > >>of their mutual
> > > >>
> > > >>
> > > >>>TE link.
> > > >>>
> > > >>>Nik
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>-----Original Message-----
> > > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > > >>>>Sent: Thursday, August 29, 2002 10:55 AM
> > > >>>>To: Wijnen, Bert (Bert)
> > > >>>>Cc: Ccamp-wg (E-mail)
> > > >>>>Subject: Re: Summary of LMP implementation/deployment reports
> > > >>>>
> > > >>>>
> > > >>>>Hi Bert,
> > > >>>>
> > > >>>>This is really illuminating. We've been discussing LMP and
> > > >>>>scope of LMP,
> > > >>>>and from what I gather (maybe I've misinterpreted or
> > > >>>>misunderstood what
> > > >>>>people say) was that LMP was supposed to be targetting pre-OTN
> > > >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> > > >>>>has quite a
> > > >>>>set of OAM capabilities that were much better (or at very least
> > > >>>>comparable) to LMP (and they've been around more many many years)...
> > > >>>>
> > > >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> > > >>>>what are
> > > >>>>the gaps they see in existing SONET/SDH fault management (as
> > > >>>>defined in
> > > >>>>G.783) that LMP is supposed to fill?
> > > >>>>
> > > >>>>Thanks for any additional insights.
> > > >>>>
> > > >>>>Zhi
> > > >>>>
> > > >>>>
> > > >>>>Wijnen, Bert (Bert) wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>Here is the summary of the reports I have received.
> > > >>>>>
> > > >>>>>The questions to be answered were:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>Type: vendor/carrier
> > > >>>>>>Company: (to weed out duplicates)
> > > >>>>>>Interest level in LMP:
> > > >>>>>>  For vendors:  opposed/yawn/interested/implementing/released
> > > >>>>>>  For carriers: useless/yawn/useful/testing/deploying/deployed
> > > >>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>Type:                Equipment   TestEquip or   Carrier    ISP
> > > >>>>>                   Vendor      SourceVendor
> > > >>>>>
> > > >>>>>Responses:              10            2            2        1
> > > >>>>>
> > > >>>>>Interest level:
> > > >>>>>Released               2            2
> > > >>>>>Implementing           6
> > > >>>>>yawn                   1                                  1
> > > >>>>>testing                                          2
> > > >>>>>(very)usefull                                    1
> > > >>>>>
> > > >>>>>Technologies (not split by type)
> > > >>>>>SONET - SONET/SDH      10
> > > >>>>>Ethernet GigE           5
> > > >>>>>ATM                     2
> > > >>>>>MPLS                    1
> > > >>>>>PXC                     1
> > > >>>>>(D)WDM                  2
> > > >>>>>Fiber                   1
> > > >>>>>Transparent             1
> > > >>>>>Sonet DCC               1
> > > >>>>>POS                     1
> > > >>>>>OTN                     1
> > > >>>>>Lambda                  1
> > > >>>>>Port Switching          1
> > > >>>>>
> > > >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> > > >>>>>One implementation was O-UNI version of LMP, so does not do
> > > >>>>>all the things described in current LMP draft.
> > > >>>>>
> > > >>>>>All in all quite a set if "implementations underway".
> > > >>>>>
> > > >>>>>Would have been good to see some more responses from
> > > >>>>>
> > > >>>>>
> > > >>Carriers or ISPs
> > > >>
> > > >>
> > > >>>>>Feel free to send your continued responses and I will try to keep
> > > >>>>>the list up to date.
> > > >>>>>
> > > >>>>>Bert
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:41:06 -0700
Message-ID: <3D75028B.50808@lucent.com>
Date: Tue, 03 Sep 2002 14:42:19 -0400
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Why is the procedure described in the lmp-bootstrap draft not included 
in the lmp-draft?  Doesn't sound like lmp is complete without this 
capability and therefore doesn't seem to make sense to have these in 
separate drafts.

Carmine

Dimitri.Papadimitriou@alcatel.be wrote:

>Carmine,
>
>this is why i have previously mentioned in my response
>that "a proposal has been made to bootstrap out-of-band 
>control channels and discover the interface_id mappings 
>(or associations) before establishing a control channel"
>
>see:
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
>
>thus the problem you've indicated in the below message is
>also addressed - 
>
>so
>" So LMP can *build* the mappings (i.e., reduce
>  
>
>>operator provisioning) if the operator has previously provisioned the
>>remote node addresses for each and every data link. "
>>    
>>
>
>may be now rephrased as
>" LMP can *build* the mappings (i.e., reduce operator provisioning) 
>  
>
>>without any provisioning of the remote node addresses for each 
>>and every data link"
>>    
>>
>
>thanks,
>- dimitri.
>
>Carmine Daloia wrote:
>  
>
>>Kireeti, Dimitri,
>>
>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
>>Link Connectivity Verification procedure (which is optional) may be used
>>to dynamically learn the id associations.  Is this what you mean by LMP
>>being able to *build* the mappings?  However this requires that an
>>operator *PROVISION* for each and every data link the remote node
>>address that the data link is terminated on.  Only with this
>>provisioning will the local node know the address to send the
>>BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
>>operator provisioning) if the operator has previously provisioned the
>>remote node addresses for each and every data link.  Doesn't seem like a
>>useful capability.
>>
>>Carmine
>>
>>Kireeti Kompella wrote:
>>
>>    
>>
>>>Hi Carmine,
>>>
>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>So basically LMP is used to verify that the datalink id mappings stored
>>>>in the neighboring nodes match eachother.
>>>>
>>>>
>>>>        
>>>>
>>>Actually, LMP is used to *build* the mappings, not verify them.  If the
>>>mappings were already stored, LMP could be used to verify them -- but
>>>that is a secondary function.
>>>
>>>Kireeti (as a WG participant).
>>>
>>>
>>>
>>>      
>>>
>
>  
>






Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:34:33 -0700
Message-Id: <200209031832.g83IWvm47214@merlot.juniper.net>
To: Carmine Daloia <daloia@lucent.com>
cc: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8022.1031077977.1@juniper.net>
Date: Tue, 03 Sep 2002 11:32:57 -0700
From: Yakov Rekhter <yakov@juniper.net>

Carmine,

> Kireeti, Dimitri,
> 
> I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the 
> Link Connectivity Verification procedure (which is optional) may be used 
> to dynamically learn the id associations.  Is this what you mean by LMP 
> being able to *build* the mappings?  However this requires that an 
> operator *PROVISION* for each and every data link the remote node 
> address that the data link is terminated on.  Only with this 
> provisioning will the local node know the address to send the 
> BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce 
> operator provisioning) if the operator has previously provisioned the 
> remote node addresses for each and every data link.  Doesn't seem like a 
> useful capability.

Then don't implement it.

Yakov.

P.S. There's only one way to determine whether it is a useful capability
or not, and debate on this mailing list is not the way. 



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:26:30 -0700
Message-ID: <3D74FEDD.53021E5C@alcatel.be>
Date: Tue, 03 Sep 2002 20:26:37 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Carmine Daloia <daloia@lucent.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Carmine,

this is why i have previously mentioned in my response
that "a proposal has been made to bootstrap out-of-band 
control channels and discover the interface_id mappings 
(or associations) before establishing a control channel"

see:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

thus the problem you've indicated in the below message is
also addressed - 

so
" So LMP can *build* the mappings (i.e., reduce
> operator provisioning) if the operator has previously provisioned the
> remote node addresses for each and every data link. "

may be now rephrased as
" LMP can *build* the mappings (i.e., reduce operator provisioning) 
> without any provisioning of the remote node addresses for each 
> and every data link"

thanks,
- dimitri.

Carmine Daloia wrote:
> 
> Kireeti, Dimitri,
> 
> I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
> Link Connectivity Verification procedure (which is optional) may be used
> to dynamically learn the id associations.  Is this what you mean by LMP
> being able to *build* the mappings?  However this requires that an
> operator *PROVISION* for each and every data link the remote node
> address that the data link is terminated on.  Only with this
> provisioning will the local node know the address to send the
> BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
> operator provisioning) if the operator has previously provisioned the
> remote node addresses for each and every data link.  Doesn't seem like a
> useful capability.
> 
> Carmine
> 
> Kireeti Kompella wrote:
> 
> >Hi Carmine,
> >
> >On Tue, 3 Sep 2002, Carmine Daloia wrote:
> >
> >
> >
> >>So basically LMP is used to verify that the datalink id mappings stored
> >>in the neighboring nodes match eachother.
> >>
> >>
> >
> >Actually, LMP is used to *build* the mappings, not verify them.  If the
> >mappings were already stored, LMP could be used to verify them -- but
> >that is a secondary function.
> >
> >Kireeti (as a WG participant).
> >
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:24:41 -0700
Message-ID: <3D74FE1B.8EE1D7DE@tellabs.com>
Date: Tue, 03 Sep 2002 13:23:23 -0500
From: Jonathan Sadler <jonathan.sadler@tellabs.com>
Reply-To: jonathan.sadler@tellabs.com
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Carmine Daloia <daloia@lucent.com>, Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dimitri -

The first part of this message pertains to section 5
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt.

As stated, section 5 requires a BeginVerify to be sent after a control
channel is set up.  Consequently, it is not possible to use the Test
messages as the basis of setting up a control channel.

Since a control channel requires explicit identification of the peer
controller, there is no "discovery" going on.

An alternate approach, which is included in G.7714, is that the in-band
messages (eg. the LMP test messages) should contain the controller ID
allowing the controller to be identified, and therefore seed the control
channel setup.

I am aware of
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
doing something similar to what G.7714 states, but unfortuantely no
information has been provided on how to distinguish between the
bootstrap and test messages when transported over certain bearers (ie.
J0).

Please provide insight.

Jonathan Sadler

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> hi,
> 
> imho i think it would be good if people discussing specific
> i-ds on this mailing list could point out to the section of
> the document providing the feature they speak about (or the
> sections that does not contain it and that should ideally
> do) but at least be more accurate about a specific item under
> discussion (now that a terminology section has been delivered
> in the last revision of the lmp i-d following this terminology
> may help in achieving progress - but also clear understanding
> of the mail discussions - by the ccamp community)
> 
> but let's take an example from the below e-mail:
> 
> > So basically LMP is used to verify that the datalink id mappings stored
> > in the neighboring nodes match eachother.
> 
> see Section 5 of
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt
> 
> in brief these mappings are "discovered" (link verification is
> much more than just a consistency check mechanism)
> 
> > This type of capability would make more sense to be part of the protocol
> > that provided autodiscovery (i.e., discovered the datalink id mappings).
> 
> thus the response to this question becomes clear (i think) and in
> addition a proposal has been made to bootstrap out-of-band control
> channels and discover the interface_id mappings (or associations)
> before establishing a control channel see:
> 
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> > In my opinion, it is the ability to autodiscover the id mappings that is
> > more useful than just verifying at a later time if the mappings still match.
> 
> well from the structure of the BeginVerify/BeginVerifyAck Message
> as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we
> also see that the REMOTE_LINK_ID is an optional object such that
> both features listed here above are supported
> 
> the Test message sent in-band being defined as in Section 12.5.6
> consistency is also provided by this protocol
> 
> > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > for LMP to check whether the mappings match or not.  This check can be
> > done via the autodiscovery protocol itself.
> 
> from the above discussion i think that LMP supports what you call
> "auto-discovery" and (if the previous statement is true) we may
> ask ourself to which protocol do you refer here and what's the
> relevance of the content of this statement ?
> 
> thanks,
> - dimitri.
> 
> Carmine Daloia wrote:
> >
> > Nik,
> >
> > Thanks for the clarification.
> >
> > So basically LMP is used to verify that the datalink id mappings stored
> > in the neighboring nodes match eachother.
> >
> > This type of capability would make more sense to be part of the protocol
> > that provided autodiscovery (i.e., discovered the datalink id mappings).
> >  After autodiscovery completes and the id mappings are stored, the
> > protocol can subsequently verify whether the mappings stored in the
> > neighboring nodes match eachother.
> >
> > In my opinion, it is the ability to autodiscover the id mappings that is
> > more useful than just verifying at a later time if the mappings still match.
> >
> > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > for LMP to check whether the mappings match or not.  This check can be
> > done via the autodiscovery protocol itself.
> >
> > Carmine
> >
> > Nik Langrind wrote:
> >
> > >Carmine,
> > >
> > >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> > >
> > >As I understand it, the reason is to allow two systems to exchange
> > >identifiers of their mutual TE links and the component datalinks of those TE
> > >links.
> > >
> > >Nik
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Carmine Daloia [mailto:daloia@lucent.com]
> > >>Sent: Tuesday, September 03, 2002 11:55 AM
> > >>To: Nik Langrind
> > >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> > >>Subject: Re: Summary of LMP implementation/deployment reports
> > >>
> > >>
> > >>Nik,
> > >>
> > >>What is meant by auto-configure?
> > >>
> > >>Thanks
> > >>Carmine
> > >>
> > >>Nik Langrind wrote:
> > >>
> > >>
> > >>
> > >>>Hi Zhi,
> > >>>
> > >>>I don't think that gaps in SONET/SDH fault management are
> > >>>
> > >>>
> > >>the reason for
> > >>
> > >>
> > >>>implementing LMP on SONET/SDH systems. As I understand it,
> > >>>
> > >>>
> > >>the reason is to
> > >>
> > >>
> > >>>allow two systems to auto-configure the component datalinks
> > >>>
> > >>>
> > >>of their mutual
> > >>
> > >>
> > >>>TE link.
> > >>>
> > >>>Nik
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > >>>>Sent: Thursday, August 29, 2002 10:55 AM
> > >>>>To: Wijnen, Bert (Bert)
> > >>>>Cc: Ccamp-wg (E-mail)
> > >>>>Subject: Re: Summary of LMP implementation/deployment reports
> > >>>>
> > >>>>
> > >>>>Hi Bert,
> > >>>>
> > >>>>This is really illuminating. We've been discussing LMP and
> > >>>>scope of LMP,
> > >>>>and from what I gather (maybe I've misinterpreted or
> > >>>>misunderstood what
> > >>>>people say) was that LMP was supposed to be targetting pre-OTN
> > >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> > >>>>has quite a
> > >>>>set of OAM capabilities that were much better (or at very least
> > >>>>comparable) to LMP (and they've been around more many many years)...
> > >>>>
> > >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> > >>>>what are
> > >>>>the gaps they see in existing SONET/SDH fault management (as
> > >>>>defined in
> > >>>>G.783) that LMP is supposed to fill?
> > >>>>
> > >>>>Thanks for any additional insights.
> > >>>>
> > >>>>Zhi
> > >>>>
> > >>>>
> > >>>>Wijnen, Bert (Bert) wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Here is the summary of the reports I have received.
> > >>>>>
> > >>>>>The questions to be answered were:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Type: vendor/carrier
> > >>>>>>Company: (to weed out duplicates)
> > >>>>>>Interest level in LMP:
> > >>>>>>  For vendors:  opposed/yawn/interested/implementing/released
> > >>>>>>  For carriers: useless/yawn/useful/testing/deploying/deployed
> > >>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>Type:                Equipment   TestEquip or   Carrier    ISP
> > >>>>>                   Vendor      SourceVendor
> > >>>>>
> > >>>>>Responses:              10            2            2        1
> > >>>>>
> > >>>>>Interest level:
> > >>>>>Released               2            2
> > >>>>>Implementing           6
> > >>>>>yawn                   1                                  1
> > >>>>>testing                                          2
> > >>>>>(very)usefull                                    1
> > >>>>>
> > >>>>>Technologies (not split by type)
> > >>>>>SONET - SONET/SDH      10
> > >>>>>Ethernet GigE           5
> > >>>>>ATM                     2
> > >>>>>MPLS                    1
> > >>>>>PXC                     1
> > >>>>>(D)WDM                  2
> > >>>>>Fiber                   1
> > >>>>>Transparent             1
> > >>>>>Sonet DCC               1
> > >>>>>POS                     1
> > >>>>>OTN                     1
> > >>>>>Lambda                  1
> > >>>>>Port Switching          1
> > >>>>>
> > >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> > >>>>>One implementation was O-UNI version of LMP, so does not do
> > >>>>>all the things described in current LMP draft.
> > >>>>>
> > >>>>>All in all quite a set if "implementations underway".
> > >>>>>
> > >>>>>Would have been good to see some more responses from
> > >>>>>
> > >>>>>
> > >>Carriers or ISPs
> > >>
> > >>
> > >>>>>Feel free to send your continued responses and I will try to keep
> > >>>>>the list up to date.
> > >>>>>
> > >>>>>Bert
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:12:46 -0700
Message-ID: <3D74FBEE.3060301@lucent.com>
Date: Tue, 03 Sep 2002 14:14:06 -0400
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kireeti, Dimitri,

I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the 
Link Connectivity Verification procedure (which is optional) may be used 
to dynamically learn the id associations.  Is this what you mean by LMP 
being able to *build* the mappings?  However this requires that an 
operator *PROVISION* for each and every data link the remote node 
address that the data link is terminated on.  Only with this 
provisioning will the local node know the address to send the 
BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce 
operator provisioning) if the operator has previously provisioned the 
remote node addresses for each and every data link.  Doesn't seem like a 
useful capability.

Carmine


Kireeti Kompella wrote:

>Hi Carmine,
>
>On Tue, 3 Sep 2002, Carmine Daloia wrote:
>
>  
>
>>So basically LMP is used to verify that the datalink id mappings stored
>>in the neighboring nodes match eachother.
>>    
>>
>
>Actually, LMP is used to *build* the mappings, not verify them.  If the
>mappings were already stored, LMP could be used to verify them -- but
>that is a secondary function.
>
>Kireeti (as a WG participant).
>
>  
>






Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 11:02:05 -0700
Message-ID: <3D74F8F9.4FE3996A@alcatel.be>
Date: Tue, 03 Sep 2002 20:01:29 +0200
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: Carmine Daloia <daloia@lucent.com>
Cc: Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

hi,

imho i think it would be good if people discussing specific
i-ds on this mailing list could point out to the section of 
the document providing the feature they speak about (or the
sections that does not contain it and that should ideally 
do) but at least be more accurate about a specific item under 
discussion (now that a terminology section has been delivered 
in the last revision of the lmp i-d following this terminology 
may help in achieving progress - but also clear understanding 
of the mail discussions - by the ccamp community)

but let's take an example from the below e-mail:

> So basically LMP is used to verify that the datalink id mappings stored
> in the neighboring nodes match eachother.

see Section 5 of 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt

in brief these mappings are "discovered" (link verification is
much more than just a consistency check mechanism) 

> This type of capability would make more sense to be part of the protocol
> that provided autodiscovery (i.e., discovered the datalink id mappings).

thus the response to this question becomes clear (i think) and in 
addition a proposal has been made to bootstrap out-of-band control 
channels and discover the interface_id mappings (or associations)
before establishing a control channel see:

http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

> In my opinion, it is the ability to autodiscover the id mappings that is
> more useful than just verifying at a later time if the mappings still match.

well from the structure of the BeginVerify/BeginVerifyAck Message 
as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we 
also see that the REMOTE_LINK_ID is an optional object such that 
both features listed here above are supported

the Test message sent in-band being defined as in Section 12.5.6 
consistency is also provided by this protocol 

> Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> for LMP to check whether the mappings match or not.  This check can be
> done via the autodiscovery protocol itself.

from the above discussion i think that LMP supports what you call 
"auto-discovery" and (if the previous statement is true) we may 
ask ourself to which protocol do you refer here and what's the
relevance of the content of this statement ?

thanks,
- dimitri. 

Carmine Daloia wrote:
> 
> Nik,
> 
> Thanks for the clarification.
> 
> So basically LMP is used to verify that the datalink id mappings stored
> in the neighboring nodes match eachother.
> 
> This type of capability would make more sense to be part of the protocol
> that provided autodiscovery (i.e., discovered the datalink id mappings).
>  After autodiscovery completes and the id mappings are stored, the
> protocol can subsequently verify whether the mappings stored in the
> neighboring nodes match eachother.
> 
> In my opinion, it is the ability to autodiscover the id mappings that is
> more useful than just verifying at a later time if the mappings still match.
> 
> Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> for LMP to check whether the mappings match or not.  This check can be
> done via the autodiscovery protocol itself.
> 
> Carmine
> 
> Nik Langrind wrote:
> 
> >Carmine,
> >
> >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> >
> >As I understand it, the reason is to allow two systems to exchange
> >identifiers of their mutual TE links and the component datalinks of those TE
> >links.
> >
> >Nik
> >
> >
> >
> >>-----Original Message-----
> >>From: Carmine Daloia [mailto:daloia@lucent.com]
> >>Sent: Tuesday, September 03, 2002 11:55 AM
> >>To: Nik Langrind
> >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> >>Subject: Re: Summary of LMP implementation/deployment reports
> >>
> >>
> >>Nik,
> >>
> >>What is meant by auto-configure?
> >>
> >>Thanks
> >>Carmine
> >>
> >>Nik Langrind wrote:
> >>
> >>
> >>
> >>>Hi Zhi,
> >>>
> >>>I don't think that gaps in SONET/SDH fault management are
> >>>
> >>>
> >>the reason for
> >>
> >>
> >>>implementing LMP on SONET/SDH systems. As I understand it,
> >>>
> >>>
> >>the reason is to
> >>
> >>
> >>>allow two systems to auto-configure the component datalinks
> >>>
> >>>
> >>of their mutual
> >>
> >>
> >>>TE link.
> >>>
> >>>Nik
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> >>>>Sent: Thursday, August 29, 2002 10:55 AM
> >>>>To: Wijnen, Bert (Bert)
> >>>>Cc: Ccamp-wg (E-mail)
> >>>>Subject: Re: Summary of LMP implementation/deployment reports
> >>>>
> >>>>
> >>>>Hi Bert,
> >>>>
> >>>>This is really illuminating. We've been discussing LMP and
> >>>>scope of LMP,
> >>>>and from what I gather (maybe I've misinterpreted or
> >>>>misunderstood what
> >>>>people say) was that LMP was supposed to be targetting pre-OTN
> >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> >>>>has quite a
> >>>>set of OAM capabilities that were much better (or at very least
> >>>>comparable) to LMP (and they've been around more many many years)...
> >>>>
> >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> >>>>what are
> >>>>the gaps they see in existing SONET/SDH fault management (as
> >>>>defined in
> >>>>G.783) that LMP is supposed to fill?
> >>>>
> >>>>Thanks for any additional insights.
> >>>>
> >>>>Zhi
> >>>>
> >>>>
> >>>>Wijnen, Bert (Bert) wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Here is the summary of the reports I have received.
> >>>>>
> >>>>>The questions to be answered were:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Type: vendor/carrier
> >>>>>>Company: (to weed out duplicates)
> >>>>>>Interest level in LMP:
> >>>>>>  For vendors:  opposed/yawn/interested/implementing/released
> >>>>>>  For carriers: useless/yawn/useful/testing/deploying/deployed
> >>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Type:                Equipment   TestEquip or   Carrier    ISP
> >>>>>                   Vendor      SourceVendor
> >>>>>
> >>>>>Responses:              10            2            2        1
> >>>>>
> >>>>>Interest level:
> >>>>>Released               2            2
> >>>>>Implementing           6
> >>>>>yawn                   1                                  1
> >>>>>testing                                          2
> >>>>>(very)usefull                                    1
> >>>>>
> >>>>>Technologies (not split by type)
> >>>>>SONET - SONET/SDH      10
> >>>>>Ethernet GigE           5
> >>>>>ATM                     2
> >>>>>MPLS                    1
> >>>>>PXC                     1
> >>>>>(D)WDM                  2
> >>>>>Fiber                   1
> >>>>>Transparent             1
> >>>>>Sonet DCC               1
> >>>>>POS                     1
> >>>>>OTN                     1
> >>>>>Lambda                  1
> >>>>>Port Switching          1
> >>>>>
> >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> >>>>>One implementation was O-UNI version of LMP, so does not do
> >>>>>all the things described in current LMP draft.
> >>>>>
> >>>>>All in all quite a set if "implementations underway".
> >>>>>
> >>>>>Would have been good to see some more responses from
> >>>>>
> >>>>>
> >>Carriers or ISPs
> >>
> >>
> >>>>>Feel free to send your continued responses and I will try to keep
> >>>>>the list up to date.
> >>>>>
> >>>>>Bert



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 10:27:01 -0700
Date: Tue, 3 Sep 2002 10:26:21 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
To: Carmine Daloia <daloia@lucent.com>
cc: Nik Langrind <nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Message-ID: <20020903102247.E38811-100000@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Carmine,

On Tue, 3 Sep 2002, Carmine Daloia wrote:

> So basically LMP is used to verify that the datalink id mappings stored
> in the neighboring nodes match eachother.

Actually, LMP is used to *build* the mappings, not verify them.  If the
mappings were already stored, LMP could be used to verify them -- but
that is a secondary function.

Kireeti (as a WG participant).




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 10:00:42 -0700
Message-ID: <3D74EA84.4090003@lucent.com>
Date: Tue, 03 Sep 2002 12:59:48 -0400
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Nik Langrind <nik@equipecom.com>
CC: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nik,

Thanks for the clarification.

So basically LMP is used to verify that the datalink id mappings stored 
in the neighboring nodes match eachother.

This type of capability would make more sense to be part of the protocol 
that provided autodiscovery (i.e., discovered the datalink id mappings). 
 After autodiscovery completes and the id mappings are stored, the 
protocol can subsequently verify whether the mappings stored in the 
neighboring nodes match eachother.

In my opinion, it is the ability to autodiscover the id mappings that is 
more useful than just verifying at a later time if the mappings still match.

Since LMP doesn't support autodiscovery, it doesn't seem to be useful 
for LMP to check whether the mappings match or not.  This check can be 
done via the autodiscovery protocol itself.

Carmine


Nik Langrind wrote:

>Carmine,
>
>Yes, auto-configure is an ill-chosen term. Let me rephrase:
>
>As I understand it, the reason is to allow two systems to exchange
>identifiers of their mutual TE links and the component datalinks of those TE
>links.
>
>Nik
>
>  
>
>>-----Original Message-----
>>From: Carmine Daloia [mailto:daloia@lucent.com]
>>Sent: Tuesday, September 03, 2002 11:55 AM
>>To: Nik Langrind
>>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
>>Subject: Re: Summary of LMP implementation/deployment reports
>>
>>
>>Nik,
>>
>>What is meant by auto-configure?
>>
>>Thanks
>>Carmine
>>
>>Nik Langrind wrote:
>>
>>    
>>
>>>Hi Zhi,
>>>
>>>I don't think that gaps in SONET/SDH fault management are 
>>>      
>>>
>>the reason for
>>    
>>
>>>implementing LMP on SONET/SDH systems. As I understand it, 
>>>      
>>>
>>the reason is to
>>    
>>
>>>allow two systems to auto-configure the component datalinks 
>>>      
>>>
>>of their mutual
>>    
>>
>>>TE link.
>>>
>>>Nik
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
>>>>Sent: Thursday, August 29, 2002 10:55 AM
>>>>To: Wijnen, Bert (Bert)
>>>>Cc: Ccamp-wg (E-mail)
>>>>Subject: Re: Summary of LMP implementation/deployment reports
>>>>
>>>>
>>>>Hi Bert,
>>>>
>>>>This is really illuminating. We've been discussing LMP and 
>>>>scope of LMP, 
>>>>and from what I gather (maybe I've misinterpreted or 
>>>>misunderstood what 
>>>>people say) was that LMP was supposed to be targetting pre-OTN 
>>>>equipment, not SONET/SDH equipment since SONET/SDH already 
>>>>has quite a 
>>>>set of OAM capabilities that were much better (or at very least 
>>>>comparable) to LMP (and they've been around more many many years)...
>>>>
>>>>So I guess I like to ask people who's doing LMP for SONET/SDH 
>>>>what are 
>>>>the gaps they see in existing SONET/SDH fault management (as 
>>>>defined in 
>>>>G.783) that LMP is supposed to fill?
>>>>
>>>>Thanks for any additional insights.
>>>>
>>>>Zhi
>>>>
>>>>
>>>>Wijnen, Bert (Bert) wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Here is the summary of the reports I have received.
>>>>>
>>>>>The questions to be answered were:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>Type: vendor/carrier
>>>>>>Company: (to weed out duplicates)
>>>>>>Interest level in LMP:
>>>>>>	For vendors:  opposed/yawn/interested/implementing/released
>>>>>>	For carriers: useless/yawn/useful/testing/deploying/deployed
>>>>>>  used with technology: ethernet/sonet/sdh/atm/fr/xx
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Type:                Equipment   TestEquip or   Carrier    ISP
>>>>>                   Vendor      SourceVendor
>>>>>
>>>>>Responses:              10            2            2        1
>>>>>
>>>>>Interest level:
>>>>>Released               2            2
>>>>>Implementing           6
>>>>>yawn                   1                                  1
>>>>>testing                                          2
>>>>>(very)usefull                                    1
>>>>>
>>>>>Technologies (not split by type)
>>>>>SONET - SONET/SDH      10
>>>>>Ethernet GigE           5
>>>>>ATM                     2
>>>>>MPLS                    1
>>>>>PXC                     1
>>>>>(D)WDM                  2
>>>>>Fiber                   1
>>>>>Transparent             1
>>>>>Sonet DCC               1
>>>>>POS                     1
>>>>>OTN                     1
>>>>>Lambda                  1
>>>>>Port Switching          1
>>>>>
>>>>>The sourceVendor claimed to have 10 customers, 5 were named.
>>>>>One implementation was O-UNI version of LMP, so does not do
>>>>>all the things described in current LMP draft.
>>>>>
>>>>>All in all quite a set if "implementations underway".
>>>>>
>>>>>Would have been good to see some more responses from 
>>>>>          
>>>>>
>>Carriers or ISPs
>>    
>>
>>>>>Feel free to send your continued responses and I will try to keep
>>>>>the list up to date.
>>>>>
>>>>>Bert
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>






Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 09:27:46 -0700
Message-ID: <2135200C183FD5119588009027DE572301F1AAF5@wntcsdexg02.csd.ciena.com>
From: "Bernstein, Greg" <GregB@ciena.com>
To: "'Nik Langrind'" <nik@equipecom.com>, "'Zhi-Wei Lin'" <zwlin@lucent.com>
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Tue, 3 Sep 2002 09:23:05 -0700 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Nik and Zhi, et. al., a couple of points:

(a) Nik points out the usefulness of the "link property correlation"
function within LMP. Besides bundled links this could be applied to
configuring technology specific stuff like configuring a 1:N SONET/SDH
linear APS group.

(b) Zhi hit the reality of the situation -- Almost all of the optical
interoperability that we've seen (relevant to control plane and not, say,
components like amplifiers) has been either via SONET/SDH or Ethernet
signals.  

(c) Of the implementations that Bert listed, how many were being used just
for OIF UNI 1.0 discovery (SONET/SDH) interoperability rather than general
LMP?

Bert, Kireeti and/or Ron where are we in the process wrt the document?
Thanks

Greg B.

-----Original Message-----
From: Nik Langrind [mailto:nik@equipecom.com]
Sent: Tuesday, September 03, 2002 7:26 AM
To: 'Zhi-Wei Lin'
Cc: Ccamp-wg (E-mail)
Subject: RE: Summary of LMP implementation/deployment reports


Hi Zhi,

I don't think that gaps in SONET/SDH fault management are the reason for
implementing LMP on SONET/SDH systems. As I understand it, the reason is to
allow two systems to auto-configure the component datalinks of their mutual
TE link.

Nik

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Thursday, August 29, 2002 10:55 AM
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Hi Bert,
> 
> This is really illuminating. We've been discussing LMP and 
> scope of LMP, 
> and from what I gather (maybe I've misinterpreted or 
> misunderstood what 
> people say) was that LMP was supposed to be targetting pre-OTN 
> equipment, not SONET/SDH equipment since SONET/SDH already 
> has quite a 
> set of OAM capabilities that were much better (or at very least 
> comparable) to LMP (and they've been around more many many years)...
> 
> So I guess I like to ask people who's doing LMP for SONET/SDH 
> what are 
> the gaps they see in existing SONET/SDH fault management (as 
> defined in 
> G.783) that LMP is supposed to fill?
> 
> Thanks for any additional insights.
> 
> Zhi
> 
> 
> Wijnen, Bert (Bert) wrote:
> 
> >Here is the summary of the reports I have received.
> >
> >The questions to be answered were:
> >
> >  
> >
> >>Type: vendor/carrier
> >>Company: (to weed out duplicates)
> >>Interest level in LMP:
> >>	For vendors:  opposed/yawn/interested/implementing/released
> >>	For carriers: useless/yawn/useful/testing/deploying/deployed
> >>    used with technology: ethernet/sonet/sdh/atm/fr/xx
> >>    
> >>
> >
> >
> >Type:                Equipment   TestEquip or   Carrier    ISP
> >                     Vendor      SourceVendor
> >
> >Responses:              10            2            2        1
> >
> >Interest level:
> >  Released               2            2
> >  Implementing           6
> >  yawn                   1                                  1
> >  testing                                          2
> >  (very)usefull                                    1
> >
> >Technologies (not split by type)
> >  SONET - SONET/SDH      10
> >  Ethernet GigE           5
> >  ATM                     2
> >  MPLS                    1
> >  PXC                     1
> >  (D)WDM                  2
> >  Fiber                   1
> >  Transparent             1
> >  Sonet DCC               1
> >  POS                     1
> >  OTN                     1
> >  Lambda                  1
> >  Port Switching          1
> >
> >The sourceVendor claimed to have 10 customers, 5 were named.
> >One implementation was O-UNI version of LMP, so does not do
> >all the things described in current LMP draft.
> >
> >All in all quite a set if "implementations underway".
> >
> >Would have been good to see some more responses from Carriers or ISPs
> >Feel free to send your continued responses and I will try to keep
> >the list up to date.
> >
> >Bert
> >
> >  
> >
> 
> 




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 08:59:12 -0700
Message-ID: <666478FCC801D6118E3600D0B781FC16159E85@eccexch01.equipecom.com>
From: Nik Langrind <nik@equipecom.com>
To: "'Carmine Daloia'" <daloia@lucent.com>
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Tue, 3 Sep 2002 11:54:35 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Carmine,

Yes, auto-configure is an ill-chosen term. Let me rephrase:

As I understand it, the reason is to allow two systems to exchange
identifiers of their mutual TE links and the component datalinks of those TE
links.

Nik

> -----Original Message-----
> From: Carmine Daloia [mailto:daloia@lucent.com]
> Sent: Tuesday, September 03, 2002 11:55 AM
> To: Nik Langrind
> Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Nik,
> 
> What is meant by auto-configure?
> 
> Thanks
> Carmine
> 
> Nik Langrind wrote:
> 
> >Hi Zhi,
> >
> >I don't think that gaps in SONET/SDH fault management are 
> the reason for
> >implementing LMP on SONET/SDH systems. As I understand it, 
> the reason is to
> >allow two systems to auto-configure the component datalinks 
> of their mutual
> >TE link.
> >
> >Nik
> >
> >  
> >
> >>-----Original Message-----
> >>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> >>Sent: Thursday, August 29, 2002 10:55 AM
> >>To: Wijnen, Bert (Bert)
> >>Cc: Ccamp-wg (E-mail)
> >>Subject: Re: Summary of LMP implementation/deployment reports
> >>
> >>
> >>Hi Bert,
> >>
> >>This is really illuminating. We've been discussing LMP and 
> >>scope of LMP, 
> >>and from what I gather (maybe I've misinterpreted or 
> >>misunderstood what 
> >>people say) was that LMP was supposed to be targetting pre-OTN 
> >>equipment, not SONET/SDH equipment since SONET/SDH already 
> >>has quite a 
> >>set of OAM capabilities that were much better (or at very least 
> >>comparable) to LMP (and they've been around more many many years)...
> >>
> >>So I guess I like to ask people who's doing LMP for SONET/SDH 
> >>what are 
> >>the gaps they see in existing SONET/SDH fault management (as 
> >>defined in 
> >>G.783) that LMP is supposed to fill?
> >>
> >>Thanks for any additional insights.
> >>
> >>Zhi
> >>
> >>
> >>Wijnen, Bert (Bert) wrote:
> >>
> >>    
> >>
> >>>Here is the summary of the reports I have received.
> >>>
> >>>The questions to be answered were:
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>Type: vendor/carrier
> >>>>Company: (to weed out duplicates)
> >>>>Interest level in LMP:
> >>>>	For vendors:  opposed/yawn/interested/implementing/released
> >>>>	For carriers: useless/yawn/useful/testing/deploying/deployed
> >>>>   used with technology: ethernet/sonet/sdh/atm/fr/xx
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>Type:                Equipment   TestEquip or   Carrier    ISP
> >>>                    Vendor      SourceVendor
> >>>
> >>>Responses:              10            2            2        1
> >>>
> >>>Interest level:
> >>> Released               2            2
> >>> Implementing           6
> >>> yawn                   1                                  1
> >>> testing                                          2
> >>> (very)usefull                                    1
> >>>
> >>>Technologies (not split by type)
> >>> SONET - SONET/SDH      10
> >>> Ethernet GigE           5
> >>> ATM                     2
> >>> MPLS                    1
> >>> PXC                     1
> >>> (D)WDM                  2
> >>> Fiber                   1
> >>> Transparent             1
> >>> Sonet DCC               1
> >>> POS                     1
> >>> OTN                     1
> >>> Lambda                  1
> >>> Port Switching          1
> >>>
> >>>The sourceVendor claimed to have 10 customers, 5 were named.
> >>>One implementation was O-UNI version of LMP, so does not do
> >>>all the things described in current LMP draft.
> >>>
> >>>All in all quite a set if "implementations underway".
> >>>
> >>>Would have been good to see some more responses from 
> Carriers or ISPs
> >>>Feel free to send your continued responses and I will try to keep
> >>>the list up to date.
> >>>
> >>>Bert
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>    
> >>
> >
> >  
> >
> 
> 
> 



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 08:55:28 -0700
Message-ID: <3D74DB63.4020300@lucent.com>
Date: Tue, 03 Sep 2002 11:55:15 -0400
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Nik Langrind <nik@equipecom.com>
CC: "'Zhi-Wei Lin'" <zwlin@lucent.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nik,

What is meant by auto-configure?

Thanks
Carmine

Nik Langrind wrote:

>Hi Zhi,
>
>I don't think that gaps in SONET/SDH fault management are the reason for
>implementing LMP on SONET/SDH systems. As I understand it, the reason is to
>allow two systems to auto-configure the component datalinks of their mutual
>TE link.
>
>Nik
>
>  
>
>>-----Original Message-----
>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
>>Sent: Thursday, August 29, 2002 10:55 AM
>>To: Wijnen, Bert (Bert)
>>Cc: Ccamp-wg (E-mail)
>>Subject: Re: Summary of LMP implementation/deployment reports
>>
>>
>>Hi Bert,
>>
>>This is really illuminating. We've been discussing LMP and 
>>scope of LMP, 
>>and from what I gather (maybe I've misinterpreted or 
>>misunderstood what 
>>people say) was that LMP was supposed to be targetting pre-OTN 
>>equipment, not SONET/SDH equipment since SONET/SDH already 
>>has quite a 
>>set of OAM capabilities that were much better (or at very least 
>>comparable) to LMP (and they've been around more many many years)...
>>
>>So I guess I like to ask people who's doing LMP for SONET/SDH 
>>what are 
>>the gaps they see in existing SONET/SDH fault management (as 
>>defined in 
>>G.783) that LMP is supposed to fill?
>>
>>Thanks for any additional insights.
>>
>>Zhi
>>
>>
>>Wijnen, Bert (Bert) wrote:
>>
>>    
>>
>>>Here is the summary of the reports I have received.
>>>
>>>The questions to be answered were:
>>>
>>> 
>>>
>>>      
>>>
>>>>Type: vendor/carrier
>>>>Company: (to weed out duplicates)
>>>>Interest level in LMP:
>>>>	For vendors:  opposed/yawn/interested/implementing/released
>>>>	For carriers: useless/yawn/useful/testing/deploying/deployed
>>>>   used with technology: ethernet/sonet/sdh/atm/fr/xx
>>>>   
>>>>
>>>>        
>>>>
>>>Type:                Equipment   TestEquip or   Carrier    ISP
>>>                    Vendor      SourceVendor
>>>
>>>Responses:              10            2            2        1
>>>
>>>Interest level:
>>> Released               2            2
>>> Implementing           6
>>> yawn                   1                                  1
>>> testing                                          2
>>> (very)usefull                                    1
>>>
>>>Technologies (not split by type)
>>> SONET - SONET/SDH      10
>>> Ethernet GigE           5
>>> ATM                     2
>>> MPLS                    1
>>> PXC                     1
>>> (D)WDM                  2
>>> Fiber                   1
>>> Transparent             1
>>> Sonet DCC               1
>>> POS                     1
>>> OTN                     1
>>> Lambda                  1
>>> Port Switching          1
>>>
>>>The sourceVendor claimed to have 10 customers, 5 were named.
>>>One implementation was O-UNI version of LMP, so does not do
>>>all the things described in current LMP draft.
>>>
>>>All in all quite a set if "implementations underway".
>>>
>>>Would have been good to see some more responses from Carriers or ISPs
>>>Feel free to send your continued responses and I will try to keep
>>>the list up to date.
>>>
>>>Bert
>>>
>>> 
>>>
>>>      
>>>
>>    
>>
>
>  
>






Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 03 Sep 2002 07:34:16 -0700
Message-ID: <666478FCC801D6118E3600D0B781FC16159E80@eccexch01.equipecom.com>
From: Nik Langrind <nik@equipecom.com>
To: "'Zhi-Wei Lin'" <zwlin@lucent.com>
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: RE: Summary of LMP implementation/deployment reports
Date: Tue, 3 Sep 2002 10:25:41 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Zhi,

I don't think that gaps in SONET/SDH fault management are the reason for
implementing LMP on SONET/SDH systems. As I understand it, the reason is to
allow two systems to auto-configure the component datalinks of their mutual
TE link.

Nik

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Thursday, August 29, 2002 10:55 AM
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: Summary of LMP implementation/deployment reports
> 
> 
> Hi Bert,
> 
> This is really illuminating. We've been discussing LMP and 
> scope of LMP, 
> and from what I gather (maybe I've misinterpreted or 
> misunderstood what 
> people say) was that LMP was supposed to be targetting pre-OTN 
> equipment, not SONET/SDH equipment since SONET/SDH already 
> has quite a 
> set of OAM capabilities that were much better (or at very least 
> comparable) to LMP (and they've been around more many many years)...
> 
> So I guess I like to ask people who's doing LMP for SONET/SDH 
> what are 
> the gaps they see in existing SONET/SDH fault management (as 
> defined in 
> G.783) that LMP is supposed to fill?
> 
> Thanks for any additional insights.
> 
> Zhi
> 
> 
> Wijnen, Bert (Bert) wrote:
> 
> >Here is the summary of the reports I have received.
> >
> >The questions to be answered were:
> >
> >  
> >
> >>Type: vendor/carrier
> >>Company: (to weed out duplicates)
> >>Interest level in LMP:
> >>	For vendors:  opposed/yawn/interested/implementing/released
> >>	For carriers: useless/yawn/useful/testing/deploying/deployed
> >>    used with technology: ethernet/sonet/sdh/atm/fr/xx
> >>    
> >>
> >
> >
> >Type:                Equipment   TestEquip or   Carrier    ISP
> >                     Vendor      SourceVendor
> >
> >Responses:              10            2            2        1
> >
> >Interest level:
> >  Released               2            2
> >  Implementing           6
> >  yawn                   1                                  1
> >  testing                                          2
> >  (very)usefull                                    1
> >
> >Technologies (not split by type)
> >  SONET - SONET/SDH      10
> >  Ethernet GigE           5
> >  ATM                     2
> >  MPLS                    1
> >  PXC                     1
> >  (D)WDM                  2
> >  Fiber                   1
> >  Transparent             1
> >  Sonet DCC               1
> >  POS                     1
> >  OTN                     1
> >  Lambda                  1
> >  Port Switching          1
> >
> >The sourceVendor claimed to have 10 customers, 5 were named.
> >One implementation was O-UNI version of LMP, so does not do
> >all the things described in current LMP draft.
> >
> >All in all quite a set if "implementations underway".
> >
> >Would have been good to see some more responses from Carriers or ISPs
> >Feel free to send your continued responses and I will try to keep
> >the list up to date.
> >
> >Bert
> >
> >  
> >
> 
>