LMP's authentication function

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" 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" LMP's authentication function

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-- 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)" From: Lou Berger Subject: RE: IESG comments on generalize MPLS documents Cc: "Berger, Lou" , "Ccamp-wg (E-mail)" 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 > > > > > > > > > > > >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: From: Jonathan Lang To: "'Ong, Lyndon'" , 'Ron Bonica' , 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 To: "'Liu Qiang'" , "Reddy, Vikram" , ccamp@ops.ietf.org, IETF MPLS List 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 Subject: RE: Question on Control Channel -Data Channel association To: "Reddy, Vikram" , ccamp@ops.ietf.org, IETF MPLS List Message-id: 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: From: "Reddy, Vikram" To: ccamp@ops.ietf.org, IETF MPLS List 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 To: "Gmpls-Ops (E-mail)" , "'Ccamp (E-mail)" 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" To: "'Ong, Lyndon'" , "'Ron Bonica'" , 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" To: "'Ron Bonica'" , 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: From: "Michael I Mandelberg(Isaac)" 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)" From: Lou Berger Subject: RE: IESG comments on generalize MPLS documents Cc: "Berger, Lou" , "Ccamp-wg (E-mail)" 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] > > 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 > > > > > > > > > > > > > > > > > >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: From: "Wijnen, Bert (Bert)" To: Lou Berger Cc: "Ccamp-wg (E-mail)" 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 > > > > > > > > > > > > > > >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 Subject: WG Last Call: draft-ietf-ccamp-lmp-06 To: ccamp@ops.ietf.org Message-id: 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 To: "Mpls (E-mail)" , "Ccamp (E-mail)" 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 Reply-To: "ramsrm@tdd.sj.nec.com" To: "'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 Subject: RE: Timer constraint of the HelloInterval and HelloDeadInterval To: yhwkim@etri.re.kr, ccamp@ops.ietf.org Message-id: 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 Timer constraint of the HelloInterval and = HelloDeadInterval

Hi,=20

5ms and 18ms are impossible for my implementation=20 as 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 are too big for whole = system.

Regards,

Liu=20 Qiang

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

-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of=20 yhwkim@etri.re.kr
Sent: 2002=D2=B49=EA=C517=EC=ED = 12:05
To:=20 ccamp@ops.ietf.org
Subject: Timer constraint of the = HelloInterval=20 and HelloDeadInterval

Hi,

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

Thanks,
Young

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

--Boundary_(ID_hvrqPuBLxhgM3oWkDRRZAw)-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Sep 2002 16:06:27 -0700 Message-ID: From: Jonathan Lang To: "'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: From: "Michael I Mandelberg(Isaac)" 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" 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

------_=_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" To: "'Wijnen, Bert (Bert)'" , 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 To: Jonathan Lang cc: "'Ong, Lyndon'" , "'Dimitri.Papadimitriou@alcatel.be'" , "Bernstein, Greg" , 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" 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 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'? > > > > > > 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. > > > > > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Sep 2002 17:15:27 -0700 Message-ID: From: "Wijnen, Bert (Bert)" 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: From: Jonathan Lang To: "'Ong, Lyndon'" , "'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 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'? > > > > > > 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. > > > > > > 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" Cc: "'Kireeti Kompella'" , "Bernstein, Greg" , 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'? > > > > > > 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. > > > > > > 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" 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 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'? > > > 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. > > > 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" Cc: "'Kireeti Kompella'" , "Bernstein, Greg" , 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'? > > > 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. > > > 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" To: "'Kireeti Kompella'" , "Bernstein, Greg" 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'? 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. 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 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 CC: "Bernstein, Greg" , 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 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'? > > >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. > > >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 To: "Bernstein, Greg" cc: 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'? 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. 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 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" 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 with 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" 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: From: "Michael I Mandelberg(Isaac)" To: Diego Caviglia Cc: ccamp 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)" @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" To: "Zhi-Wei Lin" , "Soo-Hyun Choi" , Cc: , , , , , 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" > > 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 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 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" To: "Soo-Hyun Choi" , , , "Zhi-Wei Lin" , , , Cc: 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" From: "Diego Caviglia" Date: Wed, 11 Sep 2002 09:13:38 +0200 Message-ID: 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)" @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" To: , , "Zhi-Wei Lin" , , , Cc: 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: From: "Michael I Mandelberg(Isaac)" 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" Date: Tue, 10 Sep 2002 14:43:24 +0200 Message-ID: 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" Date: Tue, 10 Sep 2002 10:52:22 +0200 Message-ID: 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: From: Jonathan Lang To: 'gui' , 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: From: "Michael I Mandelberg(Isaac)" 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)" 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 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: From: "Michael I Mandelberg(Isaac)" 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)" From: Lou Berger Subject: Re: No Upstream Uni-directional LSPs? Cc: 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" To: 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" To: 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

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-- 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 To: 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: 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 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 To: 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: 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: From: "Michael I Mandelberg(Isaac)" 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: From: Jonathan Lang To: "'jonathan.sadler@tellabs.com'" , Dimitri.Papadimitriou@alcatel.be Cc: Carmine Daloia , Nik Langrind , "Ccamp-wg (E-mail)" 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, > > 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 Cc: "Michael I Mandelberg(Isaac)" , 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)" From: MATSUURA Nobuaki 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: From: "Michael I Mandelberg(Isaac)" 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: From: "Michael I Mandelberg(Isaac)" 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 To: Ron Bonica Cc: Tom Scott , 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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tom Scott Cc: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt Message-Id: 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: 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 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 Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt To: Tom Scott , ccamp@ops.ietf.org Message-id: 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" To: "'Marcos Antonio De Almeida Cora'" , 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: From: Jonathan Lang To: 'Maarten Vissers' , Diego Caviglia Cc: "Dimitri.Papadimitriou" , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 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 > > cc: Kireeti Kompella , Nik Langrind > > , "Ccamp-wg (E-mail)" > > > > 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: 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 Kireeti Kompella > > > > > 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 > > > > cc: Kireeti Kompella , Nik Langrind > > > > , "Ccamp-wg (E-mail)" > > > > > > > > > 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 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 Message-ID: <3D76050A.9D69D540@lucent.com> Date: Wed, 04 Sep 2002 15:05:14 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Wijnen, Bert" Original-CC: ccamp 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 > > 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 > > > cc: Kireeti Kompella , Nik Langrind > > > , "Ccamp-wg (E-mail)" > > > > > > 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 Cc: Maarten Vissers , Diego Caviglia , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Maarten Vissers , Diego Caviglia , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 Cc: Maarten Vissers , Diego Caviglia , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 > > > > cc: Kireeti Kompella , Nik Langrind > > > > , "Ccamp-wg (E-mail)" > > > > > > > > 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: From: "Wijnen, Bert (Bert)" To: Diego Caviglia , bwijnen@lucent.com Cc: "Maarten Vissers , 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 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)" on 04/09/2002 13.43.21 > > To: Maarten Vissers , Diego Caviglia > > cc: "Dimitri.Papadimitriou" > , "Carmine > Daloia , "Kireeti Kompella , "Nik Langrind , " > Ccamp-wg (E-mail) > > 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 > > 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 > > > cc: Kireeti Kompella , Nik Langrind > > > , "Ccamp-wg (E-mail)" > > > > > > > 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 , ccamp@ops.ietf.org From: "Diego Caviglia" Date: Wed, 4 Sep 2002 14:00:51 +0200 Message-ID: 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)" on 04/09/2002 13.43.21 To: Maarten Vissers , Diego Caviglia cc: "Dimitri.Papadimitriou" , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 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 > > cc: Kireeti Kompella , Nik Langrind > > , "Ccamp-wg (E-mail)" > > > > 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 Organization: Lucent Technologies , Optical Networking Group, MV MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Maarten Vissers , Diego Caviglia , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 > > > cc: Kireeti Kompella , Nik Langrind > > > , "Ccamp-wg (E-mail)" > > > > > > 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 Cc: Diego Caviglia , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 > > cc: Kireeti Kompella , Nik Langrind > > , "Ccamp-wg (E-mail)" > > > > 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: From: "Wijnen, Bert (Bert)" To: Maarten Vissers , Diego Caviglia Cc: "Dimitri.Papadimitriou" , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 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 > > cc: Kireeti Kompella , Nik Langrind > > , "Ccamp-wg (E-mail)" > > > > 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" , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) Message-ID: <3D75D390.C1BEB6FD@lucent.com> Date: Wed, 04 Sep 2002 11:34:08 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Diego Caviglia Original-CC: "Dimitri.Papadimitriou" , "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , " Ccamp-wg (E-mail) 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 > cc: Kireeti Kompella , Nik Langrind > , "Ccamp-wg (E-mail)" > > 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" Cc: "Carmine Daloia , "Kireeti Kompella , "Nik Langrind , "" Ccamp-wg (E-mail) " From: "Diego Caviglia" Date: Wed, 4 Sep 2002 09:21:07 +0200 Message-ID: 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 cc: Kireeti Kompella , Nik Langrind , "Ccamp-wg (E-mail)" 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 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 Cc: Kireeti Kompella , Nik Langrind , "Ccamp-wg (E-mail)" 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 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 , Nik Langrind , "Ccamp-wg (E-mail)" 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 Cc: Kireeti Kompella , Nik Langrind , "Ccamp-wg (E-mail)" 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 , Nik Langrind , "Ccamp-wg (E-mail)" 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 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 , Nik Langrind , "Ccamp-wg (E-mail)" 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 cc: Kireeti Kompella , Nik Langrind , "Ccamp-wg (E-mail)" 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 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 Cc: Kireeti Kompella , Nik Langrind , "Ccamp-wg (E-mail)" 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 Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Carmine Daloia , Nik Langrind , "Ccamp-wg (E-mail)" 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 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 MIME-Version: 1.0 To: Kireeti Kompella CC: Nik Langrind , "Ccamp-wg (E-mail)" 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 Cc: Nik Langrind , "Ccamp-wg (E-mail)" 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 To: Carmine Daloia cc: Nik Langrind , "Ccamp-wg (E-mail)" 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 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 MIME-Version: 1.0 To: Nik Langrind CC: "Ccamp-wg (E-mail)" 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" To: "'Nik Langrind'" , "'Zhi-Wei Lin'" Cc: "Ccamp-wg (E-mail)" 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 To: "'Carmine Daloia'" Cc: "Ccamp-wg (E-mail)" 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 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 MIME-Version: 1.0 To: Nik Langrind CC: "'Zhi-Wei Lin'" , "Ccamp-wg (E-mail)" 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 To: "'Zhi-Wei Lin'" Cc: "Ccamp-wg (E-mail)" 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 > > > > > > > >