Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Mar 2002 14:56:06 -0800 Date: Sun, 31 Mar 2002 17:45:19 -0500 From: Ron Bonica Subject: RE: Please read and comment on GMPLS P&R DT documents To: Sudheer Dharanikota , CCAMP WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sudheer, In Section 4.2.C of the terminology document, could you expand on the definition of "null traffic"? How is it different from "extra traffic"? Also, you don't use the term outside of section 4.2.C. Should this be cause for concern? Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Sudheer Dharanikota > Sent: Wednesday, March 13, 2002 12:28 PM > To: CCAMP WG > Subject: Please read and comment on GMPLS P&R DT documents > > > Hi Folks: > > Please note that the "GMPLS Protection and Restoration > Design Team" > has produced the following two documents (1st version)... > > Recovery (Protection and Restoration) Terminology for GMPLS > http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery > -terminology-00.txt > > Analysis for GMPLS-based Recovery Mechanisms(including > Protection and Restoration) > http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-an > alysis-00.txt > > We request you to read and comment on them as quickly as you > can. > > Regards, > > GMPLS P&R Design Team > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Mar 2002 13:18:53 -0800 Message-Id: <4.3.2.7.2.20020329160632.01f490e0@mo-ex1> Date: Fri, 29 Mar 2002 16:17:58 -0500 To: "Zhi-Wei Lin" From: Lou Berger Subject: Re: Fwd: GMPLS signaling (RSVP) assignment request. Cc: "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:53 PM 3/29/2002, Zhi-Wei Lin wrote: >Hi Lou, > >I was looking over the codes you suggested, and saw that there was a >redundancy: error code/value 24/6 and your suggested 24/13 both provide: > >o "Routing problem/Unacceptable label value" looks like a duplicate, and should be dropped. >Could you clarify whether 24/13 is for something else (a cut-and-paste >problem)? > Also, for the RRO, type = 3 (label), this is a redefinition of >the original RRO label type, and not a new type? Yes, this is in fact just a definition of a bit in the flags field. Lou >Thanks >Zhi > > >Lou Berger wrote: > > > FYI > > > >> Date: Mon, 11 Mar 2002 18:39:18 -0500 > >> To: iana@iana.org > >> From: Lou Berger > >> Subject: GMPLS signaling (RSVP) assignment request. > >> > >> Hello! > >> > >> We'd like to request assignment of types defined in > >> draft-ietf-mpls-generalized-rsvp-te-06. This draft has > >> passed WG last call and is on it's way to IESG/IETF last call. > >> Assignment is needed to ensure interoperability. > >> > >> Thank you, > >> Lou Berger (and co-authors) > >> > >> > >> --------------------------------------------------------------------- > >> > >> RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06 > >> with suggested values. > >> > >> --------------------------------------------------------------------- > >> Message Types > >> > >> o Notify message (suggested Message type =21) > >> > >> --------------------------------------------------------------------- > >> Class Types > >> > >> o RSVP_HOP (Existing C-Num 3) > >> - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) > >> - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) > >> > >> o ERROR_SPEC (Existing C-Num 6) > >> - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) > >> - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) > >> > >> o LABEL_REQUEST (Existing Class-Num 19) > >> - Generalized_Label_Request (Suggested C-Type =4) > >> > >> o RSVP_LABEL (Existing Class-Num 16) > >> - Generalized_Label (Suggested C-Type =2) > >> - Waveband_Switching_Label C-Type (Suggested C-Type =3) > >> > >> --------------------------------------------------------------------- > >> New Class-Nums, C-Types inherited from Label object (same as CNum16) > >> > >> o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) > >> o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) > >> o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) > >> > >> --------------------------------------------------------------------- > >> New Class-Nums > >> > >> o LABEL_SET Class-Num of form 0bbbbbbb (suggested > >> =36) > >> - Type 1 (C-Type =1) > >> o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (suggested > >> =130) > >> - Type 1 Acceptable_Label_Set (C-type from label_set cnum) > >> o NOTIFY_REQUEST Class-Num of form 11bbbbbb (suggested > >> =195) > >> - IPv4 Notify Request (C-Type =1) > >> - IPv6 Notify Request (C-Type =2) > >> o PROTECTION Class-Num of form 0bbbbbbb (suggested > >> =37) > >> - Type 1 (C-Type =1) > >> o ADMIN STATUS Class-Num of form 11bbbbbb (suggested > >> =196) > >> - Type 1 (C-Type =1) > >> o RESTART_CAP Class-Num of form 10bbbbbb (suggested > >> =131) > >> - Type 1 (C-Type =1) > >> > >> --------------------------------------------------------------------- > >> ERO/RRO subobject types > >> > >> o Label ERO subobject > >> Type 3 - Label > >> > >> o Label RRO subobject > >> Type 3 - Label > >> > >> --------------------------------------------------------------------- > >> Error codes > >> > >> o "Routing problem/Label Set" (Suggested > >> value =11) > >> o "Routing problem/Switching Type" (Suggested > >> value =12) > >> o "Routing problem/Unacceptable label value" (Suggested > >> value =13) > >> o "Routing problem/Unsupported Encoding" (Suggested > >> value =14) > >> o "Routing problem/Unsupported Link Protection" (Suggested > >> value =15) > >> o "Notify Error/Control Channel Active State" (Suggested > >> value =4) > >> o "Notify Error/Control Channel Degraded State" (Suggested > >> value =5) > >> --------------------------------------------------------------------- > >> > >> [related section from draft] > >> 13. IANA Considerations > >> > >> IANA assigns values to RSVP protocol parameters. Within the current > >> document multiple objects are defined. Each of these objects contain > >> C-Types. This section defines the rules for the assignment of the > >> related C-Type values. This section uses the terminology of BCP 26 > >> "Guidelines for Writing an IANA Considerations Section in RFCs" > >> [BCP26]. > >> > >> As per [RFC2205], C-Type is an 8-bit number that identifies the > >> function of an object. There are no range restrictions. All > >> possible values except zero are available for assignment. > >> > >> The assignment of C-Type values of the objects defined in this > >> document fall into three categories. The first category inherit C- > >> Types from the Label object, i.e., object class number 16 [RSVP-TE]. > >> IANA is requested to institute a policy whereby all C-Type values > >> assign for the Label object are also assigned for the following > >> objects: > >> o Suggested_Label (Class-Num TBA) > >> o Upstream_Label (Class-Num TBA) > >> o Recovery_Label (Class-Num TBA) > >> > >> The second category of objects follow independent policies. > >> Specifically, following the policies outlined in [BCP26], C-Type > >> values in the range 0x00 - 0x3F are allocated through an IETF > >> Consensus action, values in the range 00x40 - 0x5F are allocated as > >> First Come First Served, and values in the range 0x60 - 0x7F are > >> reserved for Private Use. This policy applies to the following > >> objects. > >> o Label_Set (Class-Num TBA) > >> o Notify_Request (Class-Num TBA) > >> o Protection (Class-Num TBA) > >> o Admin Status (Class-Num TBA) > >> o Restart_Cap (Class-Num TBA) > >> > >> > >> > >> Berger, et. al. [Page 35] > >> Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt November 2001 > >> > >> > >> The assignment of C-Type values for the remaining object, the > >> Acceptable_Label_Set object, follows the assignment of C-Type values > >> of the Label_Set object. IANA is requested to institute a policy > >> whereby all C-Type values assigned for the Label_Set object are also > >> assigned for the Acceptable_Label_Set object. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Mar 2002 11:55:35 -0800 Message-ID: <3CA4C627.7040304@lucent.com> Date: Fri, 29 Mar 2002 14:53:11 -0500 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org Subject: Re: Fwd: GMPLS signaling (RSVP) assignment request. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Lou, I was looking over the codes you suggested, and saw that there was a redundancy: error code/value 24/6 and your suggested 24/13 both provide: o "Routing problem/Unacceptable label value" Could you clarify whether 24/13 is for something else (a cut-and-paste problem)? Also, for the RRO, type = 3 (label), this is a redefinition of the original RRO label type, and not a new type? Thanks Zhi Lou Berger wrote: > FYI > >> Date: Mon, 11 Mar 2002 18:39:18 -0500 >> To: iana@iana.org >> From: Lou Berger >> Subject: GMPLS signaling (RSVP) assignment request. >> >> Hello! >> >> We'd like to request assignment of types defined in >> draft-ietf-mpls-generalized-rsvp-te-06. This draft has >> passed WG last call and is on it's way to IESG/IETF last call. >> Assignment is needed to ensure interoperability. >> >> Thank you, >> Lou Berger (and co-authors) >> >> >> --------------------------------------------------------------------- >> >> RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06 >> with suggested values. >> >> --------------------------------------------------------------------- >> Message Types >> >> o Notify message (suggested Message type =21) >> >> --------------------------------------------------------------------- >> Class Types >> >> o RSVP_HOP (Existing C-Num 3) >> - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) >> - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) >> >> o ERROR_SPEC (Existing C-Num 6) >> - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) >> - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) >> >> o LABEL_REQUEST (Existing Class-Num 19) >> - Generalized_Label_Request (Suggested C-Type =4) >> >> o RSVP_LABEL (Existing Class-Num 16) >> - Generalized_Label (Suggested C-Type =2) >> - Waveband_Switching_Label C-Type (Suggested C-Type =3) >> >> --------------------------------------------------------------------- >> New Class-Nums, C-Types inherited from Label object (same as CNum16) >> >> o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) >> o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) >> o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) >> >> --------------------------------------------------------------------- >> New Class-Nums >> >> o LABEL_SET Class-Num of form 0bbbbbbb (suggested >> =36) >> - Type 1 (C-Type =1) >> o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (suggested >> =130) >> - Type 1 Acceptable_Label_Set (C-type from label_set cnum) >> o NOTIFY_REQUEST Class-Num of form 11bbbbbb (suggested >> =195) >> - IPv4 Notify Request (C-Type =1) >> - IPv6 Notify Request (C-Type =2) >> o PROTECTION Class-Num of form 0bbbbbbb (suggested >> =37) >> - Type 1 (C-Type =1) >> o ADMIN STATUS Class-Num of form 11bbbbbb (suggested >> =196) >> - Type 1 (C-Type =1) >> o RESTART_CAP Class-Num of form 10bbbbbb (suggested >> =131) >> - Type 1 (C-Type =1) >> >> --------------------------------------------------------------------- >> ERO/RRO subobject types >> >> o Label ERO subobject >> Type 3 - Label >> >> o Label RRO subobject >> Type 3 - Label >> >> --------------------------------------------------------------------- >> Error codes >> >> o "Routing problem/Label Set" (Suggested >> value =11) >> o "Routing problem/Switching Type" (Suggested >> value =12) >> o "Routing problem/Unacceptable label value" (Suggested >> value =13) >> o "Routing problem/Unsupported Encoding" (Suggested >> value =14) >> o "Routing problem/Unsupported Link Protection" (Suggested >> value =15) >> o "Notify Error/Control Channel Active State" (Suggested >> value =4) >> o "Notify Error/Control Channel Degraded State" (Suggested >> value =5) >> --------------------------------------------------------------------- >> >> [related section from draft] >> 13. IANA Considerations >> >> IANA assigns values to RSVP protocol parameters. Within the current >> document multiple objects are defined. Each of these objects contain >> C-Types. This section defines the rules for the assignment of the >> related C-Type values. This section uses the terminology of BCP 26 >> "Guidelines for Writing an IANA Considerations Section in RFCs" >> [BCP26]. >> >> As per [RFC2205], C-Type is an 8-bit number that identifies the >> function of an object. There are no range restrictions. All >> possible values except zero are available for assignment. >> >> The assignment of C-Type values of the objects defined in this >> document fall into three categories. The first category inherit C- >> Types from the Label object, i.e., object class number 16 [RSVP-TE]. >> IANA is requested to institute a policy whereby all C-Type values >> assign for the Label object are also assigned for the following >> objects: >> o Suggested_Label (Class-Num TBA) >> o Upstream_Label (Class-Num TBA) >> o Recovery_Label (Class-Num TBA) >> >> The second category of objects follow independent policies. >> Specifically, following the policies outlined in [BCP26], C-Type >> values in the range 0x00 - 0x3F are allocated through an IETF >> Consensus action, values in the range 00x40 - 0x5F are allocated as >> First Come First Served, and values in the range 0x60 - 0x7F are >> reserved for Private Use. This policy applies to the following >> objects. >> o Label_Set (Class-Num TBA) >> o Notify_Request (Class-Num TBA) >> o Protection (Class-Num TBA) >> o Admin Status (Class-Num TBA) >> o Restart_Cap (Class-Num TBA) >> >> >> >> Berger, et. al. [Page 35] >> Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt November 2001 >> >> >> The assignment of C-Type values for the remaining object, the >> Acceptable_Label_Set object, follows the assignment of C-Type values >> of the Label_Set object. IANA is requested to institute a policy >> whereby all C-Type values assigned for the Label_Set object are also >> assigned for the Acceptable_Label_Set object. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Mar 2002 07:55:28 -0800 Message-ID: <006401c1d7c9$9f23b3c0$96fdfe81@etri.re.kr> From: "Soo-Hyun Choi" To: "Jonathan Lang" , Cc: , "Jonathan Lang" Subject: Re: LMP over UDP Date: Sat, 30 Mar 2002 01:02:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi, Jonathan, I don't understand why the IESG would reject the LMP over raw IP unless you have a very very compelling reason. Could you clarify more on this? Regards, Soo-Hyun Choi ----- Original Message ----- From: "Jonathan Lang" To: Cc: ; "Jonathan Lang" Sent: Friday, March 22, 2002 10:51 AM Subject: LMP over UDP > All, > > I had a discussion with Scott in Minnesota about progressing LMP through the > IESG. He had given the LMP draft a "pre-IESG" review (looking for obvious > rejection material) and realized that it wouldn't fly as LMP over raw IP - > they're not giving out IP protocol IDs unless you have a very very > compelling reason. Instead we will run LMP over UDP, and get a UDP port for > LMP from IANA. Fixing this now will short-circuit an almost certain IESG > rejection. > > Thanks, > Jonathan > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Mar 2002 07:38:51 -0800 Message-ID: <53BBA8839E91D51194D200902728944ED63773@host3.tbg.com> From: Irwin Lazar To: "'di.dongke@zte.com.cn'" , ccamp@ops.ietf.org Subject: RE: about draft-xu-bgp-gmpls-01 Date: Fri, 29 Mar 2002 08:33:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Try: http://search.ietf.org/internet-drafts/draft-xu-bgp-gmpls-01.txt -----Original Message----- From: di.dongke@zte.com.cn [mailto:di.dongke@zte.com.cn] Sent: Friday, March 29, 2002 12:19 AM To: ccamp@ops.ietf.org Subject: about draft-xu-bgp-gmpls-01 hi, all, where can I find the latest version of this draft ? or which working group is discussing it ? thanks Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Mar 2002 04:03:52 -0800 Message-Id: <200203291202.HAA09050@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-signaling-survey-00.txt Date: Fri, 29 Mar 2002 07:02:16 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signaling - Implementation Survey Author(s) : L. Berger, Y. Rekhter Filename : draft-ietf-ccamp-gmpls-signaling-survey-00.txt Pages : 63 Date : 28-Mar-02 This document provides a survey of GMPLS signaling implementations. The primary focus of this survey are the signaling protocol mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and [GMPLS-SONET]. Other specifications and documents are listed if included in the submitted form. The survey form and latest version of this document are available from http://www.labn.net/gmpls-survey. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-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-gmpls-signaling-survey-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-gmpls-signaling-survey-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: <20020328141217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-signaling-survey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020328141217.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Mar 2002 21:22:03 -0800 Subject: about draft-xu-bgp-gmpls-01 To: ccamp@ops.ietf.org Message-ID: From: di.dongke@zte.com.cn Date: Fri, 29 Mar 2002 13:18:58 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii hi, all, where can I find the latest version of this draft ? or which working group is discussing it ? thanks Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Mar 2002 04:10:48 -0800 Message-Id: <200203281206.HAA22078@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-ospf-gmpls-extensions-05.txt Date: Thu, 28 Mar 2002 07:06:32 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OSPF Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-ospf-gmpls-extensions-05.txt Pages : 10 Date : 27-Mar-02 This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-ospf-gmpls-extensions-05.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-ospf-gmpls-extensions-05.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: <20020327151952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-gmpls-extensions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327151952.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Mar 2002 04:10:45 -0800 Message-Id: <200203281206.HAA22094@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-routing-03.txt Date: Thu, 28 Mar 2002 07:06:45 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-gmpls-routing-03.txt Pages : 24 Date : 27-Mar-02 This document specifies routing extensions in support of Generalized Multi-Protocol Label Switching (GMPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-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-routing-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-routing-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: <20020327152005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-routing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152005.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 17:46:41 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E2B5@nimbus> From: John Drake To: 'Randy Bush' , Yakov Rekhter Cc: "Wijnen, Bert (Bert)" , ccamp-wg Subject: RE: Generalized Signaling documents Date: Mon, 25 Mar 2002 17:45:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Randy, Incisive and well-reasoned, and stylistically flawless. Thanks, John -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, March 25, 2002 12:26 PM To: Yakov Rekhter Cc: Wijnen, Bert (Bert); ccamp-wg Subject: Re: Generalized Signaling documents >> but it will be so now. no exact number, but no longs lists. > Does that represent your own position, or the position of the > IESG as the whole ? the iesg, the rfc editor, the teacher, and my mommy. more details forthcoming. can we get to work now? randy Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 16:13:01 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3D59AFB@mail3.tellium.com> From: Debanjan Saha To: "'v.sharma@ieee.org'" , Eric Gray Cc: Yakov Rekhter , ccamp-wg Subject: RE: Generalized Signaling documents Date: Mon, 25 Mar 2002 18:55:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vishal, Echoing on what you said, the following is quoted from http://www.rfc-editor.org/policy.html, the policy document people keep referring to. Two reasons for avoiding long lists are mentioned. The first one is a formatting issue and does not apply to the GMPLS signaling draft. Formatting looks fine to me. In any case, it seems pretty frivolous. The second reason also does not apply to this draft since there are more authors than companies listed. Clearly authors were not added for corporate name dropping. This policy also seems very arbitrary and goes much beyond editorial responsibility. Just curious, who comes up with these policies? "Objections to huge author lists are both practical and ideological. The practical issues have to do with the long-existing RFC formatting conventions that do not comfortably handle large author lists." "Ideological objections stem from the Internet community's tradition of individual rather than corporate action and responsibility. Some might see a list of 17 authors on one RFC as motivated by a desire for corporate name-dropping, which would be inappropriate in the IETF/RFC context. If there is a desire to demonstrate how many companies are interested in this spec, a simple acknowledgment section can accomplish the same thing, without Author Overload." Debanjan -----Original Message----- From: Vishal Sharma [mailto:v.sharma@ieee.org] Sent: Monday, March 25, 2002 5:16 PM To: Eric Gray; Randy Bush Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg Subject: RE: Generalized Signaling documents Eric, Thanks for your comments. I think while general guidelines are good, it is necessary to also consider the nature and scope of work done on individual work items of a WG's charter. In each effort, there is a core group of people who take on the mantle of initiating ideas (often being the ones making the initial proposals) and progressing them through the development and documentation process on their way to becoming RFCs. That core group, which is typically small, sometimes may be a little larger given the specific subject at hand. In the case of the GMPLS signaling documents that core group has remained pretty consistent right from the initial days of this work (starting shortly before the Adelaide IETF in March 2000). Also, this core group is not unreasonably large. As someone already mentioned, GMPLS is a complex subject, requiring expertise from several areas, which is what the core group has brought to the document. Of course, many other people have contributed to shaping the document with comments, ideas, and suggestions and they should be acknowledged in the acknowledgement section of the document. There were also a couple of emails that pointed out that the signaling documents do not go against any of the RFC Editor's guidelines, as currently laid out. Formatting is not a problem (the document is very reasonably formatted), and certainly there is no intent of name dropping for companies (the list has remained fairly stable for quite a while, and represents the _individuals_ who contributed to the work). If the intent was to name drop, the list would have looked a lot different, with many more names perhaps. So, in this instance, I do not see any justification for arbitrarily coming down on the authors, especially after practically all of the work has been done. Given some other RFC examples that people have pointed to, and the inter-disciplinary nature of the GMPLS work, I cannot see a problem keeping the documents just as they are (and have been for the better part of a year). -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Eric Gray > Sent: Monday, March 25, 2002 4:02 PM > To: Randy Bush > Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg > Subject: Re: Generalized Signaling documents > > > Randy, > > I see the presentation on manners really took hold. > > You don't want to be so terse that the content of your > many replies nears zero - considering each reply on its > own - and I'm not sure that being so terse is consistent > with the goal of getting back to work. > > As I understand it, the guidelines from the RFC editor > are that people who made substantial contributions to the > work are 'authors' and should be listed as such. From there, > the progression might reasonably be to list a small set of > people (typically one) as the editor and acknowledge each > of the contributing authors in an appropriate section. > > If authors intend to indicate widespread support for the > ideas of an intended RFC, maybe it makes sense to add a > section - or paragraph - that spells this out. > > The intention - IMHO - is that the list of authors should > be consistent with the actual work and this implies some > guidelines of 'reasonableness'. Any such guidelines would > naturally need to be flexible as such things tend to evolve. > > The RFC editor needs to put a stake in the ground in order > to maintain credibility for the RFC publishing process. The > people contributing to the RFC process need to be sensitive > to this if they would like to have this process continue to be > as respected as it currently is. > > You wrote: > > >>>but it will be so now. no exact number, but no longs lists. > >>> > >>Does that represent your own position, or the position of the > >>IESG as the whole ? > >> > > > >the iesg, the rfc editor, the teacher, and my mommy. more details > >forthcoming. > > > >can we get to work now? > > > >randy > > > > > -- > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 14:10:25 -0800 Reply-To: From: "Vishal Sharma" To: "Eric Gray" , "Randy Bush" Cc: "Yakov Rekhter" , "Wijnen, Bert \(Bert\)" , "ccamp-wg" Subject: RE: Generalized Signaling documents Date: Mon, 25 Mar 2002 17:16:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, Thanks for your comments. I think while general guidelines are good, it is necessary to also consider the nature and scope of work done on individual work items of a WG's charter. In each effort, there is a core group of people who take on the mantle of initiating ideas (often being the ones making the initial proposals) and progressing them through the development and documentation process on their way to becoming RFCs. That core group, which is typically small, sometimes may be a little larger given the specific subject at hand. In the case of the GMPLS signaling documents that core group has remained pretty consistent right from the initial days of this work (starting shortly before the Adelaide IETF in March 2000). Also, this core group is not unreasonably large. As someone already mentioned, GMPLS is a complex subject, requiring expertise from several areas, which is what the core group has brought to the document. Of course, many other people have contributed to shaping the document with comments, ideas, and suggestions and they should be acknowledged in the acknowledgement section of the document. There were also a couple of emails that pointed out that the signaling documents do not go against any of the RFC Editor's guidelines, as currently laid out. Formatting is not a problem (the document is very reasonably formatted), and certainly there is no intent of name dropping for companies (the list has remained fairly stable for quite a while, and represents the _individuals_ who contributed to the work). If the intent was to name drop, the list would have looked a lot different, with many more names perhaps. So, in this instance, I do not see any justification for arbitrarily coming down on the authors, especially after practically all of the work has been done. Given some other RFC examples that people have pointed to, and the inter-disciplinary nature of the GMPLS work, I cannot see a problem keeping the documents just as they are (and have been for the better part of a year). -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Eric Gray > Sent: Monday, March 25, 2002 4:02 PM > To: Randy Bush > Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp-wg > Subject: Re: Generalized Signaling documents > > > Randy, > > I see the presentation on manners really took hold. > > You don't want to be so terse that the content of your > many replies nears zero - considering each reply on its > own - and I'm not sure that being so terse is consistent > with the goal of getting back to work. > > As I understand it, the guidelines from the RFC editor > are that people who made substantial contributions to the > work are 'authors' and should be listed as such. From there, > the progression might reasonably be to list a small set of > people (typically one) as the editor and acknowledge each > of the contributing authors in an appropriate section. > > If authors intend to indicate widespread support for the > ideas of an intended RFC, maybe it makes sense to add a > section - or paragraph - that spells this out. > > The intention - IMHO - is that the list of authors should > be consistent with the actual work and this implies some > guidelines of 'reasonableness'. Any such guidelines would > naturally need to be flexible as such things tend to evolve. > > The RFC editor needs to put a stake in the ground in order > to maintain credibility for the RFC publishing process. The > people contributing to the RFC process need to be sensitive > to this if they would like to have this process continue to be > as respected as it currently is. > > You wrote: > > >>>but it will be so now. no exact number, but no longs lists. > >>> > >>Does that represent your own position, or the position of the > >>IESG as the whole ? > >> > > > >the iesg, the rfc editor, the teacher, and my mommy. more details > >forthcoming. > > > >can we get to work now? > > > >randy > > > > > -- > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 14:01:03 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3D59AF9@mail3.tellium.com> From: Debanjan Saha To: 'Randy Bush' , Yakov Rekhter Cc: "Wijnen, Bert (Bert)" , ccamp-wg , "'chair@ietf.org'" Subject: RE: Generalized Signaling documents Date: Mon, 25 Mar 2002 16:45:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Randy, I think IETF will be better served if offensive mails like this one are kept off official mailing lists. Debanjan >> but it will be so now. no exact number, but no longs lists. > Does that represent your own position, or the position of the > IESG as the whole ? the iesg, the rfc editor, the teacher, and my mommy. more details forthcoming. can we get to work now? randy Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 13:02:14 -0800 Message-ID: <3C9F904A.1020305@sandburst.com> Date: Mon, 25 Mar 2002 16:02:02 -0500 From: Eric Gray MIME-Version: 1.0 To: Randy Bush Cc: Yakov Rekhter , "Wijnen, Bert (Bert)" , ccamp-wg Subject: Re: Generalized Signaling documents Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randy, I see the presentation on manners really took hold. You don't want to be so terse that the content of your many replies nears zero - considering each reply on its own - and I'm not sure that being so terse is consistent with the goal of getting back to work. As I understand it, the guidelines from the RFC editor are that people who made substantial contributions to the work are 'authors' and should be listed as such. From there, the progression might reasonably be to list a small set of people (typically one) as the editor and acknowledge each of the contributing authors in an appropriate section. If authors intend to indicate widespread support for the ideas of an intended RFC, maybe it makes sense to add a section - or paragraph - that spells this out. The intention - IMHO - is that the list of authors should be consistent with the actual work and this implies some guidelines of 'reasonableness'. Any such guidelines would naturally need to be flexible as such things tend to evolve. The RFC editor needs to put a stake in the ground in order to maintain credibility for the RFC publishing process. The people contributing to the RFC process need to be sensitive to this if they would like to have this process continue to be as respected as it currently is. You wrote: >>>but it will be so now. no exact number, but no longs lists. >>> >>Does that represent your own position, or the position of the >>IESG as the whole ? >> > >the iesg, the rfc editor, the teacher, and my mommy. more details >forthcoming. > >can we get to work now? > >randy > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 13:00:27 -0800 Message-ID: <3C9F8F1F.A7AAD0F6@nayna.com> Date: Mon, 25 Mar 2002 12:57:03 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Yakov Rekhter CC: Jun Yu , "'Kireeti Kompella'" , "'ccamp@ops.ietf.org'" Subject: Re: FW: path TLV & srlg TLV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > > (2). If we only advertise Path Information for the FA, then the SRLG > > information of the FA > > can be derived, just as you specified in the "LSP Hierarchy" draft, it is > > "the union of the > > SRLGs of the underlying TE links that make up the FA-LSP path". > > > > On the other hand, if we only advertise SRLG Information for the FA, then > > the FA-LSP's path > > information becomes opaque to all the LSRs other than the headend LSR. This > > makes it difficult > > for the LSR to make a routing decision with "Link", or "Node" diversity > > requirement. > > while L in SRLG stands for "links", one could be quite creative > with the usage of SRLGs, and use them not just for links, but for > nodes as well. Doing this would allow to support both link and node > diversity. > Please refer to draft-many-ccamp-srg-01.txt for more details on "SRG" usage in the context of diversity. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 12:26:38 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: "Wijnen, Bert (Bert)" , ccamp-wg Subject: Re: Generalized Signaling documents Message-Id: Date: Mon, 25 Mar 2002 12:26:01 -0800 >> but it will be so now. no exact number, but no longs lists. > Does that represent your own position, or the position of the > IESG as the whole ? the iesg, the rfc editor, the teacher, and my mommy. more details forthcoming. can we get to work now? randy Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 12:00:19 -0800 Message-Id: <200203251959.g2PJxlT66711@merlot.juniper.net> To: Jun Yu cc: "'Kireeti Kompella'" , "'ccamp@ops.ietf.org'" Subject: Re: FW: path TLV & srlg TLV MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7075.1017086387.1@juniper.net> Date: Mon, 25 Mar 2002 11:59:47 -0800 From: Yakov Rekhter Jun, > No. I don't think so. > > But what I want to point out is, > > (1). There is inconsistency between "LSP Hierarchy with Generalized MPLS TE" > and > "Generalized Multi-Protocol Label Switching (GMPLS) Architecture" on this > matter > (whether to use path TLV or SRLG TLV in FA advertisement). that certainly has to be fixed (in the next iteration of the Architecture document). > (2). If we only advertise Path Information for the FA, then the SRLG > information of the FA > can be derived, just as you specified in the "LSP Hierarchy" draft, it is > "the union of the > SRLGs of the underlying TE links that make up the FA-LSP path". > > On the other hand, if we only advertise SRLG Information for the FA, then > the FA-LSP's path > information becomes opaque to all the LSRs other than the headend LSR. This > makes it difficult > for the LSR to make a routing decision with "Link", or "Node" diversity > requirement. while L in SRLG stands for "links", one could be quite creative with the usage of SRLGs, and use them not just for links, but for nodes as well. Doing this would allow to support both link and node diversity. Yakov. > > Thanks. > > -Jun > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Friday, March 15, 2002 5:05 PM > > To: Jun Yu > > Cc: 'ccamp@ops.ietf.org' > > Subject: Re: FW: path TLV & srlg TLV > > > > > > > > > > On Fri, 15 Mar 2002, Jun Yu wrote: > > > > > > Section 4.1.10, the context is changed to "SRLG > > Information" from the > > > > previous "Path Information". > > > > Do you think it is useful to include both SRLG and Path information? > > > > Kireeti. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Mar 2002 11:57:10 -0800 Message-Id: <200203251954.g2PJsbT66377@merlot.juniper.net> To: Randy Bush cc: "Wijnen, Bert (Bert)" , ccamp-wg Subject: Re: Generalized Signaling documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5637.1017086077.1@juniper.net> Date: Mon, 25 Mar 2002 11:54:37 -0800 From: Yakov Rekhter Randy, > >> I suggest that the group of current authors/editors work out > >> a reasonable number of people to be on the list. > >> I was giving guidelines that we (in IESG discussion) have > >> used in the past. > > So, you seem to suggest that the guidelines that the IESG "have > > used in the past" was to have no more than 3 to 4 authors. > > maybe it seems that way to you, but no one said that. > > but it will be so now. no exact number, but no longs lists. Does that represent your own position, or the position of the IESG as the whole ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 16:00:54 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: "Wijnen, Bert (Bert)" , ccamp-wg Subject: Re: Generalized Signaling documents Message-Id: Date: Fri, 22 Mar 2002 15:58:03 -0800 >> I suggest that the group of current authors/editors work out >> a reasonable number of people to be on the list. >> I was giving guidelines that we (in IESG discussion) have >> used in the past. > So, you seem to suggest that the guidelines that the IESG "have > used in the past" was to have no more than 3 to 4 authors. maybe it seems that way to you, but no one said that. but it will be so now. no exact number, but no longs lists. sorry to be terse, but i have work to do. randy Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 12:51:19 -0800 Message-Id: <200203222049.g2MKnuT55574@merlot.juniper.net> To: "Wijnen, Bert (Bert)" cc: ccamp-wg Subject: Re: Generalized Signaling documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6752.1016830196.1@juniper.net> Date: Fri, 22 Mar 2002 12:49:56 -0800 From: Yakov Rekhter Bert, > I suggest that the group of current authors/editors work out > a reasonable number of people to be on the list. > I was giving guidelines that we (in IESG discussion) have > used in the past. So, you seem to suggest that the guidelines that the IESG "have used in the past" was to have no more than 3 to 4 authors. Out of the 47 recently published RFCs (rfc3196 to rfc3275) 2 were published with 5 authors, 2 with 6 authors, 5 with 7 authors, 1 with 10 authors, and 1 with 14 authors. That is, about 1/4 of the recently published RFCs seem to violate the guidelines. With this in mind could you be a bit more precise on the guidelines that have been applied when publishing these RFCs. Yakov. > Bert > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, March 22, 2002 12:40 AM > > To: Wijnen, Bert (Bert) > > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg > > Subject: Re: Generalized Signaling documents > > > > > > Bert, > > > > > Chairs and authors/editors, if/when you go through a new > > > revision of the drafts (any drafts), pls take action > > > > > > - to reduce the list of authors on the front page. > > > main contributors (those who wrote say 30% of the text) > > > can be on front page. Others can be explicitly acknoledged > > > in the acknowledgement section > > > > If you suggest to limit the list of authors to only "those > > who wrote say 30% of the text", then are you saying that > > an RFC can't have more than 3-4 authors ? > > > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 11:23:28 -0800 Message-Id: <4.3.2.7.2.20020322142111.016fd830@funnel.cisco.com> Date: Fri, 22 Mar 2002 14:22:52 -0500 To: jplang@calient.net From: Baktha Muralidharan Subject: Comments on LMP Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18841572==_.ALT" --=====================_18841572==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Jonathan, Looks the following comments that I sent some time ago got lost. Thanks, /Baktha >X-Sender: muralidb@funnel.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Thu, 14 Mar 2002 23:02:27 -0500 >To: Jonathan Lang >From: Baktha Muralidharan >Subject: Comments on LMP >Cc: ccamp@ops.ietf.org, muralidb@cisco.com > >Hi Jonathan > > We have the following comments on LMP draft 3: >-------------------------------------------------- >1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks > about Message ID usage. It states, > > "Unacknowledged messages sent with the MESSAGE_ID object > SHOULD be retransmitted until the message is acknowledged > or until a retry limit is reached." > > What are the subsequent actions that need to take place when the > above conditions occur ? > >2. When Nacking a link summary, the current message format doesn't allow >indicate > what's wrong with each interface mapping.. "per-interface" error codes > would > be helpful. i.e. The TE link and each data link object in the Nack message > needs an error code to localize the failure. > >3. When a channel status msg is received with message ID less than >an earlier (TE-Link) message, it might still be accepted per the >draft. So, in the case where it is accepted, should the accepted > message ID become the basis for all future message ID (validations)? > >4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the >current LMP > draft does not support it. > >------------------------------------------------------------ >Thanks, > >/Baktha Muralidharan >Cisco Systems, Inc. >Chelmsford, MA. --=====================_18841572==_.ALT Content-Type: text/html; charset="us-ascii" Hi Jonathan,

        Looks the following comments that I sent some time ago
        got lost.

Thanks,

/Baktha


X-Sender: muralidb@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Mar 2002 23:02:27 -0500
To: Jonathan Lang <jplang@calient.net>
From: Baktha Muralidharan <muralidb@cisco.com>
Subject: Comments on LMP
Cc: ccamp@ops.ietf.org, muralidb@cisco.com

Hi Jonathan

         We have the following comments on LMP draft 3:
--------------------------------------------------
1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks
   about Message ID usage. It states,

            "Unacknowledged messages sent with the MESSAGE_ID object
             SHOULD be retransmitted until the message is acknowledged
             or until a retry limit is reached."

   What are the subsequent actions that need to take place when the
   above conditions occur ?

2. When Nacking a link summary, the current message format doesn’t allow indicate
   what's wrong with each interface mapping.. "per-interface" error codes would
   be helpful. i.e. The TE link and each data link object in the Nack message
   needs an error code to localize the failure.

3. When a channel status msg is received with message ID less than
an earlier (TE-Link) message, it might still be accepted per the
draft. So, in the case where it is accepted, should the accepted
   message ID become the basis for all future message ID (validations)?
 
4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the current LMP
   draft does not support it.

------------------------------------------------------------
Thanks,

/Baktha Muralidharan
Cisco Systems, Inc.
Chelmsford, MA.
--=====================_18841572==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 11:00:14 -0800 Message-ID: From: Jonathan Lang To: "'ccamp@ops.ietf.org'" Cc: "'sob@harvard.edu'" , Jonathan Lang Subject: LMP over UDP Date: Fri, 22 Mar 2002 10:51:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" All, I had a discussion with Scott in Minnesota about progressing LMP through the IESG. He had given the LMP draft a "pre-IESG" review (looking for obvious rejection material) and realized that it wouldn't fly as LMP over raw IP - they're not giving out IP protocol IDs unless you have a very very compelling reason. Instead we will run LMP over UDP, and get a UDP port for LMP from IANA. Fixing this now will short-circuit an almost certain IESG rejection. Thanks, Jonathan Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 09:03:00 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , "Ron Bonica (E-mail)" Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Fri, 22 Mar 2002 18:01:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I think that I did suggest that the authors try to come up with a reasonable list. Pls do so and then we can take it from there. Bert > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Friday, March 22, 2002 5:35 PM > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; Ron Bonica (E-mail) > Cc: ccamp-wg > Subject: RE: Generalized Signaling documents > > > Bert, > > I'd agree with 'main contributors' but not 'those who wrote > say 30% of the > text'. That reminds me of trying to judge programmer productivity by > counting line of code. In the spirit of 'main contributors' > why don't you > let the authors themselves do some soul searching and revise the list > themselves? > > This seems to be more in keeping with the spirit of the IETF. > > Thanks, > > John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, March 21, 2002 1:13 PM > To: Kireeti Kompella; Ron Bonica (E-mail) > Cc: ccamp-wg > Subject: RE: Generalized Signaling documents > > > Chairs and authors/editors, if/when you go through a new > revision of the drafts (any drafts), pls take action > > - to reduce the list of authors on the front page. > main contributors (those who wrote say 30% of the text) > can be on front page. Others can be explicitly acknoledged > in the acknowledgement section > An example is RFC2571 Acknowledgement section. > > - Split your references in normative and informative > references. > > For details on these RFC-guidelines, go to the www.rfc-editor.org > web pages. > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Mar 2002 08:37:28 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E294@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , "Ron Bonica (E-mail)" Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Fri, 22 Mar 2002 08:34:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, I'd agree with 'main contributors' but not 'those who wrote say 30% of the text'. That reminds me of trying to judge programmer productivity by counting line of code. In the spirit of 'main contributors' why don't you let the authors themselves do some soul searching and revise the list themselves? This seems to be more in keeping with the spirit of the IETF. Thanks, John -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, March 21, 2002 1:13 PM To: Kireeti Kompella; Ron Bonica (E-mail) Cc: ccamp-wg Subject: RE: Generalized Signaling documents Chairs and authors/editors, if/when you go through a new revision of the drafts (any drafts), pls take action - to reduce the list of authors on the front page. main contributors (those who wrote say 30% of the text) can be on front page. Others can be explicitly acknoledged in the acknowledgement section An example is RFC2571 Acknowledgement section. - Split your references in normative and informative references. For details on these RFC-guidelines, go to the www.rfc-editor.org web pages. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 23:52:46 -0800 Message-ID: From: Heiles Juergen To: "'Brungard, Deborah A, ALASO'" Cc: ccamp Subject: RE: LBM comment Date: Fri, 22 Mar 2002 08:51:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Deborah, virtual concatenation with LCAS can also be used by non-GFP mapped clients like IP (via POS) and ATM. Juergen > -----Original Message----- > From: Brungard, Deborah A, ALASO [mailto:dbrungard@att.com] > Sent: Thursday, March 21, 2002 4:26 PM > To: Sudheer Dharanikota; Bernstein, Greg > Cc: Maarten Vissers; ccamp > Subject: RE: LBM comment > > > Agree with Greg and Maarten. > > Hopefully of help are some tutorials from the last T1X1 > meeting on virtual conc and LCAS. I've given the links below. > Key is that LCAS is not about the addition/deletion of an > STS-x, this is handled by an EMS/NMS/control plane. LCAS is > about the use of the STS-x(s). It provides for the hitless > use of an STS-x by a client signal e.g. hitless resizing of > the bandwidth used by a client signal. It is based on the > premise that the STS-x is available. And, LCAS is only used > for client signals using virtual conc - it provides the > hitless resizing for the client mapping. The only client > signals defined for using Virtual conc/LCAS are the GFP > mapped clients: Ethernet, ESCON, Fiber Channel, FICON, etc. > > Deborah > > Links: > LCAS: > ftp://ftp.t1.org/T1X1/X1.5/2x150440.ppt > Virtual concatenation: > ftp://ftp.t1.org/T1X1/X1.5/2x150450.ppt > GFP: > ftp://ftp.t1.org/T1X1/X1.5/2x150460.ppt > > > > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Wednesday, March 20, 2002 9:15 PM > To: Bernstein, Greg > Cc: 'Maarten Vissers'; ccamp > Subject: Re: LBM comment > > > Hi Maarten and Greg: > > Can you help me in understanding the following case? > > Given: > > LCAS is used for "hitless" increase or decrease of capacity > of an end-to-end pipe. > > Question: > > How does the end nodes (of the pipe) know whether a given > increase of capacity is possible dynamically? > > My view: I think this case can be addressed using NMS or > using signaling protocol extensions. Using NMS we need > to know the complete topology and "its current state". Using signaling > protocol we can figure this information out either locally or > by polling. > This is the case being called LBM. > > Please comment. > > - sudheer > > > "Bernstein, Greg" wrote: > > > Hi all, to reiterate what Maarten points out below: "LCAS > takes care of the > > hitless addition/removal of this trail to/from the virtual > concatenated > > group in service.". Eric's statement concerning LCAS being between > > PTE-to-PTE also applies to Virtual Concatenation in general. > > Hence the SONET LTE layer (SDH MS termination) switches, > i.e., most of the > > ADMs and XCs out there don't care that the signal is > virtually concatenated. > > Hence all the current stuff in the SONET/SDH signaling > extensions concerning > > virtual concatenation is just end system information and > not needed by the > > network. > > Is the LBM work really aimed at the virtual concatenated > case? If so it > > seems unnecessary. Also instead of further complicating > connection signaling > > couldn't we abstract things a bit to have some type of > grouping/association > > of multiple (pt-to-pt) connections together rather than changing the > > signaling protocol? > > > > Greg B. > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Wednesday, March 20, 2002 8:29 AM > > To: ccamp > > Subject: LBM comment > > > > Not having had time earlier to read the LBM draft, I only > just came across > > some > > still VERYY INCORRECT text in > draft-mannie-ccamp-gmpls-lbm-tdm-01.txt. > > > > >From section 3: > > > > "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling > protocol enabling > > the bandwidth modification at end systems and setting up and > > releasing circuits provisioned and configured through Network > > Management Systems (NMS). However, LCAS doesn't apply to > setting up > > and releasing bandwidth at intermediate nodes. This > means that LCAS > > must be combined with an NMS system in order to offer a dynamic > > connection setup throughout the network. Therefore, the > advantage of > > using GMPLS is that it provides a complete integrated solution, > > allowing for a wide range of traffic parameter modifications." > > > > LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be > > combined > > with either NMS or ASON or GMPLS, which latter 3 take care > of the set up or > > release of a VC-n or ODUk trail. LCAS takes care of the hitless > > addition/removal > > of this trail to/from the virtual concatenated group in service. > > > > >From section 3: > > > > "Using LCAS in parallel with GMPLS implies that GMPLS traffic > > parameters may be modified without the GMPLS control plane being > > aware of these modifications. However, GMPLS provides native > > capabilities to modify traffic parameters of an established LSP > > since MPLS-TE signalling was originally conceived to > allow traffic > > parameter (bandwidth) modification." > > > > Using LCAS does *NOT* at all imply that GMPLS traffic parameters are > > modified. > > NMS/ASON/GMPLS are in full control of the connections setup > to support the > > virtual concatenated group. > > > > Regards, > > > > Maarten > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 17:55:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: ccamp-wg Subject: Re: Generalized Signaling documents Message-Id: Date: Thu, 21 Mar 2002 19:54:14 -0600 > If you suggest to limit the list of authors to only "those > who wrote say 30% of the text", then are you saying that > an RFC can't have more than 3-4 authors ? my calculator comes up with similar results! randy Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 16:00:24 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Yakov Rekhter Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Fri, 22 Mar 2002 00:59:45 +0100 MIME-Version: 1.0 Content-Type: text/plain I suggest that the group of current authors/editors work out a reasonable number of people to be on the list. I was giving guidelines that we (in IESG discussion) have used in the past. Bert > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Friday, March 22, 2002 12:40 AM > To: Wijnen, Bert (Bert) > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg > Subject: Re: Generalized Signaling documents > > > Bert, > > > Chairs and authors/editors, if/when you go through a new > > revision of the drafts (any drafts), pls take action > > > > - to reduce the list of authors on the front page. > > main contributors (those who wrote say 30% of the text) > > can be on front page. Others can be explicitly acknoledged > > in the acknowledgement section > > If you suggest to limit the list of authors to only "those > who wrote say 30% of the text", then are you saying that > an RFC can't have more than 3-4 authors ? > > Yakov. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 15:40:29 -0800 Message-Id: <200203212339.g2LNdiT05000@merlot.juniper.net> To: "Wijnen, Bert (Bert)" cc: Kireeti Kompella , "Ron Bonica (E-mail)" , ccamp-wg Subject: Re: Generalized Signaling documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16516.1016753984.1@juniper.net> Date: Thu, 21 Mar 2002 15:39:44 -0800 From: Yakov Rekhter Bert, > Chairs and authors/editors, if/when you go through a new > revision of the drafts (any drafts), pls take action > > - to reduce the list of authors on the front page. > main contributors (those who wrote say 30% of the text) > can be on front page. Others can be explicitly acknoledged > in the acknowledgement section If you suggest to limit the list of authors to only "those who wrote say 30% of the text", then are you saying that an RFC can't have more than 3-4 authors ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 15:36:46 -0800 Message-ID: <2135200C183FD5119588009027DE5723FD2EFF@wntcsdexg02.csd.ciena.com> From: "Ong, Lyndon" To: "'Debanjan Saha'" , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , "Ron Bonica (E-mail)" Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Thu, 21 Mar 2002 15:34:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" FYI, this is a relatively new policy on the part of the RFC Editor, there is an explanation at http://www.rfc-editor.org/policy.html - it is being implemented in other groups as well. Cheers, Lyndon -----Original Message----- From: Debanjan Saha [mailto:DSaha@tellium.com] Sent: Thursday, March 21, 2002 2:58 PM To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; Ron Bonica (E-mail) Cc: ccamp-wg Subject: RE: Generalized Signaling documents Bert, >>Chairs and authors/editors, if/when you go through a new >>revision of the drafts (any drafts), pls take action >>to reduce the list of authors on the front page. Can you help me understand why this an issue? >> main contributors (those who wrote say 30% of the text) >> can be on front page. A lot of people contributed over a long time and I am not sure if there are individuals who contributed 30% and more. >>For details on these RFC-guidelines, go to the www.rfc-editor.org >>web pages. There seems to be a lot of material on the web page. Can you point out the specific area/document where this issue is addressed? Debanjan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 15:12:24 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3D59ADB@mail3.tellium.com> From: Debanjan Saha To: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , "Ron Bonica (E-mail)" Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Thu, 21 Mar 2002 17:57:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, >>Chairs and authors/editors, if/when you go through a new >>revision of the drafts (any drafts), pls take action >>to reduce the list of authors on the front page. Can you help me understand why this an issue? >> main contributors (those who wrote say 30% of the text) >> can be on front page. A lot of people contributed over a long time and I am not sure if there are individuals who contributed 30% and more. >>For details on these RFC-guidelines, go to the www.rfc-editor.org >>web pages. There seems to be a lot of material on the web page. Can you point out the specific area/document where this issue is addressed? Debanjan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 14:23:35 -0800 Message-Id: <4.3.2.7.2.20020321171935.04dcf780@mo-ex1> Date: Thu, 21 Mar 2002 17:22:35 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: Generalized Signaling documents Cc: "Berger, Lou" , "ccamp-wg" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:07 PM 3/21/2002, Wijnen, Bert (Bert) wrote: > > -----Original Message----- > > From: Lou Berger [mailto:lberger@movaz.com] > > Sent: Thursday, March 21, 2002 10:53 PM > > To: Wijnen, Bert (Bert) > > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg > > Subject: RE: Generalized Signaling documents > > > > > > At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote: > > > > >Chairs and authors/editors, if/when you go through a new > > >revision of the drafts (any drafts), pls take action > > > > > >- to reduce the list of authors on the front page. > > > main contributors (those who wrote say 30% of the text) > > > can be on front page. Others can be explicitly acknoledged > > > in the acknowledgement section > > > An example is RFC2571 Acknowledgement section. > > > > Bert, > > > > An alternative approach is to list editors on the first page > > and list all authors in the authors' addresses section. > > I've seen this used in some older RFCs, > >If you point me to specific RFCs, I can try to check them and >try to figure how that happened. What's to figure out. > > I also ran an this by > > one of the rfc-editor's - he didn't say no (or explicitly yes). > > >I did discuss this with my co-AD (scott) and with the RFC-Editor(s) >this morning, and we are in agreement that your alternative seems >not acceptable. Have you checked how it was done in RFC2571? yes. >Why would that not be good enough for acknowledging the >contributions by the various people? I'll send some private e-mail on the topic so as not to bother everyone else with the discussion. Lou >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 14:07:40 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Lou Berger Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Thu, 21 Mar 2002 23:07:08 +0100 MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Thursday, March 21, 2002 10:53 PM > To: Wijnen, Bert (Bert) > Cc: Kireeti Kompella; Ron Bonica (E-mail); ccamp-wg > Subject: RE: Generalized Signaling documents > > > At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote: > > >Chairs and authors/editors, if/when you go through a new > >revision of the drafts (any drafts), pls take action > > > >- to reduce the list of authors on the front page. > > main contributors (those who wrote say 30% of the text) > > can be on front page. Others can be explicitly acknoledged > > in the acknowledgement section > > An example is RFC2571 Acknowledgement section. > > Bert, > > An alternative approach is to list editors on the first page > and list all authors in the authors' addresses section. > I've seen this used in some older RFCs, If you point me to specific RFCs, I can try to check them and try to figure how that happened. > I also ran an this by > one of the rfc-editor's - he didn't say no (or explicitly yes). > I did discuss this with my co-AD (scott) and with the RFC-Editor(s) this morning, and we are in agreement that your alternative seems not acceptable. Have you checked how it was done in RFC2571? Why would that not be good enough for acknowledging the contributions by the various people? Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 13:54:42 -0800 Message-Id: <4.3.2.7.2.20020321164905.022c3da0@mo-ex1> Date: Thu, 21 Mar 2002 16:53:13 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: Generalized Signaling documents Cc: "Kireeti Kompella" , "Ron Bonica (E-mail)" , "ccamp-wg" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:13 PM 3/21/2002, Wijnen, Bert (Bert) wrote: >Chairs and authors/editors, if/when you go through a new >revision of the drafts (any drafts), pls take action > >- to reduce the list of authors on the front page. > main contributors (those who wrote say 30% of the text) > can be on front page. Others can be explicitly acknoledged > in the acknowledgement section > An example is RFC2571 Acknowledgement section. Bert, An alternative approach is to list editors on the first page and list all authors in the authors' addresses section. I've seen this used in some older RFCs, I also ran an this by one of the rfc-editor's - he didn't say no (or explicitly yes). >- Split your references in normative and informative > references. > >For details on these RFC-guidelines, go to the www.rfc-editor.org >web pages. > >Bert I'll make sure to do both of the above in the next rev of the signaling docs. Lou Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 13:18:01 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , "Ron Bonica (E-mail)" Cc: ccamp-wg Subject: RE: Generalized Signaling documents Date: Thu, 21 Mar 2002 22:13:01 +0100 MIME-Version: 1.0 Content-Type: text/plain Chairs and authors/editors, if/when you go through a new revision of the drafts (any drafts), pls take action - to reduce the list of authors on the front page. main contributors (those who wrote say 30% of the text) can be on front page. Others can be explicitly acknoledged in the acknowledgement section An example is RFC2571 Acknowledgement section. - Split your references in normative and informative references. For details on these RFC-guidelines, go to the www.rfc-editor.org web pages. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 07:29:27 -0800 content-class: urn:content-classes:message Subject: RE: LBM comment Date: Thu, 21 Mar 2002 10:26:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624101BC6@OCCLUST02EVS1.ugd.att.com> Thread-Topic: LBM comment Thread-Index: AcHQfyIIe33EQwjwT9+DMBHbEUT3UgAaXxsQ From: "Brungard, Deborah A, ALASO" To: "Sudheer Dharanikota" , "Bernstein, Greg" Cc: "Maarten Vissers" , "ccamp" Agree with Greg and Maarten. Hopefully of help are some tutorials from the last T1X1 meeting on = virtual conc and LCAS. I've given the links below. Key is that LCAS is = not about the addition/deletion of an STS-x, this is handled by an = EMS/NMS/control plane. LCAS is about the use of the STS-x(s). It = provides for the hitless use of an STS-x by a client signal e.g. hitless = resizing of the bandwidth used by a client signal. It is based on the = premise that the STS-x is available. And, LCAS is only used for client = signals using virtual conc - it provides the hitless resizing for the = client mapping. The only client signals defined for using Virtual = conc/LCAS are the GFP mapped clients: Ethernet, ESCON, Fiber Channel, = FICON, etc. Deborah Links: LCAS: ftp://ftp.t1.org/T1X1/X1.5/2x150440.ppt Virtual concatenation: ftp://ftp.t1.org/T1X1/X1.5/2x150450.ppt GFP: ftp://ftp.t1.org/T1X1/X1.5/2x150460.ppt -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com] Sent: Wednesday, March 20, 2002 9:15 PM To: Bernstein, Greg Cc: 'Maarten Vissers'; ccamp Subject: Re: LBM comment Hi Maarten and Greg: Can you help me in understanding the following case? Given: LCAS is used for "hitless" increase or decrease of capacity of an end-to-end pipe. Question: How does the end nodes (of the pipe) know whether a given increase of capacity is possible dynamically? My view: I think this case can be addressed using NMS or using signaling protocol extensions. Using NMS we need to know the complete topology and "its current state". Using signaling protocol we can figure this information out either locally or by = polling. This is the case being called LBM. Please comment. - sudheer "Bernstein, Greg" wrote: > Hi all, to reiterate what Maarten points out below: "LCAS takes care = of the > hitless addition/removal of this trail to/from the virtual = concatenated > group in service.". Eric's statement concerning LCAS being between > PTE-to-PTE also applies to Virtual Concatenation in general. > Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of = the > ADMs and XCs out there don't care that the signal is virtually = concatenated. > Hence all the current stuff in the SONET/SDH signaling extensions = concerning > virtual concatenation is just end system information and not needed by = the > network. > Is the LBM work really aimed at the virtual concatenated case? If so = it > seems unnecessary. Also instead of further complicating connection = signaling > couldn't we abstract things a bit to have some type of = grouping/association > of multiple (pt-to-pt) connections together rather than changing the > signaling protocol? > > Greg B. > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, March 20, 2002 8:29 AM > To: ccamp > Subject: LBM comment > > Not having had time earlier to read the LBM draft, I only just came = across > some > still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt. > > >From section 3: > > "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol = enabling > the bandwidth modification at end systems and setting up and > releasing circuits provisioned and configured through Network > Management Systems (NMS). However, LCAS doesn't apply to setting up > and releasing bandwidth at intermediate nodes. This means that LCAS > must be combined with an NMS system in order to offer a dynamic > connection setup throughout the network. Therefore, the advantage = of > using GMPLS is that it provides a complete integrated solution, > allowing for a wide range of traffic parameter modifications." > > LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be > combined > with either NMS or ASON or GMPLS, which latter 3 take care of the set = up or > release of a VC-n or ODUk trail. LCAS takes care of the hitless > addition/removal > of this trail to/from the virtual concatenated group in service. > > >From section 3: > > "Using LCAS in parallel with GMPLS implies that GMPLS traffic > parameters may be modified without the GMPLS control plane being > aware of these modifications. However, GMPLS provides native > capabilities to modify traffic parameters of an established LSP > since MPLS-TE signalling was originally conceived to allow traffic > parameter (bandwidth) modification." > > Using LCAS does *NOT* at all imply that GMPLS traffic parameters are > modified. > NMS/ASON/GMPLS are in full control of the connections setup to support = the > virtual concatenated group. > > Regards, > > Maarten Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Mar 2002 01:14:46 -0800 Message-ID: <3C99A3EB.65EFFE13@lucent.com> Date: Thu, 21 Mar 2002 10:12:11 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: Re: LBM comment Content-Type: multipart/mixed; boundary="------------4C2166AF110615735207020D" This is a multi-part message in MIME format. --------------4C2166AF110615735207020D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have created a short document to illustrate where LCAS is involved in the connection setup. (see attachment). In principle, LCAS isn't involved in connection set up or release. LCAS controls if a trail is being used to forward payload information. The set up and release of the trail is fully controlled by NMS/ASON/GMPLS. E.g. when the bandwidth of the client layer link that is supported by the virtual concatenated trail is to be increased, the network engineering controller will request this BANDWIDTH INCREASE. The Call Controller receiving this request will send a Connection Modification request for Connection X to the Connection Controller and it will send an ADD member command to the LCAS process within the virt conc port group. The ADD command is now forwarded over the VC-n port that will be the end point of the new VC-n trail. When this trail is set up, the LCAS process at the far end will receive the ADD command and will detect that the trail signal fail condition has cleared. It will reply with an OK message. When this OK message is received by the near end LCAS process, it will start forwarding payload information over this new trail (after it has send another message indicating the exact frame which will contain paylaod in it for the first time). Now the bandwidth is increased in one direction. The similar process is performed for the other direction. I.e. the far end virt conc port group receiving the Connection Modification request will also receive the ADD command (i.e. responsibility of the network engineering controller or call controller). The far end LCAS process will now issue the ADD command over the VC-n port that is the endpoint of the new trail. The near end LCAS process will at a certain moment receive the ADD command from the far end and when the associated trail signal fail condition clears, it will respond with the OK message. When this OK message arrives at the far end LCAS process, that process will start forwarding payload information over this new trail (after it has send another message indicating the exact frame which will contain paylaod in it for the first time). Up to so far. Regards, Maarten --------------4C2166AF110615735207020D Content-Type: application/x-zip-compressed; name="lcas-gmpls-pdf.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="lcas-gmpls-pdf.zip" UEsDBBQAAAAIANlLdSyg/rnih6EAAMDwAAAOAAAAbGNhcy1nbXBscy5wZGbs/QVUXcu2LgpD IFjwENzd3d3d3d3dCe7uDsHd3R2Cu7trcA0Q/EHWytpr2z1n/+3e/51232pt9jHLq1evPr5Z o89eNQik+QUpaChpsaEItrbHp6EgsKFoqLGpsa10TaHY2aGoxA0sjeyNsWloXtNkoagETczt DWyxqQTNdewN+A30rPQNsKE4OaHs7G0NdCygIISDd5WWbbf74J7ePXWzi5LAvzO03s7/zi0n X00QffQp+VoxmRIJDFLkM49Xn0DYM+eqHRD3VzQlzJjAuGFGgTHx21RO9/sRmCM0qsp3kcCx UVHX2+ES5xm2UpanGea0XRkDLk56atDX7j+QY6vu3AgbqGoOQnKdR4eJy6dxib7VckY1DthR vnAKOtd+E0qfd9J/WoYyyNrlAQATMA8Nnta7YELfCyKA1s9GWpj50BOiZrpsb15DEx/aR3m1 mWmzEWha1H0s/a0/Naro8QsybyxDJIxz9KeHOCX9wY+ahjLpQbHq/Q3GKTF8RLUcfTA7NKHE pGbpsVQmChfVsiQDaYB2556NT8+DB7yGDx+TOTAJzv1z0qfc5Wy3ouiHvxRT5qDKFsOkHn9R 50Y02FHGZ8frjeDH/3bdRNwBlw4OK7TjJrwNxI1pJPGOzUlALqahthRtAbSx31oT+oVQ3+7B gBExeUn/OAmdhsIpeyrbuwRiUBA4oSWFzZZ0qLl64L6TjNOtWpmneM8PawA9hgpHojppDHvf rc2Lr5r+RTEcHw23+n3luIlPBlks3OzB57ADe969AftivTiDyi+fGe8WL461BnRT5m4/ecee H5GT3qJzMTOWSndYWAq0uqPsQpELHzn1nG/5jaY5QEEgoP3Iq7Y2Z4xWETcDYC2bFpZWmeE7 hkpNoG2cdRJP47ChWggdGJyNCIyjjoNOlaYyvG8Go9rRoCfyueW83E5I1L9GKZe/WEdL70fn HkV7RKUGeJYH+KwBtoU+xTFTTGglM2e9UHX/yM1hZUekggqCNGvkXbHVIrk/+OPdLOO5+dP9 O1AeRQcVfVjnxEvyg/fPP37QMnHLzrFw5ZZTEq0opHdwIoFpUTATHPga4Wz3aa1jz8yDzj5y Hu37niyJM+UYLRf7kpN5xe1cZi63OO4fTTjCFk+QoqrDoooIGRAWG8j0p+7dDuXqZEtSH6QS qHbnWlLiTRqWEztiXXDHqWAS0PrlTAE3s7xX/5iJDBCr6PdCx5pO22U6qewD8yk5ZMcTeRCd pK4FwF9Tu9MQAguzl9fnCGwg5UyE+965RnMtd5Rfk0dw/3vB0eFYZnnBgnv0tvjOj0Jb++PK /h/U5iibzN0iskIGJLHSQty0imRq3iwBsg4jUqAR+zatoOr9ce/tGUajCtQGF/boDx9R8eZ1 ntK/tSLE1JOJfi1rm236BFBBVpO6LTNZZ383E4W/fy6BcU4OA2ASuWEPYMzSMACpl5FNy3qJ mqJCwnJ3z/0+SOQeRMvuHdEMmDigJ8ThFlKrqWt5qPiwD3cNQCiF7qg+kpH1CIohtOY1enxw azJ3Nn8wIKB3tm7m2HfFDnlVU1huduknD6igQyWGieUJrB7ZOYuw9A5kvCY3hqN+0yoOavnR 3CTigylUM8XpdDNveBMVGBQ6U1cbHtxZI141lgN/geiCjxwMOkkllILwOA74dfqknCdQoIeS 9iCYH3yPNidugo1SBjcqM+lQWMHNaENFQFNZP220F3NaRAv+8DfN6+zzoyT3OjmQlg9O2SM/ fYZKBSexVTiX/DFKYT9nmdgnrHMEpFKG9QjnnDaKeQynUvzinszBjFetvO05/2M0EqYeU0i2 ikHvOQoohPsFiHDihY7ws6o8ylXrC/THZ9Z9USAtuRjWYnaZmNwheD3nKdnP2n6o3/dh22xI dE0/P8x5gtXbQNVaDbA2zBa3koXmSH99Fwj9LgcEUZyRpdJFcUAcNMVZNUHOvoLB2PNFkvpe 7gI+yFR+Qem5BQ8Cm0uOprgXTHhHWHhqFboP01yjDGk7L/3CDlnX99wloj3vyHi6Yrs1L7px Zp3LPRn8qHyUA3i5PTSDtj02uhMRPMTB7mHs+Qiui12PiF3pk+r7ImbudPtu5Z34M2sARH6O 1P3za14+zHOyoTYlBbsdd/5JfHmF5vFZugBx7+TVEnWqTO5rC18kDyUFpPWMUEK+afVPuBnX Wj2rhHsk24tDpN5AwVtJGYfGKRdjRzn9CIbidFcadRfbkqoxCYAElbD6hBQ2yvNIc++m5GGr RlfBPEdEVIGCacY5KqhOr4/BdgECp0j7zs2ik11ktGaPUHyecDB3Lvv4G+n5TB3Cz3YFW5oc zi0cor/kK5oyhJV8Qz0aZe8NNbBB5BQi/kIdcjIsGAKEPnldEbG+RFZ8rGB3DzCDzDVMmMa6 bVRcVrLiPumejiOY+V7DEvRrPLvomoEKAYq/lNgVfnhXqmi4HMixAaNGtJxKT2txbYt60y1Z ZV2H5GD5YJ56F5VaocR8DkzS/ITXwbLo7c7A577ySDrM+H1uHEGISJnb+evDYO3k7JGY4CB2 g4ONqnvtI/Jd3B7GiriwTP59Dx/YbngBhrGwJQ22MunTxXm57+mfouH5AOEoV6WpGWUk94RH 0CGak0gF4PWmLsyrF/KvOVjX5RAKrtkQsanGMGIW29evsSfRqIGTzTX4iFfr/aLu+z5/i4Gd ALOxAS5uEApiSvIDsCLQ0gHafWb6odSNu39fZgGGMBwAsftYxMvSx6nN9+VdpzSiq50HoZDH yqWsF7SWAzXkcmD0CZmvs0ZsKOqGGphLlg85NpfhkSpUQ/2wW3cCuAUWxzr4RyA67lRHCRL7 EihQa77b0FtEY/AljErb/uwdjuiFy/sRZ6G48txqBbTi2b2pkIOGLPTZnVLMSqRkzElHnmIO fvVuTZyzxPGWrG9FyaR77qqXSQVWMUoAD/27xw6cGqN1LxiDuKFdsefM/okk/JyI2kw7YWtf BcZM3o3mOgr/qG22ssTwXmTgvJUqPeo/EVk/tEoyEruuK+P5RiEYHeC0RerykfSrdxG+51jk lBhXsQFa9w3KXqDgbRGGZgrEIqE4I50cHT5QP1gUv0J/7HY3d+Zq9SDutAZF3IfvXuE6LT9Q 2XjQXFdllMjNwmkVrholsnOIeblBZvnIE7jsQSEq7jGgSXwnQlI3WavnWwz7582NeAoXIkA9 tbLigaEJyMlDJ3E/i5I4s2JN/fAqi2IA3wF7Jwhau1AVHg5DGHKMtFeFWw52VBfCWxYxSbOK tg+6JdXMwWYFWHQydRaE6M+aMApezMk7uQIGm36wJ5kF3rKWW6mlwIu0dc+YtQxRyHYg7KxW 0oiMZBCzd2hePRryA43Rscq348PnMmHzaHdBBIfYQtwu21B2xrxJ349U0+9M69Fy06PV5xXA SlyPgZ3MnLcpbngijGIX7693N23uYLgJRnnIoqDZ7k4up4/ejW6G2J2cdOvkwRAaDi3FZmoh L/jDkNbyCbLPtpB6Z0ZetbfyyISd+dHnfQW38XdSviD0jusTbzBhWPHzXq+WkPCATVf1oRLH SEUavERqQjieNYphWhCIp28T8SuF25Yz7VxE3po1gktwlhwPqZ4Lc10K48L+NiZzzWMf4KET NjsXahSzeMqGBJlYy0gah8QwGOIG8zQt/05Mpi4yksrOTVNcKSPh1lPt8Uc1LhdQR0LoLJVu awK2F3UFgEFyn5v7FVUD5UsPlIGl/u9LydfQ2xr058LzLUDLSEv3K5H+TwtUeWdrA2wqaR0j A6jXq62BpT02w29rVVkDOysHWz0DO+y3coJWrzk/A9TYjG8FsF+DNNjMv4K02DS0v8J02DT0 v4Vfl7ZU0rZWenIG9tg/s3+m8L229dqRHfbPpfLPtF/sMv2LtTPzf3ftXKs0aqnRBOXxrqNb xRDkvA7/0ClZPwYwJD90ibh5gHC7SYTduvxDv2+rB0E0vMjqtmQ1MSR+YgcuQQzWeElKaBQ0 iXnRjkXL3e5X85Ozi2lHm+s587zg+pRIpD1tjbDrbyeOLJ6ey5qPT9fDRyen3+3dHq0f7G+t l9pXOdzXLLEkC/CmtDhTOd1YPVjS0z2WLJ8braNgsjClI5dGAJtvlyWVjMpLFlAHpakpc8sv vqJsU0Kpsy7HU3L0HO7T9ooXI4pjXniPcl88OatFrllGNGRIwdzCZJxGaDV4ontyca55Mj+t cTijwUTwVZczO3782Ox8u9m9PX1R+3R0ejS/va0UZldjL5e/OtVQZvs893ynl6P2+K1iuTcl 5YNwXgCqrsk3t0XK1ivxdSVU8ZwaAlR4cnuZ+4yG0HWPdoDl3WPEQ4UqeP753uNefhGSo4MZ HioQx8Pqj2EPfQNpNBwslWR4Jh/tLXLmL1jl7MHGQDCqoZx1iLGOWXtGifg82D5lBlegvRcF ETWMGxFOlpKdI8a5Et3LI+cb1gwKxqEfKdZBDJ/5wk+MTbGjEx0ocIrYNG1rlQgW1IVaZQwj HJpyRIVHBYOCO9xoiJJIV38zf19Qr+KpaKxz6Q9sdp+TiNOsJd8EsMC9YnRTKDfu4iBHlXXr bA1t9AXTwVEscKs1T8dI/cKWVuNh8RLZ1sIMrcpfXXYcNswKtFbZDisjd8I3ERG9rXb7m3r3 GRKKOTuMJxc7K4d0jXM7vdE0IAHuUCW9vLUil8cgHVVna6NUTuaEAAwKEd+TVXjj2GKc9djc RkX5026HKwjDKWYRmMvNPfljDZoSqTyEGQVJWvrEl42t/HU74k3skkQhuCN+0OYePPwnW3dM wQ/bqNCUfKiDdnvyy0bP1EE3loQQ709BDN3SA/tAIuGGShN8vdV/TJTM3zoBxbnWae9zRuLi C+5ETxhVTGALzvDxkdqzHlYR7AhLObtaJjiKDoRwulMvuNqIgfTAoqoE18TpJA88jno8P9kI AGxXgbcNAOUkagvDXFUJMvHodyLPPGUWAuRTRia1i6ZOynUwGlIwPDft01D4di5wjt1fCSri xaGoYuH5UEokFmjlHYMBR6+wWZDtOyNkRPgOdrvF0BYeYMHi3L9jAFPyDNhskJMxFWC5zmdj l5VkTXcbxo+wgBxP7lOm6TtH1tUDZtC99haSTh0dp27/3mZKldYNtASvzh4uuuJ+xBczq5xc NREF1GjEdHWwLcDaD/rtOtNeB7e8W2TgM46CsxLkR5vlcQK+b+CPjhuO38bsjZXH2b+V0HmX UPoEyJSNA1Z/umMOrXLqcuI7ZE6aING5ixQjVdwolN79nBqAEdjb33nIi8hcPENQ3qz69SHT NKbqIfMLyJbdBvzpvcLBkeJWJWIIY8IDAFF+PO4pFZA0KAVg/GdIL98swNn3RBPfqxmC/O2Y 84o5rvqsvyxza5/PgMBLlOyAVtrzjyoLQArSobfy+iKXeisR0wfh0IfAI5EcUZHnCtewUymz IL/C+xc+ddv9T8Tjlfdhmbk6VC/BefaPPbKPA/r7uZHig8JDW3RpIlqgQGJE3cOIaoUy0FnY hKS8JrQE4yj7NIcfNm2lP2Jq1IbYYoSDqEMvVTHiAtPlO3HCBo7wCxtm+n/LcJdJr2TeH3CR iaCACnWRDh6sC5MbCDzzEqRhNDIpT4/ppn62Ol+Yfsz4ATZXEilrnaTR4dFJvXeuNGSnWDNY qwX/HnTcI25uSPjqXpIN8EtpB1fWt25mcFgGctMPcPmVKR5zwhZrQqLXQ646sghBHLCljXXI wMIQAtCjXp2fKjmsQcQBSrBlC8U6gZdTnEFp0T5zoyaBK813/pjk+yQjRp9DplahWbLT7XxH DCX+jZyrDNhdCKVSJJdfQp9mBK6M5qP6y5wLCIPBnPJgSQv4F9hWbuEyChw7YXxT1W4l94Av CDf8kNlEhl51qNEgfMa5CngUqE/Jfu+myCvOyHPD4atz9UWGqMVQ3CY/QzjEmUDpBi1cwqut jXpqG0Zqs9PyF3QwdPGLiCzfiQIIejpLBsw/OQhGqgIgfxbhKsAcs+qKEoJSLxLceniVMi6g j+AEKw6wLu4uokFX0thda2EHcbI3okqmkTsvYJKwQB7i7sxUUBFRPLLGkbQDBFVvJyhDwB5C Uc9ht1DADd2C/5mARGtbB4gkmfT0Ilyuk/JZr24qP9F0IMDonf7Tni3Vw41dS9m+1VaUspU/ uMx+pQm0oGlO6ojucUGUVPYXWgzhVDh1JoVoRg3NS4ryl97glNLCBauiMTE18fKODguqNXZ3 Ts70CKnllsSKhluqtZVW15fpm/tNe9Y1zlWO1PoGz/T7SA+2OlGq4cbvG/lseu8yW26pIgKl Aile1Hmu5tdP08vbLV+cP7vd3z8X2LTh3UVbrbl15PVvK+o1ZJ09g6VT9PIlupX6iF/BcPXv fcxJA/ri8S1Bb92jr1oSiUQx3/2SXW8et8zqyTyXrx7roJxA4D6VQKDZbAnXfSxCCXlAcvNz l0c/x4Ra0xiYxJq2ckbZPCJlY98xpXdNMpTi8GlEfLamEETEchOES84NdxElbrzgsQEU47bG yYlPS9d1jU3kZX0hwyLfspDxNpoLujRt62rd52qkDByKSNmdS6LZ2fvE6dNLJTVWgoaWh3Bu hwVTqpxl1ha7MoQ7Oh6EyKmu0rEpedE15jVANhymzr4N/zK54Rsl7mOPazZapRlOrSeXJ1Mh u7OrsQMJKZOSUart46iUDG/19NVHl067swMEKw5349AyMJOEbQPw97qVIO2hE9h9M5nfPuHA +jKkrkkEGzoLgCTzKK7pXEMPK4Yo4OCFiUEnXSs/7f+46MOEFJpHA0RsFnZQfVY9O99Tsi5I fljUD1OoKHG1bDWQQQ+ToeibeldYpMAxKDk3vEn9dde6GVlCZpjfKhQTCXQNhqibgtCHJnJD btdDGEGCqIrUxVfL1I4rNawwDtShHqtYhtBwmdUMakxVE27ckY2mrC8Jx8Vm7yiGYK4HawFq +5Y8gGOqbRU2JlEtKECbfPbbHGTtCuiZ5R2627y9RdA1iEsYkpLVUwJ0793N3V0V1DM6kOGP qamEuUfksCcDXk24VqXc+XfciqubvMC2V6ZJUdKYF6gSGp5xJNDegudmzcUay1pjFlQPQICD gz+m/DVtE592PRbL11TTqsCTxdc0lj8LcI+25PW/mF7PdL/PSYikaON128+zwhEWVRk/0NXz ZNmMQ8Y4r8J3Fqlci+U31q2px7OtiDAZWoLfseCmAG0Rk4fwrskoKsn5Yc4btMgydzv14eCO 0l5kZqgOi4h5voMlJotFzB7Zd7WpcWAbN1AAOnSF3DZnl9GEZYocRkUUjUB/iNaYrUBfcsgt uloQXEW+ulD3BIrcVyCgso8JEZp7RvdFujIUhEYZ78sugq54+A1J0HDSrYcHKOc0B16fyn73 qjkYUs75mXh0XHX66jYskr+c7rEjTNvBfkYW20NBx2Fl3FC1O/ppFdcM5z0+p4sFltHwLZMU g4Qc+wMYZBDR0YwbFbXgYJjbScyOHJPoQGuMM4HaUSG5A7C2ghHcqG1iHboJDkwoO7ltw8Aq rtbhZ2rmwNRE9KAuTnNVN1i+FQt5J7RZqB+7II86Jzk+aqOWWAJUD0G6KQRSa4ZGANkXxqnH CAThzr11ird72scNcG3n+zlZ7A9Bmp8dY2aUMlL63IjgBcqtHJAzPOZEe58I4He7oWF5prj5 6LkMfX6TFhQ97JWs6OvqQGdWuc91OVZlhQTHTpQQsMCdHawhj1hlRoIamRdIMfzFUZOixWGF +ruS4aKAO5tLRO1AtrBZLbdXpuOEhfbCfLBMP3Tq0d4tWTCMDOqgRHWlDcsWHysrwmB5IXLF Q9rRqbm1xFT/0t2CbqDWMthOskw6VW2wvtsO+dBTBpRNkmAtXb7bRY+zdw5RM2NERvdcuSGs JAGD73k3te8+L4uvdDJdoTpJMuOSxPNIDBGGej/zUDqhdPiKUeTFs5BtP6uKdoj82ejQOzn8 KkM1xQnQrCyX8PIR5WmOre9ZpuYWWTwqpS2Wqw5HzWrzqy5Kxvt8s+caKFkwWwjlXP5Hkt5l jec6bFhj9A3YagBoS7ph1SPYZvP1eWJXOHIibIvTk3um8N4tXwR52nHmggoq63b5qylFPVVQ 82FXKfOkJ0vvgJTEEsLfKj2FjqrTb23E78roSyfcf68ifOa+YPEd2zO3a0ye2SrrAq1sGTix p4sFFD3nnDNB2GENm2vbZCflFIZ54ld9ilE/PDbG7SXI+kAhjCFSUjWBBZnXV5ETKn1ASAqx Kh3Sxf/dpyxJxO4L6qcjA2b/0zVDaSqQTF5XIml/mHeKELyF1SufF7JUMbYDGSJoJNZLEtbq +XyJlKO3AEQwunWkEeXVNThcAvH54WQ06FIAYHkuoDDmZhfA2Wy09RA3a/vVu3UqYuC+cVzw uOwTtR8m7uCw6QSVPOJb7Blh3hVb5KxBu28+NC6CwEerWcIXrgtK8vqx8GfSzoMphPBmvnXt /dY1IAscXibRIQ3Hh1Rt+WsXbKIZcf0luhpw7HfNTxps/hY1/XwTgQAY+aQJjDsmJKMNCsrl sSkWfOBLEpVdirXMI6rEiZDEiJyVJY+SWt/6ogXWpCetGhIVyIiLGLnpqkq4BYFQpsa/R+Rl aNm9v3POipGpd0YMTg4dGPxUS2W7TubKjd7P7BtmchRQpbE6kVWCFg5Kw1/v4LtrYyiowiSc eAUfoBqdbKPMOKI6I5jsrHjYUDAT91FfiXGfL/HLJHextKlhoODFUbJ0G3LmEAl/pW0xXHlq aBYFelkgRuls1RfECB94fUJTG0PczKQUGy0mgKGX8VGMqNQU/OFinVbnKlP7lZ6DEJa4QNp8 lDH9+EBn8o8xtSegNUOiMYGlPTJisB9nk5OcaUv6yjy4Utz5ehfCDX0SfmTlEQCyFiFjkIF/ JJQCjEMRDJINekf8IfwEemJI6JF6A6/LNw5YIF/fG77UTxdmy4lGVhAWjgCvbNJVsHiAKYYo tX61HySSRcUwdUjUHDY5kHpXWGWByU7SQcUPB8/GviiMvDk+wmCiqL7Mhe3Q/Cpwagl7jAo0 bagft04fnxyNdirloZ7bmcanegqustSPn5oEUldFwGRdV8Xd0IRb0AdkIKmO9COgADW8i6+M DX+/OLZVbxGBl3gfLvXHMsrFXUah5fq8xKuSghKJewV4Qh2BwPBQ8yz3mHdihCL2vCbD/aQ4 tUidTdSZ2OJA0IfxVEyKwhf26pbTxSwzvfC9e9gmNGeL3+pmPhhcRvM4vqMUc1HUQtmrPryh f9plv9YLLCwT/dCAYofm0NVKz6PK03K1d12ROPytoP9oO5GKfS0oR9/vg6ZkXZUZ/tJ77cha 6DnZyllzEJ9Vd5VTzPKzDKsIpoN+ZvUh0Ma8RF0WY1waxe9ulfbC7AsHeiGODnbXd/YOza6p 78XuYq+2z7cGL/21C0dsJ8nXOLnUxc7Kw2CWhIw16K5XiyfscMCbFJs2r6XBf2iBV7gNiquP SAQYuBSO2pt9LbfvaQRuq6kMpVrwL0oLGIU5mVoaGSruHhko/7o5Njaeo8JVY+tiuft9BELT u2rWsCBoJ8LR2G91pUe0ZNACrU3SarlTjg66YNUtklEcTsSMroT6WwK4nWUyrGGDxVfGDouP JzOUX5o0viD3Kyre3UERY4nVUnSsDAFOqg9ENohKfXoWDykRlhHnh7rOaR4QvNM4xzQD1a9h y8Q+bnSMIy46dM/26r4hYABqfDcdOWVdD2bem6fOE1c+LnrYlzqMJUFiuIuVtPs+bUhKjV65 o2LY5XqBUHPp9oxyXIuEchRCKwoq5EwwKp50YD8PF4KpQQZJ/qSwz6X7E9Ia+Hg1vWUxJS5o V184luIqnIuyHdF+PJEHGFbp8UUJIoUXl8YXRIZcyFbpu70sHDvDT0LczQte7gJ6/PJiLdjp F3dqw0P0kLpKKLIWgRzGEzNsCuidJdGaxbYjmT9c1yIQFSDzgQvslt8Zg2Sjkecmm2ggODIM MNuctstUVcuQ1AwFcFzsalXIfmisWG30pe9ftD1iUJRrNckJycGUN43ouj1yQrLSfLpbTllf dLdjQWkeZUCSgSBhnz9gBYFQ9rnjLFSfRyvZazkq1gGaGWAsF+LTla3IZfxsJnC+AJrIuXdx TbrO9wmoPR5ZhfzoU6QeDfD1hwiQiDnVMVC1Rf96xBriaWxeucQWhbwRkDTFe5TKAraOh/NU SxUKo2EWR02l2+GC/pTtJ9sH++vN6YvNWvY1Spj+6fn+As+E7acqt3sXp/vGR9dbexfJw/lI mHmlgm2++xaV588Pt0e7V9vTwSnrLwCH1H7L/8JYx/y79YueiZn+j0TG/wPWOnpsGpZfYQZs Wpr/nrWO6R+sdbR/NiT+bq2jZfi/x1o3oWAerk+MjCQ7/3kzzCYRhDLtRDQRU9fBPlmXUOED YeSPTsPMH8+tZUJWTP3L4wWBD4FSTv0Vy1wRHVhYZ1ypHmfpreGg/TgqSugtweCrrQ/nmxcH n5eeHW6vjy4uyPqaVJpJpi0PlhVZPM1eHqsmKZ6v5k+2Rkff58ryQVXV2rWbI60555+RQeVP LsJDgSM2Ez+NL/dacWl5ndg6frguVgbPPtK90c3Ojbu2P8xEAmJzWATvc9fbGUtKR1+Ij64F b66fPPqcRsIKbOQLvRjQSh0H44ixtReL05EGMdEzH/6OAIiATtQwd4SIxCwuypngSjYhy4Cq 53XtaDhLHSpoKoGLEIV4WTnQjesUumLS1CAG3KMdrlwLmts7ep0YnRgIGW2gXhM2jKL2YPYk t1zKRVZLfcfrw/A0OQy7SlWsDmCOfUrnOlNk1NZclDjxwM4cSCcRydqSx2ezNlVJV/6ZJbn8 ydwZsqm+LnyBl7LICKyvAUi1tClSSna/S+xDhObShV355m0oJGN6YAcWZhpm4SK71peaAy94 OANlVFLmEqyOnWQkbc2VAhnp/ezAsNis5wZB9W/mosxGZudK88+X6xy+qE6R8sAcru6Iz4vh ZJ9I/esS4iSljCWsbabPWOKso2aHc4IcsoE0tuBiPJo4YXL8baBAE3HCd1jsik/oPJH5XZk+ +r9zAqLjHOfT8+0HM1Ac7uKmdNufPXpoARxqU6W2zxCCg8e7FN6vUTKGxTvMwvnEinG9AG+b W9DKwSTGRqAvkMGJfNzWSACkCxZe2qMyVCmu/2zI9fLciOt1seCnueM9KUadG3innJOCTasN eeghLQ8glygkrkUwtl+khVaTgPqi/j0pgUfbHMvoyRmvBG4IsiwSjicxf3i6QtYR2Ef4NK3+ 03f2EKn+rh0dThGUme8wQbDu3qh+JVzd58tFxHXZqS7TGJgkRBhS7Qbw/YwB38T1SpH1PkNW 0figVt134hGP7Rkha91r1iWObQJagFOmCxKctl/jDBaX96b5+gegq2e33H2/wE3b9r1ykW6m hpvfxNdvjSpuJQsIbjz5FpN1BezBZt1iZ8RKX2qUfjWb3KmAxNNdOPcNYDHELbV3oWWjBccB XXw/rvKxn+ATmbV8oS27ZHdE95aetgPOB3SFQ3glDYpNd2mGwQV3aQmgCxZrcKen4u8OZDbK HwTQht29Pk6Lwt0mAhb6JniJsoN0dk14Hfp8NHZZRO35ypIqO5vurMc8aoFN/dkUKDhf4RJI mTXbsBQXJAcFWjOLB3KukwwB9VWZBYJD466REGVzVdKRStEh54JsRnEoWb5DxBkpuwtKT1Um vvTIsnroknjo09pPCeXr4xtcJI/lVvh658VuGoRSzBAHSsN+/JRFnxzzDfI78rW/NUsheCSl qkBThCAQJeiJMhqcD8o0G1YQnyEuPt3E16vxdmIpZXR7/Tbi/oQAAY7Cnh3VPpKdbifuHOSU GnolqUEd5Bemz8cmz1JuwEezQiTMI+VaXNrIdj/IdllKFvWXqIJ9fI24RM0Mcp3dC9IAJObW MyaudFKBg1AR6/zB5BYkuMxyGc/w8lx226hJIHowwRRXVCHf4fvjBhpyb0AsYDIDEXopwJLM EGj7nIy2AiVDsWNDjfiVmGk/7meFFBJ8mYwvU6pQuNxsdYsDybdLyFD0ac+BXMCXzSasRt4L mksCL/c04/D9QmtWujO7CiwBpomdO5cQxYIPz1C2WcLJJwHhigsy+ZGuUzVc2BeHfqo4GjH8 WZwX0CRh3glx6vWhXLYa3yApD7LdmN2fdagWhIbf3DmY4myPi7pGiBoTJXt6/Yt2dm7uiRsB QE4HO1H30TNrjhAFAGRrboYczLcG7YEckHJ5vAv3VylHA/DgGafBvqOJtg2t1hb/5qY5oxU3 wh1KPlHDmQUgnpstG2pratIzEysaVu5QyOqfqLvhi8pnFyKve72Jx/eAcvz1NptwbU0LqOBT 4cEx2BRb6a0ujWR27AGf155btYddU6L7Q9Oq4ncmG+HShq9+xPYL9KB4dTKShjQ3cgNEMhLJ 0PhjYOUpxcIplFR3iPMvWz0SivLHDfLf8igI59fX65Gs0jmxsKT6C05Wh+eXH5CsLNfaXkxc n6xZMawyTjEll5e5pJ6EOtJU8xIN1F2sp9NoACdWH5D6uwu6EzzLM++OrJyklLQaXtjZOd3d X6Yb16IfB5is2tentm1KqpYnnDyBxxO2ssQ4FXny7wIz9K6CJ8cAJTrshqusuPRUCkIRyKY5 ndOrzKLnGjwYp3CWI+3nY3Ddx2JwVxksojmN+skg9QusW7U7tjH3y9SN/AitqEvH58w+IKnr OSZ2Lo6AlBg49YvKVOC97z9Rf98m45opjxQtindTDZJyUX7j2LW6cb/YKOSsNvPlOOsEr/YC igOaGGXtVJV9MXQ8KkGIxPYu9tD0adjE6a6EIi1mefVJMJPVvC5x0iJttUkx5DEZO0ToQFvR yISUwAr9zCstCk1b7/zrXJHBAxm2Y8c9RjKZaUaFR5tHXU7TrfO37/kFtbN7iTaOA6Pj3JTj lh4cG0239iEN6Zy1vYp+9MMX1X7vaJSB1gWMYfVMJ65CYIO6UCXP8vlrWnF9R7DJzipdAg3I eouj4PoIQEdcSj3sHz/rwQTkHIUDfNDIZaXwLHP6fEXWOD3yZE7bVzw/y8G0Vk0M3VeIqGcC ODNTnK5PdLRrjbxpy6wRll9okN0gEBkKdBYYu4n4sStJ6LzIlgs/JD9W+VNbF1VdE5akoPyQ L+syzCzxxxqLtDoQI4qKIKOWtCRFvRHYNuYrh0F4sy2Y44ALV8RuzIM1S7DBYQp+PuqEQzsz ENVTX6cGN+h2s2bGHhcgjr7QkgYPscAtt4fHxwUQzwhAOjcTEzEzD8i+Z1qcCrA1sikzQOyS U2ucd03ODOLCxJGfw/PLuYYQArnxfjBozJafUH2rT3zy9trRdzvgpWoafrbtMFeyKhtb8BMn PCu3aMXN3Fud2vascznc9JEZ7k/QxOH8PtUAi59X+s2+qqoj1Vo0DPqHckwrvvKZCC59lcoy XJNSP72BBfglY2aC7yoBqX/n4vjMrIwbI07PMfqR64H/dzekZnzT3aXIj6lH6+iDE6kErGFd p+rqOzbR3biBApaITZO2KbXoJgmB5Hnh8LQGKLVpcrREBu3CKjl+5KQq8lU3IAlduHzK22gf QLFNqzyJFwR8kUvhRm0haPIFHxB6DEZcuTqAMg7S4bbJv29aMvqFyvxwyn+zL57aBIV+JaFx bAlcs/8+PpH2NK3loCxqsMgJfbuAZYrlDo/VVh9Zs/uQUvAlnyTdHRikJ9bBtB0JOUdfsN1R 5LIIjUBfc7A1psxBPoH1XWVxTZBh07BqRG1UoAAmYpPajmU0lQM7cirfmBh0jzYWIwVnEM4p Y3FL+CHIoy3Qc+WNTFeZYUNkdqI7f9VoDJFVDR3A5Gd6SceQmL7WLdUSVzvqm+Ugzc/fJ6XT 3fmp2NlEDkvGJfTaPwbjzjewhklxmeVtPcMHX+qABmGbZOJ8waLr+k1aIKhBziQEr8uDSlPy 7baTQfLTuCgWglivaU5Mv2XZOPJDQmTILMCSPk+2imrEFlu8R6XTbeApJqGjaMxH2FQa4NQk e5hudkjg6VNJ1L7tLrVnj9ylvJzpms5dW9FiUhEFLQs5GfDFcabb6eUJCcV+xoOFI/2OKrh9 uhx3LRQgkh1SmZmHDuVD2rAfhu+cJ/BteHKIiqBFpjaJC+D45YIFYSnI8YIwSOH4R+B5NmQR MRoDf7B8SL+x1joidQnw/b7D4sI75onvqFv9HoT4Wq329VqDJCR/7rNpTdcvb6ibFMNMRdzP iYiaPerx5Wa69qzAnetEyj8AKQ5PysAPaYRs6jGEvs1H1SYHT5JVFrlVW81LuU9XvDY8E7mh Ks/sKot7kGh5+mKXPkg6LUCmigUfJBZCSAU8N6l4dr7IAKzKicXPS24bVGM4Bqjmtc5Vzag6 1N5myKUpbqGc3Y8e6Rfui6ausT1DKfvkuS0LAqS4lpOT79SxWfHUXIf0IbXQOS5MX4RGfWap pXKLE00Ka0qC4+ohqeqxWWOKKze1IPNwrMiEGvfA677Sx03p7NlXliWLuCaBKM2iDEY3M60W NnzI0XU1Kg350FfqBqamsM/T3VVcnIRY31xvoqZE2XE235VO3Bv2QexetTy0euMw4ftBLMEF gp0pquFHen6brayjev/PPpKoC8AC9Cfgc8YLctRTrUaIpQHOW3Jt4lSTwXypW7FN7zPcd+QW vd3R74fOuvc+R7E49xCiXTd4x1LgIuvmQMwtFLtBoP3su/C1b8QNfDQc9mCpDfA9fpzdFCjn d6Mg+Xi0gUAj3gf7RzuFFmPfwTSJF3RYo8LypMQs2hW2bNdnjtlkFiyzIeuyMyvt4KDgAOCb gorTC85ct4lz1cF+9B85KDKIlkAtiKOTSp+DBdwsXio/PGpVYHu2Ww96ma3JC+719uwErDS0 ndVxYIfrwfPghDng9RRZ/qCdDefxRcHtb8b5zkpbUoY2QmYTzFcWPNJMjqYDVK+gv8b9NIb+ xdEndQiESjxLBSgAItBQCTlVf9xwdtlfgcBvoRTe1FwpuJcWMUKmu6u0eCENEboSXpDQRkQ/ hoeE8ajKMpPEk4MRJiBuQX9JMTyqu0ZB7yuhhJJPFmcc+IgxoRz6TdWItKIj5ghCvDiVjEhO AiBh1QfqB/38r3gv7ClPASE2yKOQ5CY6fgRo33N1xQv1U8A+d2b6UNcTYwGCfNKN4kCWvxD+ 8IG92hksZoA4ClguO04nNfxHC6yJFDWRKn/fRmSQvQL7FFFq1WoBiBQ1OF1EdgwqfxeOJEsC 42V3ag6ptzJujCCSAP45KbrOhMxitDu6w80VP4oezVmDb8QWXCFcmPkwYFiq3boXiZVSvjxz NsWnKH1xzgDzotx4LIsiVrY6ALwUkK6FJoRgYwEEWrdQGZv3/dCZ6KMlZYDvw7jB4HMC90Vd t8yE9ncvExbrwrVI8GQZZZkL9+E5mYrBPqH2UtVWX5IzfzXSa5RHhO0xwdZpE51puD2LhEns r8cob17+ku3Bv3zANOae48TLvFLF7ZoPhHOcK7wBNwKZcgA23dF6mfik6m5vsV21vIJE1SZT tHDS6nE33zJMhcW1wuV2jz8d7izCZF1hN5p8o80RUOEVYCRuta8xwgYY6XJv73x/91xAdYa5 Vhd5rVOU/yz+8qgDriZsSZtN9lj+9ez+cd1xZdnJyvPu8eZqOrBmegIUlmIcQwmCqzRg9SYk UsujveHwozgMp9KxestaLculW//AqWrJCJjjQ8CTY8AivR6eBH+XR0oW6Qfv8/AT+rwBQe2P HNMCjcMOmcNzpw1VtpnotFOrwbZ70BQgmMuy2WZfP+CuQVCNxqm7RIKKnmF9A714J/sZEpYz wPG2Z9Ue8gezRqcIzrB8/4f3RcytGjuzzCIUVpjJ8M0kPAHCFHoOe0HT4LJOWwKGiCLSx96w FcA7I+KhufrIih1CIyriRJ7CdL1dtoegLkQHeVGyUsn9riJUBPUOIxKdM1sg/KlmaCjyn5ny kVZCAlfg+1fg1fMFX061qOr1anW0Jin9Y1dVamlS8GO8UI5SEtdX2z0uxpkaXmBnAa79yoGJ eJ5FvEmxlimMnxxYfAdAHhUxt0rkLoa65hrOY/2hKUNmWQe+HVXByzvtljEzg6dgrAF2l6SY ApOUFkszgQi9tz8aktFRMANdb8yx2mcGwywUIBrD4WRbY8no5eJq+3EzimG2/sUSAVjN8Pjz LgyW74VoCmyOkkSczhKdLbJCo793ua2tjqg+EepQEUiHjRvW7tJasrz9PF1WI4o/aJObh+qI kSyCkBgJ2GMewg2HGckAk1nThqSfsQdH9OVpz1mXVYEHzIJ6WeTVwWNEVapq7kmaSLxdnL9t RLX0UHID3+J4G4Ype3zJpjplszvFJw3OW4C8xla+L18JOeK5ScbmvS0fUY+jIEUk47hpe4JW neW7N9YsoAUkh+LcwMItxM/yRRquR8wFuRuv5KdTS28fWCsoPsWHtY1SS+dvwvgbGwUeXGZD NSJ+acOEUEP9kLJum7mD8vK0ukpGYTkp4wPI1ss9OLJJHHP3cQ/28kSydyjociXaVxwnSaRa kkBwQRxXJeI0Q3kuMjao2xDAcdCRXd5cadXb02wuiaaXuwK+GXy2shrJpjoZFB7vzgwvmMy/ FK2zWTUdwnBUXvxDgu83TXhQNY3G2PxE1ORbpBKgL+r05GhfnGrsu3xbfZIiePnb52s0NOTd gG1uZhb1xPLakmPLKNlrDYnnlSak5C/NegMtE2/QIEfZtH2MHuiQu2/IJbykDkoFhiksPqKm m01Ww9gezr7XEk+5ue1oe1acgYlwXR82o4/eZBLtvGs8ITXE3K952gP9Fu6zVbIGOmvbFdGh VY72bsTvsx0OMOonte59myDX6+8ZVCdpz7Z2d8+7Eq13m0e7/VYenzc9H6d3j6aXh1sKKmCw uDjUOT1+XN5tfuQ6fpHZlJD7ZxvmT/vfW4CBmpH2j0S6/8Meh/8/2TN/mi//zp75L7wPaf8D 78NhS3Uh6Cef58CWOCD7krVIg60FQPY5ckFe6g9WCHkWJFFqQEVAL8/yn1QEqu9vlDUhgcFG jaqU8WHOqJjQsJwmqWgKDJruHHIS7m8fDRbV25XEyrN3964ET2rBsx5b1eq3bxt2t7aXMyoS A7ttXtxcndw+s5KvY0bcDq9Ob1aC3h+dbN4MPx89W7vVrDzW0TCeuLFkotcVplmsnaFqpDbl Z4vha/CgYKX0+csMmcevoq7G1Y8FbBmj8fEqWCgcXqikkffd3mqwuDQtrq9ipWNmtLMfayV4 nr6scHGtYT6bp6dCs/HhmMRCNYHDraivrnFi3Qbu3gYmJj5dfehpMh6JK1a5r0cYC7w/q3hf 86NiPWG0JSU8vMnvkK/8m5sG4xhzNtYHC4W8WMElQbZJlf11qhQujyXl1Z2duQT56Bio/ODB UIhU+Lnuoqoy5IEikQAaTDI8hr5z/dJ0FJkvXmYYqWHzheR81EvDUXVSH/l+ZMoTtzQWumCS 7lp80lISBU/WpY3Fi2UIGUyNYsExU9rT1Z4oIiBRBzSJScHf5aZrytjxiEkRsSR0jrV+rz2B sYGxiBHFw2mf6obtu8sYtAISDchk0BkMZna7P8eRN7iUs+Tin10kd0RUoeB6uSIQGUuqgIgS 1SQGbT+k0rFibm+ucRruHUwImqa5RYlWYDNTdL9iTqnRMnkOa2tiipHpLd7z4VA5Y4BMCaaw Kp+RXSbr/TgFsYsl02Oq3/rl/nApK7gnBzv7ql4Ji+gXknEweMS8b3B3tCRhp7cQDveNqX1t 5CuhzfTUEOq1UTqUPap3tFu0Bnp+JGo+Ha2Oy54NaHGNarnk+5MH83jddn3+EAlf1cV4CzSM 2zd28ncXjdZXgVm2hYmQl5+wuwXvbC1QQSxcUR0JFxeopJj6lzgvQHlmnOS8SaSZYLc90FFJ mUFShOqO4ySSodvcHn5M4DQpfPA7laXi1febLKd2TgahTRKUwFMyph9cNqNhmeDTzEjJDdet Jpc6g7xMH7UH0qcOx+8JHs4U//E0e/+0vF0NcK+H55gF+pWybwOzT+/aslqntflkRq+gEiCA MjypXjh1gq+D3pCE4Z7lAG7U12uBM/LeLkQpZxSvllEQOa2EUqKD9wATbKORbiphcpuYFQMk tmZbxLYgwPMD2ORcgWTS5bRTRziEOtl5EdNKV7Tb1OROCqFNod7nEfqvIZwBD7BHeIXwNTDM 77ZLPZov5uqKVxmZ+z8xs6HHV94lBPKXVCMwQSOgWpObL866/WgMKvihnYoe1wfTw0ANDk7V SGoR4oFt+cSyOsEM3PGpUWMwGRLqMHnPzabPehaYTEf+UM5L359TUtdc49xU+AQUj1WA+CUd fwEATiiZtFcP/xiZmPOd4vbHbpmsMZvZOHhNUIVP8ZqgswtwGe++Wc/LEkxT9HhQIpiM3AI2 J8lDVHbYc5/Qg8rvwAE4BgDLb0PxTVtYwFpIbSKU3PSgdZkUA3l3yqFa01PEYHVOYTLofKIF G9U+p4XSjwLJjTLB9jXRxxlTn9NMEvEmdP5SWU0njOd3B63TzFfC7RGQYPQZ59rsFks5pB+G 3J8KzkfysWcnjJj89EL8kXVfmRU5omGB/9r2HIVaBpY3lthDUihSUwsgMQ313NgHMc7EeGaz ejqgFhAniKZ12ptaH4QXHogc/ck89NKrVxJ06oObuYhynG+IRLlJ6lKt63v66ioWUbsbBCi/ C0/ffsfRl+BIRbYLGVOolfK8dV5kvR8fdmlKBvUXpJDq+tKfiCni4YTuockAi/E7uCxaYDZz 63i+Ztdq69C2bBpFyBc45CJUtCISCgIu6LUZqnxI98aXy52IM2jUdfiQCjCtSoEdU2TXWdvM cAWhr3heWaWX39Za74dFIY/IIEQnvpjqUhTjWLCLR7/BSnQbK1p/QozBGL1TCE7uw5JLYKg6 3V43lknYwSB/eWzplX8dgZM7sxe1SIDOUJctn5FJGMABC3TgjaJoFiyc1kW/VQpHFH4jLg5o HJPoZDglSqOCUD1gYC2G6Zbw2XSYOBZ1QLsqj6S+1uUlIpnC53mAEfmuzERhA6EBo0K/LEYr 3XdT3zNtog2x9ORzMFcg5ohV34aQgzqJ4PFDtRwQbtk1PM+wn3YQeFxyHIoec8GVz2M2Pogy fkD6LjiK9rtPfqobcmK4+any5vajfLNgrfpA6yE09PnCOIZYlLC1GZ3l7hSmvDftMKlfsvIn OYSNMtdqApijI4qhAFOvZFp6cxVvrr/ZKk1o+VNOStJ9zO3UmT0OUxZi+eI/IcmTIaxgwA7L wtFoSIpb1ly7Y6b8UqOTTF64UC2/lzdGGr++nhDq1P/wdKXjqV7u4dHi1vzZye76YPTy5sB6 YR0DKx16+KED5kRoWLJoyuJU5NawUW5Izfr2QLfjoVptSuo9vefD9ubnu+rHbwd3Py4PJKSs Otw6rFTVh6euPEiqzNYdPQHGXXo1Yt0offyuYDj7+z76plUxP0lSPLS791WLI1Ei5ltcplaV RCc0cKKZJJYJNZsGR6fX9AgrSZjlfjs29q8aBEMfnzirBGUdnUfJF0GDPIi9XvmKMpc0S2BN X+NjqrJapRt1JBxgw6bIU9CDOTCrkrsS1DrSRTgwu0TZiKrOhnZDXFCjHJtW9gBm6aYR+S4k pL4FVcr2mC53Dc+o/dHGoeo5r7H5MT4hYrL01INDGqV+YZhajYglUdSb86PyBRhG4+wgg3+M XIBjp+A5VCWtsY7ZTO2TwbBjxyVGMoRpRrlHmUdeTtUti95OPlFt716ituP5qNRi3LilB8VG 1S19SH06Y+2iIjD9II6KOCBKLuDZV/ooGvpzZxWwAWwoPCe5XBHNKO91bPAzxxvLgjKEYh8h 5Hy2zrKHw8D+WyZHRRn7MrhjfqPyiGGtE4ylR9pjej0utLD2QwYHoXAmipC0yRIBE3UAAoYS obVBW5ZjwUp0aKQ2EtHkAYvJri3uh03tpEE/mj44e9J1mOivBz2KAgUbYhbHgb5wfrYFkjd8 NEML5ilGZT4qYmRbg5b9+QpYdMJSY+oq1QtffgC16Hwe1V3A1ViGsrB3+xANC5nnYjkKMOxw bpnwbaNFXcnVbwlxb++yTe31B1Kpg5vLipLTeGWsOMYniYt/w0AfwUu4i4/w2fueASAqAWMM dLl3NW7lk7OzVmoNVler+zTUtyaY3sgkCo/qSWOXOsNiKEw3/3w1jfyx+rbliuFd11EqNaRx fZkX1UAxv4NLZoNEcxWf9zXu8LNouE/M7fppVg5WMXAITPmT77RSRohoUZf4OKYCtG3lgHDk AgwxsNK6lfc/JClVliO3NAsKnJEA5TD26tiz6vbsY8Sa6bBhjd/iuGaEmjFdmi0JCckzG0ff uFejfSR0TtpxjFkWKSdsirHFyEM3jnnoyYvXpdU5yEuDo+02oLRTyUsiB1OBraqH3ut656vS 0LALTV7Sf5OXSfQK2YLS0yQDyKjXbVAJlWhYPt9QwfTQe9dWw/OpcahfBA0kwY8meUC8olkE +lxAu1JuQA6bc7yXSiJudIZaXSHJq7lmOC7xWe9zXe2fJc/4UVN66aEv9nNoRxdjGUxbEyk7 GkcgkuFpew0obV+5GAFP3q6mV9AxooZiMCsUwSOcTBT+YxWUuyLhPoGSC7ejz/vFgHKQ8wDS cZh6nXaAjhSSjXy3ThIiwkE20hrB3YnpC59RBOeSyxtrIqzMi+lpVUsiJ2muWA6jk0JPyS0k JleCpNe3osgQ8qtbxKyulvgnj046QXXwR1hoBGPYHJoQcySUDbHqErbBdIzis1Mo4t3jqNP2 Fa60wWi9+oIDzGszkaB7jEY4Kaa1dEkBaQz5lvVdI9EpL46aBmzOq9w/FMaA4rj6j6qobGXy eIq/EJLKHzLoikSRZgLHzVdwpPQ/uwsPQD3asYdyXI0ytlJU5ETgrNuATj8f1ZSdht27F43j ItXkSieTKY3HbkfxudF5sxnHpGbOxsq3YH+qSDSLRbcgsIjJgZk+3vQawhcaieGGlUU8aWxh saRyHeq2GIv9fgDFMKx334jsaRhwpQFz8etDAngk04WFEIjCEkB6ooHKvM+3jcwajPV3H/A0 4wAdzUsbNOZ9XxcBZC24ACXp9/Ksj5k5R5ftR5ecyc9QwkeQlx4nRM20fGBx5hN4GFrlBHDF ZiYz1yxn8iTHBgTRbgOqWnn5JD2TuwjvxhK4kFUTjpMcQJyxtFJ3q+VgrIjHSX1JGfIjne6I EjI/1vCIsS6+W80P+3x0KHxeGjG9Kh0sRoAorCIcbf5g3IJWlnvvK0tNmSdBMX1uZUSSJ9cb MWdAZrHVxt+R+M5I3aiLmgB1FK5bVXQuzvm8YkkUcHpsBzFaW3i94HChJlhvtM+Kdxy3TH1Y cKEmfA4ign35+1Qgw9l9HTqDYIsF6IlcnFxp/1otCwbhSVZnMYeHNaGqjCJfQxa3YIs+vjCV LsI8I+DHE7d3LKp3CIQ2R3JYtQE2Z2Yuyem+CIpNATJ7iGFzvVI48jW3JVouGOyufEOXAFK2 hzBfY9lxqXULIFYWSnyEbIsn0gLwChh7v+sESH2H+xr7Azh9Q/JdwXl4hBsULRvQkDZzhAM1 PYeQC7BnZu/URkI8O34gbsJwM7ol/+ZMMC19tM/XIQF6fQDhHvziofGhr4YQJEjvnp9d4utY 8mrBUkkiUKNrwAIupz+reXiUhO8kCrAGVrSzD0JKrDIr6nOVXFk1iMaDUN3pyZ6qeg+ygkLd SF3z6M8+NzokU36nxxuuLrmMdibAMsmy+BrSoYUTffbAUqQkbCGucmYHzzTQFkfezo7mTmLS PRb3/Z1VtYtj/oTEzUCyBIF7kj5uI8hVVCM+zGI4cW/YR1APLqTIR6KmgdpTeMpmpJYeAAHV YmA2B6SPnydJ5zqVGmgETBZtsMz4IKfl6KcC8gKQdZG45/xLwW8ft0VvSOlvEuIOMMOPJ7B8 8R74N4CgP4VVCS0CM8sHSd4MZFk4ZsF85K92NXbkEQQkaITPQ9je75nHrq7JJDfldzGKhDOp 5s+lZHyKi3wQ6dandWnOH83fhE1EkyC7s2wzIfVOwo1hTAgQ3rCw9nvKH7w5fgqoGQVUSTtw lz2bf5DoxpPmQF5MxEC22+mUV0ofVV/cCGo398I3qka5NMCrczsbzq+R/UhdbQYbFl+CA9cW xBtiVY0ztqEMiNDmUueY6QUHxpPdEKWh88HNAqZGTR0vsP6cSTQ4Nx7BkbTYL9xflLeJ9+JD XSn7B/GFQnSkKWCfyRxyZq6JVE1PLk0qpt0FjCUTFJ/iYFtZK/QjnjS3SpYabud8QJzUVOEN kBXIwE3kfCvJk2qM6ut89BX5jEQDMcOsOJvGu/PT+avdzYvny/sjpQO5Q4LZLodisq6ZgBSU 9nes6TRtuvZVp8z0Dg8OTW0tj7d3h/fFj0loH5rGoLvazck3BpTDeWi/9JyJPpYXUPWu9M72 dk/3Tp88pTOEAeoPi+3JbgUaNBxMnu/dncqWwFRSLCTZyJa5dJsSXzpIndPLuH7pSzbkV4UZ U6ztZmGDn/VYkoHn6vkM9hUNqMIkV8ide1iGEcudAfhR4i6pC1udYZMleT3AFfeEn8OGLZf2 JZd2nXKrmmXE2CVg+KnGT/KrFERs0pibmItvNz09tZ2BePuCoDCOdrRvEk5FDHCb2R3KQgvI 3ULhgEgZwKwzUM71tz2Y/jzcC57OPrNcUfzAOgjoEgWzPPHcMnTu9veF3u9fsPXEWYSl3UoP hoExe3NkH/dmbhW+JiNX0ma8XDtyjKFVQunAGFKZeBmx1UJCBQREOnlmuH9+uJhezKjOSDD2 13bOGqhqgmsN4BpnoePdqC8HRnPhM/4h+EIMTbAOakJHH6n0FYuJl1uf45y5ogEb52aD+ADA wGC4G6oZ1t+vK92P+EuO5qJAD7oQcLizMbW+OSZic/yu7p65vIzzy0HrgSHJRzG6EOaKISw3 MEVoVr9ignGmFLSxuBVDGFs/AqHBXaSdqfLUXlS2eDIjNtkj3f341FE6mw7S2RyNd4vq1Kdt sq1mcGl2d/AFGCVxHnIkpUhyLEaOfqkXopvEBqPQ71I1nOA2rIW/pNTovERwnrjkpp6I5Lm3 NtVGMiVOaa5oLN1sn1avxw9bao3xBUjltgY/wBXSWZOgKGMdbcFa5OMqkinmAExDqZGt2Oy6 iKiakkBOAOVs70l8J/2+NFkmL6hi6RVTl02VSJbxg56RoZE0Y6+9xEBJ8pDprCW/Pv+yrzq0 jK/J7yzTujTJAPFSlma4m4ihZknU3KRAHRHTj3lWLMO3OLHj5WazjXjOpmgs4FToNCAu/Pjs Ysay0Rh4ydG7Dg9fEjnwBRGVrmEDkViS7O52+HL8dZlHIt9Fgnp2hcQ+UU6txK1XKlVaw93X hXrjb5Gnc6sNFdZpsMXR9vSoLt60q8/S9lm9/Kw8IfIs0apBSish8KG/YPdq++mq+xKUbc/z yrF55F/YBP/wa2Rm+sOvkfb/hF/jv7YJ/ld2wH/0a6T7Fyf40P23T/D5n+/XmPXXLuS/diH/ f3EXsoJGKBvoBygWL1dHugxOzVw7N2tNGFEkwi3WVL8wJNl4p15quIYndVr79E4rUEunU/HA gOsRu3bWj42HuMbIs/fo2GrRkTXIrkhuTLkRvuBp8Akvjbm67yMgFCL6TRZslN0gSyn1vXNE NbaKSwhaYYoJUVpgik2wOUEpN8u14tstCaDNsoz1mmCsdVVJtp5pARwm4KWD+wGYkVGlNazf SVCp+SozB8oVL9FZQRY0QQGDSFlgT9aKegCICc2EKfRo03d3kdG/6upnf15fZN4cYpvo6uev vCH0w1c+8b5dqDTlLD0EgZrel5Al42CiqDeXGcqi/VLkvZHiAZL3A3FhueSc08nfHagr7Wlb zav8UXdhIXSzceMI5S5TvTFz2mEpQRk2JwVKiOcnjTt3MzHM8Hip9Vy+AdkMiPvpg6h+fl5E 2gUP9Y0oRdpdmKosBI1PUh9m9nf7AW2MoGeXsHdIwgK5/QISyfFm99Nuuyd+H7h4fQQKqQft mcduxJAi/kAgY31+LGRSFkZfcVb7MXPw/uGjC2dYLIBMd3Y9rA5Ey4FR+Myee658RSsSoYD3 AlBXiFooj1eu9M4EJJg64DKQUSdwJQSufzOweGVbshN2jTdorneytQNUGBaHPFwdP11z9fVh nShnamLkVKf92OW06IRTHGAKv+gMP2I3+iQqXde1VZmRtJxheHxrc0omeNcHv5kleNpA/ux8 BrdZo0IRHakebBddEOUSOBNqP0FVhqnsyQwRYuzRy/sx3iViHDHRhFzImrgupPACaaHkOeyA IAqqqt3VR1DDG7A+PD77e7WP4nFxtWkVwNrfE7/pf17VMvpe+N7LO/G73eHmIyKk80xnvCl+ OxUoAw48tjFw2UdebEJZSxnEsIPU8dD70BgU4+j3LnNECF7B8vKmMpIU4UkussGTddAKBeey kG7SesaS0aKlnG76xly+Gj80Z3qWH8w2at8xpGHwuARea5L3idjTuoNNpErNWVHeVltxNSyH PBNCB18rJsH6Q6fsaecyDg2S93lA3OEXk0x796B0Och9MpneJVjfutdKbRwMCXlKOGyt7d25 f1i+2Rqd/ra9ffCjts31zsX1ZWt0tOWWy6Li9bdl+2R6tdvE9eFb0ct+g1zJ9+owMRjLZjpC gObXYp9/2C9cjn+i93w6OT04PLrJCOwvqDjzRJ1ni8G62xu9VXNht2RwRLs/jdxYlGW3H+wn HaB/Obcz56RZYsk8cLJkuTkxIj+yj9Y1WCIap3OkmLqfGxdk1X+IPlWVzR1Xkc1tyaeY+nb8 2d/7GCEC6dhpBagt/ihsYgcq4HrRxWLTx2zkFJ45ZVG77vhUmeTQIXejMa0kk8kUJu4QV9ak R3NOm25tdo2yEU2dC+2W2CpUNZaj1t2PsT2rH5Cge1kjlMj1AmXqkliA0lNWo8yT5YTSsy5P zralZR1MPrDshra5rIZtXjSa6yP/BTHGyCG5RN5O+DZG5UdbIHNIzQXWOnPP9z2nSh14dgIn V7MV8xWO9LecZ6lr3+Pqlx5px6Cb7lAGdhdHK0DZb9MlL+amA+sXQqIMWTQTpLFBzDZawKB0 xaFcNOHe0Sh3H6zGGSco6Ueh6O9iKJ5Vmucpf6L92rjjpRI5GxmBZXXcZW3fBqedFSpfsFtx DW3l8d7pS1OGRJ/ydXPztz41xN4u5FldcgqvL6qzscf6bejQeOrQBaGTCHXi3+v3bWw2nqxp V3Rxka/AOBVOA/kn7eFLspl+5DHedg8GiTpLGz1koRro1pfVzG2U7n66MG/4OG0ahpKNZNRO qaIr8ei9Su0xrruAt7oMhePc5G8M1ifrbjnKPex+fpow3uUkMR+gbJXZ//l10WJ1IJ1qlZGB tbwxTqMdQEVhYTIa2bWgRbjzqctVwIUCQH8Wg5Ifm6kiABx8F65icuZaKHkL1hi4I79kqe5p d+Wmmgs2KjWMSmOfwGlR6zTx5LBsFiUlanBntS5cCXimVc3lsUJRikOd2vRuYYqsJ1DzHtEn N+46lZLxJvGjZPAkIJZYTCLwEYeIHyGjGRvu7WFSfikFzxrIjG1lC38eLPNDcjNryDihX1Ka njtVW1T6GW8if5n6g42P3VMKHsqXGv5AmoW00FB2SlvlncqBUVwmVcvYBLzRy6i8WhnefHLf ejvRvdwRpLetEwIEoaRza520yvpgZm56mwD8FDcw71uMYX0ZslUkcfpmjDN8GsOcz745bdCt 0umm+nOujAZY00C8jCG8LnEWOaBtZJgJ+ixvJ1IinlGaazzvS6DFisiX+zcxH/hOcqS2cuZv bOrdPK/kp+l7ayI7vT5XS47evtOLGxmYpxThdMjxGyFLVqquixiSFQJQdECcJHdSGY7+Y+MG xWVeBKiv3YDzoDfycXd+LyhNz6qgQ4PMqpeWZSfWHCdp4+zxjcz36kjiepXLHQtHEGzUyL5B SZmpJCV1Mwcr6D4PtMkPkZyoQzWR+/5GRCLu100mI064Mjv3ioEXB0Zl8itauDKcxwBw+FD0 /Fd6hL9Ja54biIYqjx8yC04x3KC1gSO5Nw2etkAf3nqp39daLSRGYBXYF4d+oyNNSSTyExPs M9mZcO5I6G09DDruO1l8+Lhk4q3O96MxYX4AVbtn/eWjBg2u79TTNZvMqkralwwjiop+7Oyl tBxYIBOWdYuz1tPeWaEDL40Vrif2818WCSPW3VHtVIvjtSdzY9KLaE4cihS7x9kyD11DZpfl GsFikNMFAZGi8I/E8MD+dGp8ZBFNv7dWGiJ1BeFbvUzl4Mw7G0yDdfAFLO6n2AcBirtHFJQ/ 996qpOufMfTJCGHGso+wMKfnLzmzuccsOLO8P80/k8vZ9B2Lzmf8Cnr4ycZDIFWTJ6dxCo4Q YxJGZgKPe0CPjlDVSBrMEP3g0INY2lZm3N6tKZ2/sLxAZo4B/7MChJCKSC5s6Nx8oQGEjT2L v1fNN5iABAJQwzQenFzQwKat2W62odChTMHRg49udxF7dt6xo72IB7QOPXQsBnEt5tvfK2Oz Eis5bywQDtrDblomOYuhawOc8U5ckgM4W5aED2K3euFyK3I1lC+oEmQzRkhh6wWzXXVURQeT qqHbFdhMxOSsxGAEa3NPBewOd78WMa+RVGx525Kh6VRAcBgvONeR5QPJzXGWfUsbtlh2PicS pdn+Glu+c5VNsaCr63m/I1KbXdqnw8QjpE8Gx4q23Q3IaqLzEWGynkg5x6DCN/qGwyGTYQRN a374O3xaY4+DG23DRk2Zm4ajNlZi+6PFAjoUyTAe42KRFqjkTZB2UBqpsl5F9SfH4gnfgDS5 Fl1WZa9YN79zfE5vosaP/qzrxwNAxorUJ9EsyNIg25xzk1MLqftwblE2X2uxUWyXEw49loOn HRRqLPg3G4Np6UN8vvb9tPflkherprVb+uZE2eJsYFXMK7fImVp16ujOe7fyUc901EXMdrzU Q19uB6uBqF9lU9NKkRJB2WrVNymNe9VGiIA4c91AYeW3b17OMIFAmQajPwRMHI2QN1tRV+wQ UNaR0g1XW3wGMi8ZafV6TmNmuAZhqYPiTJKt+Sz+SXI0f0KtKH22JPFDhShElRrB7EJFTKiz OXpOQJpai67rAnOnWFJyD0GyCHTeCvlDu3f548vKCousbazJKoPbJYxjOHhKrQZ4wJIsIXVO Wul2ZZlByFT1le6czOB3+PhaUxJt+BaAGgtDjc87GU41FfvILbPiXTHQgsrVfDCsfX6iN8Fe oOikYHqR1eDWhbC+x2NZGJH2lZ14LYHYwWHvRKwJREn6FoPX/YQteFRmgiDXTuBMQvlzLZi3 G6WA0rXhHVMjRFFh3wc27hqrDsK4SiqB98BH1zbb87+zCsQjZ9Vw1MdSSjtplA6Imn24zp6+ AJsBE7zZBRAsb6LqjE8kU3JkzqZiwx5MNg9wWxSh4LqvPjKfeRd2jAqst30ozE+VHbWlVhpC xswIkJepWYZBrA3MG4WMrq+0gqvF1kmeKL41ofgsSRJtLryZmS3SKF9EHleB0CE9PFTT6Sc2 ZENDhR20zN3j8cnE0uqFayX99NDI81TrSHpGfIbqpK/I3TgWltKJXDrDhAeMiAS+EYipu78x 8EBqfMWEDQnJ/Ml63u20OnaRGCnVMZ3r7u7w+3N3y9FyJJZBiwyVCbSlezmIHNqp4Q+I/c99 tV37uqsXxofP2wfPJ9cp40wNTNfjS8rkVRzTHObkW2CDfIKVyevxdxoZz0V7muutHi8H1wUP TkJz1CBRFDDJw8lYio/5Rr0t41YVdfdgy75i74nm85lQxaKtkBfNMeJRuhzpmK2IFiQ+Qk/x 66c2oBTbboCvM0vKBZcCQ0/SpfmzZYCyprhwdQ95Vw8IOxENFbPNoDeWCEWXg1OBfSZrpZez PaA4LvR4oeYKgonipeNu3DhaxZOa7trevge0hBCpZ+UcEPbfPMFdT/vY8m0WT6+HWqAQFi5n 6QcQJbGtNUFVGE0aSX0pIOTnGe04sqjrUXzSvIBw8xXJH9iWQ8WdLMv3eYgRhrMqwLaEbcmm UXLCI94VHzcb8mEHlJc5N8aM+0WBMhhryOh0yOnWCL/cVTx/Nr8JDsQDWRnCNMC42HhPcs2O WCEk9dzq9vzjFimxI9iU272nkLc1E6G3s8yLA0neyjixFLezYhdntpIW1PQ9os0nQEGr5n1K +Wg2UqwfmZDQWZdBEe6V59206nXfyXXfN6gGkH4PKWU9g8V0RcZs7X95PyCG4UHNvZjJR8AL nl+2/zVO5nVc8cT3XzUxZri38CHDYmtJj4DGk1lBILdz3hmu0jZkRiyr+trCzAe8O4GNzQMt 2djXzjpupFEfK/P1p/KkVrbEIq+Xt9rsG9QOQqwRqJ9sNqxm1ZTSUr+2ZjEHFETnQhpBHyP7 0iKVf8k2Wbye6T+C0mePCOKqOenf/IkxJPqw1VBIwnEHV/pYwoGwuZhx8YtrY9ogTF+EKYCH 33y6q9ztNBNBQ1ONGy8VcdOllzpnQuwEK1+4cVaWB1tURd69Gz5CmGxjrFj/HC9rTMipMmkz Hknq5LysGvP38AZQ3jWQPOsE2xvs07Xk7kZXdeC5PXX2djzFsDr1ASHZO2QDTqyckW9uCBZS AuYUSl+z1C/6bbsszYq0p22AU030AnsHizgIUYoulVMeeAzOZkcRjdcG5cp0BSzG6HaqevSy bNJuR/HZmAL9vGRGsxbcjRaWaFrrUhU+Fj4BYoViVVmwEY1TJBnmQfdYlMVC6yyxqTm60F2D 4WEmufpZdOd+D0JG0vApZXgA1HSYIfqhal5wDX5Wc/ix4/nykUS5EoR0yz+SPTdtiVhZuhbK Z657b/6mmjWGZSUpffXlqQn1dcU6rSVF+bV3mKpAKVKT86bCg9m9ydO9uenF9mFz++Sgu2U8 w9IA5wmmpIyK8Z9tjnS/Dj6kZ2H+mx8iy/8UmyPdP558SPdnF8lfNkf6/1t8D/3/8j38y/fw L9/Dv3wP//I9/Mv38C/fw798D//yPfzL9/B/su8hRZvGCvdjyXFV/Beuo29LoNCfCGQVIExl FdAb+aO4cyGkwXaP5tMT+zWtPqvHvJR+0xl/3GP43+h9eEr8j96H+v+jvA+x/tH7EDQhk+7N +3D5D+/D7P+l9+GZ9n/gfRh6uBD6T96HjukWLgfdX2CeVCNQc1brY29Ihkjm2pgsJAtEXIkr TSOxUoMV42YnLIijJilRwKd8kXvrJDr52TK4IxQ5/UVW7mdAy3RWHr5o5n/D9lco14lrep/j cCEHNnv8dJjYDpPehmPg7EXEco22KYIJh1wl997yWKELj0VhX7J7rEiCxj1p86P77zbJ2E4S txy8DtDkNEAD6mM9DEiJ8WjMLizjKvpGAwKYwaygXQcNaKZs60N+lC/CPDq7uKi0APi68Aq7 RgY6dP5xHwA9PduGllJlVYHHEFoEd8h9sh7p1xIytEzx7gyixzZLqMZp+eSYIj4tUh0+LpfJ 5nWJPSfFtShqV4/x+D7JucOq1HFZauR/4BgdqD4udtPXHBRSNU6p3DpTEt55cJE8/CSLJjf3 kNoDdUlMEEpFJaglulRJR9DWmVKankZiH7vKUlOUCxMrDjyvjQmfuIPTApeXZLPVWfFta8wz JlT8iHIz27VSDFI6N0+0Us6JxhupTBfKzQFNLi4B47aKsYeaQwDPQtk0CMcRUF9j4Iv1OFe5 /rp/31oM7WpONMa9hbV+BphbZ5YPzQ1xCkAgxOTgKfqSIdI9NQ9+S6Ahkj6CtA+ZjChNhOQj Jr8jYpxAuPDZMWY0oRj/oe601F1jBr04YU6B2ZI5KrRN02RtzNlcSj58EAmuiZ5JEPAaiNCC 1Rfz8TUr5mX0qNnkNaJrj7Z1evZ3s77R7oveNELQ4g67vSPxUBH7wyDCtoQpOFqMssO37eas ZAyAeC0gXcpNqPCTocS5PwjRtiAjPnFPliiZgUIge8Piu3xY/FTfOX9D3dLLYGv8wTMnTlhV RKcgW3RBuRA/juyXATJ8yAZHAhuZY8jnCmj04Pp29dpWLmK1KC0Bp/ALMdF1XxXmzCBoCt2H OCNU2K+DwcCWnaPWyDfU7vaWiSdxZUy7G/n3reRqtB/ywrpHa4g6NCmxzjhb25+/i9zHuYg4 WKcdilLXbRoGVHhFGIlXIGuUskFLrHqoWq53PN9epRwx7favKA84OILd6OgBCvWZQsZM4nso bTmtdpDtla+pu7d2NHc8WetD6QEsXkY1xf3QWbRwoW+9e3yuU8TSVquk2c5VvQ6Yld45St8w yb6hD6cbDarFTC0zDrRzxC9+qs3B9wi6QPBjAtGcFo6890rIMee8NwX7kXJJ48vTaPrVjrYD 6pZ/Kdhly1HY4FnEoF2jx8Duy+R3yMQHI/A0vwwEQpq0u4TvIIEmxtp7Q0luVeFRvJ24oDR8 mgTgLvOXdJVOUJdVMtGxqoDFVyCCR+OjGTf/ffdDDRIP+9MH0k1xSOVkqheX1tMrEHO+BV8W UdSNRUkKPt+sze3BdaRxTC5Pm4uC4wICVRxlTWJbc0vgis1xsbEw2MYysq6ANVjU9kmuEL7B W54lyNHt+PMHwaTzK5mgDdwHgKw8ES9eXo5YAIGaozgN9hF2TMwvw90XYDdq2XCHrtn8OREk XWXVoi4Cs0kTaGJFRXAmX5MCrEmkoGZ18SGAZHEX+7PxUYS+msf6eR/CQiomhkdBU/WxdgoV vS8eMApqK1u7sA6nxGYczfGWcqfGdsSCrVVghKymhwFfHQjynz40l9dxvt+Szc9WOEQzx8+i +nzpDXrMkH6zY0h/JlxkUCbDkMmp9giuIFCoyu++p47LajAaEtfMhqSP50FdFcYK14Bz52vT 1c4fOPGRoGlkL4COoGExFl2HT872DrDJntioyldqd2jRe6YZ2YXgNiS5USv+cJIyvrJJmz0m mz1FNB7XegMtODhvizO+35J+dmPEO4pOkwQ9r5SF26vmCOcdesSGnR0j+vpkAd96XA1ekX0Y U2LExZ4sa0iL2LLNisZNoO0ixrDzPvZHEqstG2Dr1a3gfgDMnJriHSYI7VUv2bk8Y5OoTxR1 78w/pUaHAkknNHuBORhwuSQDkBpcll5WGFyrVtWGhSPDp0jZrYfWkBHFf2836zUjpVIbXmKV 9/hhaRTfEbbQrvAMS1jXsURrfpB5qYRZcNg+zjP7tO7peoOAIGSsb2QpVntE7qA4LNzJqSSx uaYnZrglaOvxcGNXpQKceFXSsnv/lLJ7N707fPLUsrsd2PKwe7IaOI6VyJVQYns+HkvneXPZ sTsrRYXVosR1ZfcMGkENL/MvLI2/TkGkZ2H6w9JIR/s/xtJI94+Wxn+xy5nu/6J3rBT95d34 l3fjX96NfYYUF13OHMQaSUFH1vC0msIKa5+6+Vdu7AYnnN91YDSuNtFhoM7Rjd8dim8Uh2bq yB/ZeZkLcI7pHmucr0axQhPaiyo/b8eEfGImlWfBLNDp17mgqWyOeh9B6hBcUp5wzln4Rf+Y szDf+wd6o1+Lh8J9czxzqX92+C5nZ7BJXtDDMMAMjxg3ASbQhrYxt0MXOH2bOZTuJrpkkel4 K03qHiMsMnudN/806R0gOYYMnSKc7yQk6OuEgJhtfIKA0gULz+4RGLr/8IFkinz8gyI0iFlP 4x5sIrrL+yG6Uk48YpOFYU9dEgyuKgQuWhTWAzw52pjqH+JGU/NdnVOD59W9iKZxfMRBwSHS X8QH7UBcwu55G9Fn/ISQyrLVhXIAE30dS8PBusIO0mB6cOjgYlCMN++MtOKIyKFZqzXj9MS6 szHldW0pthEuN9kyZcJGVb6UFOxQh72gsd/QvxBx+lwf5iCgG85XYFGHsTzGX6bOmtOeJPJ3 ddVg5dXRTrW2T0t6ER6dSe3fUUu+44cKXeL1IznOz2CQTbmNlm271ExCeK8LA0xmSQECGMMb zUeHbf3eHCYV8GMnaRDCITx1143hmvcICGYUiOHXWQZqj+/SAjPwo/tDcyXzpHfWmpyiQNMs w1JkPOsyIObwJDIfVSDt+M1GgOc76tJ5JJIZFC8PLX0IgalgZc3EBtDhg7/MnStkZBH6c8D5 7gejaJcJ5nbBoprMCocKehJmedEPH7F9MMnxIydRiaEdkQXRok/nxTBQ9UXGrW/tSXC6wkpa xEOOhJw8sJKglpGdcmyH95rUSo/ddPBMm8xBBADRnBovCrxSo96RAVIqjv7R/iplYa9MuFpJ MO8k4SYBFep8O06qQypRw0wBxH2VDGkAQlmZIgGWOnrdQxECwXlW+bSvYjTnPOFZLAKkVffn 0VlPkI6brjIfrc4qvKchZuwdgQ8w5lyrkIkmB7/jcNtxqnQ0rQy3P61Ykt2nMOPPqenwIrCa f/GNXiImqkF+INmJLcwXB4U3Ap6XUMiVSEx0Cz3ytNkiJCO9USu+mkKMPTqzWg5lksqIjCzY nr453T06eQplYjpbe6lt82BOi2iQcoIpODnJKHjOWZcsmxqmpeRoPBhLAtg/fQrd3pzWGeZS mni8bmgpKKlY9sTEzGhvfzFRPxP22ElhWrc6uGicXbDYb+HyMRK7mCDAKsGefuwer7rrMf7m lb/etLvQkFFVOi0QEm+SwT6+UCd8pMaFdhB1ItRsJhLNaSQSffqlXjijZvsTSLUcs2blug3M d8VyOt5YJuQ5o6M6/w/lNC1iG+aGvrPVLXp5hfPRPtuO5T5rhRzSxaHCeXCuKr6jn5VcWzYs rZ/MV3JaKUwlbiZu4JZ+BGCCxkFaOVGkH/caCQ/nIDQ9ijjUPe/WtjzOJkgOnpx64Elj1C8N 79ePnaqTCTyLw/bm2FOX1NDHxzBFOHVKDkBV0nzWOZqpfvoE26L1FDHyqW5cqUOzY2ly5aHV zmVabsn0apiZbWfPCDvRiKkD83zFlbVXTQprSZeM98vuZxVeb+RS7zNc+iAahn1nAbAebagC J7lsFc1oHsOoeCfltu7qeF2FAbDtGCBDDkUuVo/WKtDuyWtBL39K2bSEjjm21rtPKyZ7Howo erNHh+loVioIoHryoVW1AKamClLVsde2zGHWLKmUgnIztJPL2f293rfdg9ahwdojeD/km7Dg BaZFSkPWNhKXVmCI8Eh3edJOAk3jghfrx1R9axKUempWJcVLaAyDNFPvmvWDGS5AHbt/cITq RNpbMfnt7CJm4yCLXTcxAFHcdrWocYKuM2ig6bZ5Y273zqp15PHZtLt7eJj7cvV7obTX1uYx cIHoeSZHKQGffTqoA4hScGqE9V5pRSXEjxNqFZSbxzII4cuEe/xSbjp/k2i3PPzMzW1L226f lbhi4NmkVV/SoGhkzksY6zTPqAknfWV5cNGhynFt3VW4qydWAYvlcqAGFiM7Z9e8sKAlyUwg COpGLqIJX3qLD/dlofQkaKVE70t1PbAzmvRw1yl8PO/GsdHhITFnCqyuY8R123del/YPGvB1 tif94GPXVhH6xmPwGH3aTpSUl40DOtHduEyhK8ZNEqoR9MN8CVOC4MnVkEtjJMmxtFq5pTK8 iPHkxcquQMPa0TilF+H+QLB1C1wIx9k8kHNBhiz+yHI57hBbtHttGeve4/bjQTaI99ZMaF97 iR/Z5PDzSo1umXsENuOQW1b5rFjvjfbHng8qWMnzqs2xAl2PYeoiOYMjNZf7Fy+fRuUkphHG Od8BbQ2yMqx/CJOhxdNqwb+bCYenrdDXHJxjJRXDAFSeVeGvWTGgEFId6MaFCV2hsG0YSGTF hBzD+UYAqlsJk4KI1QPrhDa7KugA5NEE6Kn8ULihWLMsNDnMmb1gOBjbsIjiZcyOSsQmIKKn aVM228aC/GDBT8V+b0w8zpmNlJ6Gfz37LZ9mPZg/+kgNo68go07WxjOY/64SiD+KfgJ2NDJZ +6e01IGgelrj4Gn8BJUZEi7WbvQRnUQHUmNEOk2wYL5akIgiOnyEDJjwUtjuSFMSi0RvgHsm c/+OQ2fJmeJ+ziON31mJi9PCE3X02WmuxSv7k6HQ3DqMChXi4nH4ybB2iAZM9WGJ0ry8eu3T qMUtI2TsHI0Ta0LdlRYbWFyaTAdVXfDOFqmK/B5XxpwO6sUo8GWmyKWPopTsiU9ct2K5IawF AYPvvnYSD7r0ILZuAqRPVLVx9+rOuOblTuCyA4aBlF6h6mlNf+8PJdt+0FVtr2Kbq+YugLz2 O8RPbpnM4uOTdShnzbhjoPF6JmhQk4eu++2Bpy0n7cunrvPGPzJte8rDz71dBPa14JqVJojL 7X9ICllLIHwH25BbDgueQ9l5Womwd+ZCIF7MNGJtV5fAlVeaJj5A3Uoj9S8rxY+BKZlTKtT5 3cVx783FEc0wjWetXymwabYoUCmugtQXYrYg0ulIy5gTNNUcWixzeAfOSpIma0UCpSAlDbLN 77rKMkd43qB2LfxGxiGT4Tuayeww/ffFSUHRDASqCGwHgrKvIZ6Vcc3Mke90bPGLkZrz4sJI jjbU6mIT6B0My7rAAmbcSSXbUJg/9bPtKrBLWxrgHStkoUGhVSj22lNX6GXsXQ0ZJO4u/PiY l2SzIdKSv51JkeQAfX2QRjQZUo36ZRUYIzqMf595fOwsMxaRkQfOwtWHQfWGFNlkXQ5Ula/j QqFNHGYyWEy9l8juA+fwkJIB2o3jgZgndEoZjkFTLyHbdaR3LAcusm4BxNxCibl/Gql9js72 THESNMgGPtZvRzee8mcNzbPZgn5BEVfTZwSJ66oMd6CmZxRyAcbCT6WGEr6Xr89rXVfUbR42 TfAnRmeSCRCUkVZuDAqABAhO4lcomnYysEaQpQR+PLmGMHMQPYViFjdnjaoBC3hkmq96vHU9 wPZMaTToZIAhw7OTZWHBu5VIdr2GFD5K0o+ys1i3bj9CY3Rwz5nMTBiotwLjGBtRuIXai2/t yVM02GM1R7MEqZcxxMz0FJKUaONxtPCFaZ5Rx8iHKDCU2Q+THz+eTfFWIvBfKIsxPVYa7J1h jFDs7itTqFq0QN8gGBHfihnBD5S1LF/+6eTY1GSTu0M43WzWuK95gorBaNICDxmfJ64tyKbS q6MyjJBn8NBbmh1zgENqMivbie8IaLg4Umw9vH5m6JmpZ65I916M1VhnEHr1ABmDdJHoHaZ1 IXYYxxBhZxYvfTVaoCL7VBdA5DGmDz4tBH5XPHEesivRMwm/6YehbMFcJ8dQ4RpR/qGA6YgH +g1wQp3+osJcQBnrILWI/Hi3mm/y8dyQcCIlYgL454rMX7PlDNRuHGdVbj7k3Yq0aVGxfork rtPW12LU3vnyAK7uTGdr4I93X/0uJnXQcCAxfuayjKpkjBeqc6CchxqxPIT/Oy4ESXtXMbOP HqD098PZJe93gtjAwWu8jv4E53UcI7Y2EehLI1okBDGGsguFxPCMhqTgu7S9VDPVl+TUOjm2 6sJAYFuMsJVa778sD78MO7sMZKxWeYzyydBEd8Sh9V9mifM2rlRxe7xtcc4V3gBcgcTqRszn am+YtlUvY7rr5rtoklA0zKndqr3aPElZPjjavTt9vMRdDncRsbE+sGNJWrJm6Fbi7qfLNwqj nMMIzE/XzC+gcsroWM04u8qoqqoMuBR/aK7ywsOHQVn7aWLUwKppmn46OLq2d3dZqwmg8TJ3 HlUXfaycpXBRdPtxsytZAlPJsdC4taP6PWBReueDIGKskIFgpYphagPecT4cqAku/NgypAKL tZ8VekERv+G7wP10ya9pEVBpe24dyfFABlHRp5JxMk4DLOdRke80PmpuXCh+NsnfmQpdl75+ bveExcL2N/SqXNttAU3Pb+vunwVaQcg2d3CLirocXRZoZyWSHy8RCvDSgZDG4S1X9l/cdvSZ KeOPThaAR1DDxieFZsGbxiX5FDBLhWmGON1lOSROa40ewmOW24ova1p0qUy2S3DnFlEHnmS7 5hVEc8cH/Gmudvc9152ExYWFhQ3hVKbnw3jGnkX9pno0lX/KqmY9TQoCfOCno8CGl+a78+l+ KaYX2NlGa5CwvJCYnLn+CLs6wMQ4cA9Db0EgP6DHT27vj0NAWb8JdxFqe8xuVl80nnwAPwR0 G9r2hV6U9WfPlH1v0SuoT/NigUYfiIP5fjT83vIjUU34RzRf8a9PZkTyI0UNbcb2jWvuzWWT 1coKhpTuReNdO5F4X+SIZASdakl1jHEo+hMkv2pH4LnkvQuqK8gjPWvNYmWzhSvEWjSwi0Bw Jps/jeGbmNoF1QsiCOX8Gkpwahdf0CzTFAdCTvMD3N22dNXQXYDyZFgk9WSk17IEx3M5etxg s5HIb7GGCOm27K6RSEDAgPi9gjWxP9+GMkTImfJYMgaOUavsgphKjS+A0TcNYOZU+v4984UO vLmoqlQpV1kTLAPKk5yRvFokCyF/C/KGe42m2ZNh55qwvLet0p0HpD0CtxDoeFkq5CE+OykE ziaSGTyyM4XPbUk56ZO8O4jyAgotypelqY2QiC0k8i3F8N8M8IsCtM+j5R0vhovZPE0+VY0U byRXU8xI6gwdXQYwzlIAL/GzrNcHY62Drq7qBGll14a3xkKhCtGEa+ARk1kMRx3pODE5Syk8 bX3r8PxMFJIC9tQgjztu2ZFWeeO1vCxlmAcGQDAbCqTW+z0bFZCXmSAhNH7TsFft61KtF9aQ S3QgmyrVGtfTDQUXtWTgwfadffKY1mlB5Fn+mdR8/8HR1S7rk6Pz842DC13aZaBnB8ePbk+P DA8OLnajLKa989C08sTp6W8kVCSJV9+uDgjO+P2vv1tzaOVXx3kTiTZwIsupR1spWkY9ZKv3 IbeObB8YNHOta0iPXl+wP31xcPds7uCs5noBBST5hPgvjJK/tlwzUNMw/JHIgP2/NErSMf7v s0r+B+cw0v3j/mv6f7H/mv4/2H/9P9sXMu8vX8i/fCH/8oX8yxfyL1/Iv3wh//KF/MsX8i9f yL98If8n+0IytNisUP9Q2AM8HN13yuWD5kEFEpgCdgjJng9vi4DCr6rSZKrQCs4lFs2x2VI/ 3g1CILjMGahoUUt94Gh2EYIm3J5XVNsLu/TIKsPdxkuU/kJmpEbYXx4wNIh8WvlxHlhGammJ 2eNCtYV1EI6sKBbdHVlRSoRYyjZ35D0wCUV+uCNdv4WCVHNjhI00Z1nOYRMV1vZTxYh1/QHO Hx8SHQrSoZ/viD6Nrye0R/2eZWqf1uP4dx8/xVxeJiqVjtdcnpWv1w3WqxT77xFcFywj84eX Xz+ZS2yZ5GQDS01p+1OQXdJTkhH2u9Z1QdYtqoISGTWC7P5lFEgxDjKniXk64PHHCfDvRlW5 kpZ0F4mHIarnuFiGBfAoNWUwBd4bFFFhmW1RRWXS1XGLsaqhpxGGf74yHzjHjZwelQ7OhccS JswlVuRUHReMk/eARfueW2uppv+jgUfURKEwx8kwb7a1ztiZxPjeOQ4yvloGaHJS9pJwhc/t Pdl7cbRPZoKp2U+cO52akO9KEmyJwsiHcGt7RYLN43dBSgbm3A+60Zm2vyQUZ2smpIWRLIHP OtA7QLbwuApXFiee+QRr+inNUyMUGn9EIDoQCcO10KOG+6Y3ALf7MYl/johzAMNlTemW4hI5 l3uXVDCUUY/+I5e3dNGabMc5++f6CL9v0OkIMxl+RAJ+OvI+Q9ZkMgbsstIqlo7K7+ssxbEE f/Qg47CLRG6Cb+JbV2tiDXzDrrHBRm92KE/LPlicJhgCxU2AUFGslEbnTaKkY1EX/lr00cIY 1x+qBnFQGlB7E8gq3sMwfosw2A17wioyUcFMWja0M1l3NihMkDo3Y+jw+9WrSndIrLCYR+yq kE/EhesJXoeyvzDKkzJ8Lsf6pDsNIR/HUFjpGQJjTvZje0qedbg7RFxfaUZvctcFn1ct3N9D DEfmrJ+BhCTXnrC1gSEY0rYEX46c6l7ZdjFO29aZh374hiCJXGlZgfoo4buOdDAsainf1BYr uQ5/STYz2Eakmc0nrvJe3GFKnVbnajF7aXzZ3oVB9bBNAflSH6oaGhyR5fTIWZz8AT56+G54 PsgiOmw6nLeXQksNpvv3zcVar2ZXAX//tqGs+/Xc24u2T5Q/9APY2wuhSTMdHLNggPgTzieO fUIgRcEIVMF7OYPGefS3eT7HBdUKVsAV4Rrhf0xxHBLykKVBiUstD16UR8dtiq6utNqXWIX3 w8ENrpLn97H0xztPMV0uboA0QgGiBZ1ewj6lupPoxROmQBYjR6MW1IKP5XOmgTDwx+urfhfj o7IiTV5CfLKsPMdRQw+gBw7lQ2OmgK+LMCm8D4W8BRaBwr0WojYMQIvMo42vCjW7i6gUYaHj eFVDVfTbK6HzoVIoqv1vRCDIk/Hj0UTV2hEbJzSBx/wBgdsE1MDac1g4Xjgx849qzR0dGKB4 FgVUB4lunHGkOBdSQ3ma89/hpaYObKB+hQy1hJpG+uai6iijFo9YbjfycXFLhZgf3XKtzePa pplrTQMTE7NRKjhlB+BbESWBHGu55RAc9fn7aTpDpHUM33JLrPxlq0QtzApopYP+heRQZ0fr exMjaKG+Y8gQGX/bCulTh2aR0xulh4fpZ3vXhl0oO4DZy7gW2KHebJUd489PP05kLc+8KIyx bGRHH5pVZPbopCrpZdS+9IWqwxZRAKsNgHwzl5J9KnIVe9x4Gqsqd/LPn+TcAnK5GXHbmYQ9 nz/QAw60nvE62vE4GAuu3jwRWc5EGJZy2TviEZdviRafp65qQxz2vjbp7izXYyFY7dJGIU1q wp2J3nVmGY1S8EEYjRUjPz7Cp7hqB5k6cAiuWJploN0KfFcvYHsXn4p9cbge0kkGrVax5YTb WSqjaKdhPEoloBzDYwtBCf/cxVv0yGDEW3IT3xnP7EJg/iCKvIvRPoL14sJScUTI1idcWPal q2YQwiEkIHLeU6vV9e65uzdjREqjvYnKD1dwYdHO9NxoLHRaZJJbsxhqD627Hys1HwbfWyMF 9SSkn3zUkF4EAPZKzNBGXOmzQg+aGwyDxiCt6kTgt7WvcF9aiX3vMPAF7xR8zacy50ywjbxQ bBklQUgod9/TLYXKt96dR7uejSgA21WYDYdwxdFY3rTUNRIXLYv5wMuTGE0LhnNl2VTHic32 0SZHo2fLC4iktsW1bWETZ6AW9yenvGhrnl/nCHx2buqc0W1m0GnYx6DarCE53vroqDMtqZeB vJRXB1XiLGs/fIkZPlKFzPSou2qOfE9BVlyVpVDeaGPOTIRqVFn1pMuUoz8TEC2jaL6gZlLn DZDzTQIYGf1732ntMmcOVEqViJmaog6aFaH59qhfZbzTx4ST1hRjppPsxfqauy5UFZXdBrqo lOqrD62NlOGLMnQUxRWfoLnGWmjRsyQwJFdoc/ijNA4H/BSvo6UkH80XtFC2l0E5p94Riteu IR+eW+ktO8+mbmAAPDNyCV9H9z8IxRdOyPe7f94xEakonAi1m79Zn4El53o8sFDnerL3GmTd zHO+kumm7pcPhg0ReolcX2/btGBBY9nq9CAuZzH78A7Hv01r9sNlDrwjpbGqAZ8IOMcO1McE qYRAmC8iXpnkpFPYGZqi/ng3dyff+u27DVhTxm77D85PTF1eDO89XJuTT88iCg6uLk4vPFzY Tqa/clWMHy92vEhkQM87De7Fs7qWFEzbeD4YiJpvfP5hu8CFfxmtcDtf0G0zdAyKm9WaPoZg /8W+0g3gE3mGwKSK5Q3M9OzmZdByqiX0dEHt/O1yybRE8LcXlq1rk382SNL/bT82C/MfBsn/ Yj/2/0sGSfp/3JxN/y82Z9P/B5uz/6e7TOb95TL5l8vkXy6Tfx0I+deBkH8dCPnXgZB/HQj5 14GQfx0I+f/WgZBiVhoMsM9kTuDwt1u3VUgambL4/Fm473uyU0gljHNDFC1EXzhvWtlvLsDz Qvmd3PZ0xt2uvrDk52/Fplid5jfoJNVC0x0sDO102MAas+V4aGF+HCzAVZnZ64gapg3/7TXX zjwlREU3MkObxPN0QfUx6Tz2lSPY0IX6sDRiIDzCKvYbmJffiJ0PuzVISo5RIB2G7W5+xLXj O/HOQIEUYjZkokFKH6ohy3SBhnSPoculgHuQbrlNsNRXTcKWtfcfuKa2txy0pLRLhQfAsAp9 WQLDKlTquftk4/I+fEtUKMmen4ufJxIAJ3I0yTiNByfJJrfkIYt7UIBj+mLXBT6rOV1QZT5q Q4EE3YAgmpdcVSsn4ffd1+lvu6/RkxxA/KMw0fdClGDOiKlIfVEZCqTOdz98GUchSrn624mQ pv/7ToRUsTuc/S9OhDT440TI4X91ImQz8n94IuRLJQuqbIKQebUcF0zqMVwXLJtCZZ+mAdmx fBYoFFuBY699JQDRHdimiNs7KWsiCIf2xWjQiVLtJTw76kzIPvfSnLwqlkm8H9jbfiY8tDv1 FLNP9R8LjooNl4O+2nw0MEZ47x8eajwAECWsIl/H6r4KIoSzy9vJpVlR5Vgws+bV3VMO5Byo XchlhlHCxVUHfTn680RIdeRkovhYkKaKpZUSI27VfnzfVqyHABi5dWvnQzRfkDr+CHe+fQdD xFWmJKVL+ETV+GSDRcZWwHoFw/QsT6I3Z0lJC1+Y/BlyTDl/uRqS74rFRtevki2J4T1WFGG4 KdnRxUTrL9T5Nle+gMkIfQ5vSGgjYhjDR8I03G6VSfbCxuQUEbeir+oElfHoq6H3ldBCySer /u0910RHzOZmydm1x61JDvK0bfwEZaoQST2UneYpKkiYd99Wj+lY+ywZ5CpzfeESjid8I2iy YtxxNwADIb4u5Ji/QyftwW6xM+7HwyA/HzjFEcbN4YZXD5YNsXHceuHNrX97HwzI2U1QrQDu FGOqzUoBoBQ1OJukEAFUkA/fii192U4gR0EJsG6wsKoGK653QzccYholW3VkyZijOjHfwOGT y+TBZ2BTYLwHWwC8+RWjjaGSeDI29MlEjKgdcUa+9uPcBCz3RQdGU0BBRyifKhsH/GwkGeEL CsXeT+hoXrLSFXPQCNTvcIQhoavJLKMrMLQTxAhtjMk8C+KEGXOtpSfx1YvlEYeUQrQKDXZV tL8S7DYmIcH2WGDrdoTQNzSsn1lJNlzXdHyvcCA2JTxMdNye4awVAUtkQywcr8X2i0UAX/FJ 2dRb6f6+jLVi0oLwdiLk8t9OhOR8Pr07WH1omGfC4hxwzNGcQl+5V4fKZ1wZPf80cRFm4jvZ 27w9ObMaOL26Pm/F2d7srOBZGt4Lv0y32t2HGxHFrg+ccqeRvO7w0vzF9e5wt+Uh8dbJKrJU BxJbDZM2kY6r9IfEeEgD1kv73CGeOQzlp1T1lDVjcoF2Hf0aB3lD4OXRjdY0bSYJZuGP0TZr hoVD3kRu28wSBNXwzPzj9oinbij75odPkGSgQ7h4q2nEJafSdhv1mALNhK3YG2XnU+KDeQ2V OfdP3Y/YnNwQowCbPhVOkewSoJGRR6CNJPiLhz+w8T4FNIS6OUkepytFhsF1I9AlQPXDgDdm DnTZBRuEpQAnKkxM69EOwfX8MEyIk+0WrM5x/AqabVjIsjhHdV2B4oDonSpjw9YnWxqVtOyP vlHjXowCjDs3dzVK/4kvvsvu85m6wVdlg1YJ+kuul+voxW8YksjWJK5x9iPbvZpqx9JH2+vl 6Zz3u4uz49mo3Fi+bdK1mbC92I24HYM8V2rDh9peWsF86ToqICMAUDqT6zy2SAXIzOf2G2XV 8xkwDF1sAOqRMwG4nyEZRHqLlaO6vgMwQ25CQPu2BCG36p628fkdc/LqQ59uRZLltH/qNbYT eH/woOWBtLtYiOw1r7Nm6tsIER2Pk4uYu//B1T4qIE4EGaEAYoE/6zulOKXUgf4UbVqlvVUo dtcmJT8zBXJhdXmfUDNHTxchgrIfmGI06LsdREBcPbScTWzuHkXmUNUKccVvk7FG465B6Ige eJoZw/rQiZ9GOYjkJtOMZw0meNco8dL8uzQV7bMydV2Ri0p1OeViMZrAEj7bKFiU1c1tSBK+ UDvGPf6A0yTL+cKikrD+2JNHby6td/Hxfnsq0Pu3AyJT2PgodH4eEOkkPTzH20Xsz9Zkb06R i1e0H5GXzRbzFcWdos6fb/2zK/aOhTSEEYkRDOxGGgu/V7+AtsVY7zab7p3ysL8bfnykzN4V zZDbmNDkjfzknC0B+tAnT3Kk4/oECEYMoc5kxkhzZua6/u8CERDXlYvXrEYfWGJT3puZ+qYD NpjPNAeLJw99xWZhCtGfNtj/SHCc0jMXsZknEKnxQ/LRZ3t2gpS6d0hwNV6taVNhOKVIIsmm TTbta72MLKtAWKgmz5z2V38E5kNEN4r66Wb/WxWHUKwOz3tgcoSgtUUhzAlJC0hy4sUAbjNG MTKVsnbAxDys0+d75ZO96bvv/dt2zC934we9Sp6cl1TtnO7NLZ7uLi8320+jB2yuz4Npllpr bU3OveN3SNzSlHf/whL5t/3aLDR/JP4X+7X/d1oi/yvr4z9u2P7nF+W89QtFJeega/8zKm/r YPCWAUUlqWPxlk0NRcWrY2fwkz0qeRMLAztJAydZKwsdyzd7pa2dPZ+xji02HS0UlbjO7xFa BgYoKiUTfXtjO2y11xg1Nh0dHTY9NTM2AzX1T2J+jTMxMWPTMP+W90Y/8xjp/yj/9k37Wgbq V6X/it4Kv9FbI7+I/nWGoFhoabCZaGmxGRmZftLPMA0NNgMD48/wG/3kgpnljzzm38NvBPWr 4Fvlt/BbgV+ZLK89/Aq/pf9k/ZWLn0NmZPnJGdTPyGvBt8ifv/8Y95/Z/z3MxPQ3ef0hg19s 0v4p863nX+G3RulfhUr7Fn79ZqCn+dnQzwaYfmfrV0Ea6j9J7y3jt4TXAb5FfkrgtcbPwb41 8av6r8H8HADDb7V/1nzLYHmb0deab+GfYnmtRP+7iKB+Te0/zdyfeGBifBs+4x/q8Cvtpxjo 3xLpX1t/K/x7BYbXwvQMdH/ozc90mt9Fw/A3+qkKv2bqH+ltsD/V43Wwf6Zf4/1F/7aBn5PA SP/v8xgYfx/C75L7R3rr/V+l/1KLX/S/vh3oWf593u8EpQFFJWCpZ6VvYmmE/XqbWvJY2pn8 SvgNh/gN7PRsTaztrWyx/9GfmulfAsjfKvzWwG/Y8Y9oYa5jZIdNR/9bEV5eq8+v6EDxNm0U tDSM2DQ0DMy/6dErgxImdnav7PwEkVdwoXlFKHsDC0VsJrrfQsI/QyL2OuYmejyWRuYG2K84 xadjLWxgYmRsj838isZUyr9H6OkZoah47PTesPdnxhu3b5G3bt/+g9H5KQoaepbXfnU+/9Yn C+MrhvE4/s4BPTXNn2TA/B+DKM2fQZTH1kTH/L8Lnr/POh0Dw28q9Eq/dJWG5U/6+ZrGwEz/ B/L8TVt+r/Rf0R/o89rIH/SaDkVDTcPwd8j5Cwh/4cJb/Bcc/QJI5j/d/VA/K/5e8I+Kv4dZ ftf8X+l/1vSf6PnGws+7/Bev1NR/x/Mf4TcufgfCt2/mP9X5Qwi/sOePitR/j56/YdCrFBl/ +34Twht0/PYDwPBby78a+gMs/y7hbSB/RN6q/BztWxu/6r/RH9PG8FsTf8DnH5D8E0vpf+v+ l2Shfs3uP00e499gm4nulQGm3zljpv8jjYGB9k/4+SdIe8NPhtcCvxr/SYwMv88j/R/0NhCo P+bqH+i34dLS/lPGP8HXH6DIxPxP9FPev2vKn+nPGvJvNfrttvizdvxZS/4eQP9NAz/pVTi/ lgZ/R78a/o8BlOUfAPSf/6b+9wD6Cyl+A07afwmcb+tCGrp/DZy0TEy/gJOZ+hdwvoX+LXCy UDP8CTgZ6P4Azp8ZfwJO2j8BJwP1n4DzFS9o/oyc9H9GTpp/Xhr/V9BJ+0/QSf4b938h6F8I +heC/n8AQWn+8SGWhu4/xdC/QcZPKGVh/D8DpRRv0Pf/PzCl/4/BlO7PYCrKLyYqKkr2Kn6j t67t/g5Qqf8toP66zX+KiYaa7vVCQ8/wOkvUNK+X1xuOmYX+TZCvjzM/F/TMbymvoqWh++PC RPPb5XUIr8+nr5c3obMwvlWnw2ZkYflJb5UYGF7vGurXKtRMb0/ab8296h8L3Vsuzc8SbwT1 FmF5feR7IwbmV6xkeW2Gif4nsdDT/qSfj0b0vzXL/NrNL6Kh+e2upH6Nsbyx+1qEmfmVXhHj VS2YXxWCiZ7pN6J94+41/jpAZmaG3/tn/MkL1OvjyxsKvTLMwvj2aM3yys7r4Fh+otBbDi0D Ngsty+8DpX6FBybmN/m99kFD+yqLtw5YGN6eMF8Dv43ub/QmyZ8FmH/rjYHpTRSM1L9d/iwL Bro3sKX7bYp+Jf6nBPVfFfh97v/LCxTdq/jemH/7/sdB/Zw1ht/y/1XeT7H+u4z/Lv23GqCh /qla/3D5+5H8d4ZM+zqan5c3DfmpJf+OIxYmlp/0K5Hp9Sfkz/Q6r0y/Xf6oykT3B0H9DPzK oPmNflOFt99KZtq/I/pXontVV0a6N517U6DfZ/j15mV4A7p/xFuGf8Tbf97r/e/x9l+gyk/M /deP/a9sM9H/rk//CLnMLH9ALg0j7S/M/Rn8Xzz4s/wZcqn/9ODP8neQS/MnyKX5O8ilZ6D9 E+Qys1D/xrigibnBqyz/UTb0f5bNv/Tf/MPJ83ez72/R13ua+VdTf3Pv7FEwkZcXQnwuXhOs Caom9hnuRuQHzFqV5uY/EOzNxCbOhG9RQaiF4+ezxiNG/TRjzB/OhsrQuIdjOoGsZ41nI6Wb bRP6jVovAsVwBIVuLANlr72PhvXbD9dDtlWF2zn3hlPV9yCdULuwUfSUBKUZB7p2BDank1a6 jt5lxIdWidmAczD4URq0Shzw9Z5c2PAUApJkXzStn1XiQJCPe1JYVzmtljoyoMqx/RMPHoic m+pTxWCUCN6dRHzkII5ExkwfMwt6jt9Pd35vJyYUWagO3tgS+/zp5qt5SuKhiJGreTYdFeKC aKhfsC1WJ1nszqxKvc/KEgQf3WSoFzRbCMS3kdFKoXxAbw+vq6nsrZVsm0QXifdfnWLa5anz 0NQ+BJu3EGriSfa/jA3AySu5b0Ph0QgowD3Iuy+RgtZwUJMQ5se/VI12odcgvfcHucrLCEMS /+JA6aqRI/khG59MEsQISanB8fSE7fNnF2en453pxfkKsXnLVYUXzL50QO82H5dbcGjwEzRE y8N5z85OHrhJPr2AXmgsOKP6nkh0BladEbVgvX4CgsiMjs8HD8NK5cp1zaZ2u/IlFl974uT1 Db7tSKakJ3Lp5bdpK+pMHm+x2K2TODNRcOhN7ZAkWyWOqVVrb2ZX3w6RJZTdaZ80w8wrWS00 HuRQqDVYrFfVGM6fRt4er96KnDwDgcJgcF4WKTrVPi9cfMxgSGW/vjugGnNzvinps/tGpd46 8/2aKbFCvc3xqW/UquPheQ6Ga639anrV9RaL/dH5PGqgUAh2MWNQDgXXeTgjgcPCwuI9ccju /XGQd5jgfh6+7LkBsbUP4Ji1N9msNltjDgdrJ1A6goqVPT/Rj0w6t81Ayv0Qy33oT8/7gHgu uADe+/7Y3wWxgPGAs/ZDqf26/Tz2IwGRg3iCuOkDcEG6YUM3kb2Zk3R42AV1EQTxAPX+n/bO AyiKrVnAioKCAgKCkpNLTpt3iRcJShCQjLDoEpYchSWrBMk5SxSRJAhIzhmWJKCAgJKDKBlR QUB5i+L9vXDv+//7QtV7Vf9WTZ2lp09Pnz49PTvFd2bWaCiBNDPhPkbBOHe+NtWasDntAGrt +4PZTRh1A568QjQBBxvheYwR+6nKeN/37VLimFscS1wNfOcfnS6+HoyMD3JS8XKK8HUwukXJ YUgCWofJA8kVCo+deXba2DlsO5+gq5CI+Rb/qympvCtQ2C122BS7ZaOmZTN2qUFp4NYF7Izh UqP+UjNndusdhgZJhiY0Q2NWn4pfejYOyIAjdvclSmrhdg/t3yIwWQP0TPMG7iKTcIR6LQDI lIW7d1eFV26F72KFZ+IWzcSU22gT+RZFud0piSmBsROb68fI18FEhqfZKO5fsbFM2Buq+NLG SMWamLHR6k75tEz1reJ5DSrjXmmXp7LQApuotMCOzIsJ2RxMCtfUJVvJ7tztjAowf5uaF/vk 8rw0e9DnTyQVv90+u2zc380g/GSEB1fjb55NV7/uOt5Oz1jdfNXGS+AFkb4glOLmkJbkiFtD T2Q3wZUV5enMb9Rm+Znd4iaSPjyfOV81Rfl3fdyQ61WMzOdw61WJ/dZTo3021yhLrs1bEDv8 EnsD2aHHMupg+iKifSkvnLo45nHxgzPuLGb8s7zOpEPO6eGsbVevFfkxpA3LnXEU+mR26oPK ECyWRyJIaCfjFWz0VhKgWD0WByuiK5oisGAVnUlzvyiDwhE18lQF1l8FZ4z5cLh4FY3JcYy5 7u2oSpxSKZBV0+JQObXgAfWuUsF5XUAVzcp8Ws0ikZDRUDRRRYk33A4MFZHc5PUiRZv5nL0M 5DVU4GbSKLgFfdO2MMJdtAqqbq2OGrIqjNq00tRc49+9WN9dsOZX80Biqp743NkmdVaFePYl arLTQ/cXp7meyY4CxqlW5RRfMkR8CK+dVawMLJQHcoFjMjqFjavtmyoFx/SOO3DKRGmZzQ6K fjBiHeOKCc0bpPgoLqaE2pLe9O7bbqJilIp/0FpM7HMWFqCjczyxWf6ma4nfsmHp0sUv9kG2 iWPGYcMFSwVkovOg1Xbvm9txLWrOdKkd8A/P3eklrlLr9CpvvNk9/mW4+y4nM+okeaPuOw5t H+fLT4R0uKh5fJovp9tqmabVVAZKtV6084qXq7t5PrH1JleUHuXjY2YPz8u1R2HkjFVjSrx5 qmTMI1CM19fDxea4XCpr1PLjVtv3VGtiQuXJL99sffyYC5shjXwI4Q1LJqP1pf9A2trD6hB3 v//pp22E0qBHqEknes3YKYcOc2blUsZCLQ5FXc2aOrT4ipubzx/kyNxLeKLN/0IEh6IvqpNS L7r+YexzigvF3pdFx6LdYiixNwpJ+Jv0uX8LNQ/inGBjUHnLrTkH1NlW1Bac4/YYsc0JHPyA HnjRyke7d6u+/zljaGUN+VjyR1AhpWv5k2QyIHyh9EyNSG4k9syVVrpGtphn49GSEjly2rKC 4fBaC8mP+nInBa8+o/BmJ/q4akJCvkhPRzma5aRS0HAvpY3pm/mmNap66wv28/uBF2+6+tOl 3Dax1vkCPUScMrHSnmAf7eB1TY0zJeYGD+0GslWSYa/90W730YPqBq31Auk5mn7x21VGfHJK O8wdw7CO4bjIvFq6kHd95wYN1EtzMemvGzgAWf2upSPxaeb8oY6PDPmJhE/D2Xa/vj8zOB1l ognFaPDfcJfTz2g15/BwFOixa6vQm+87N4Cs7nt5X/NGzbPs0FacEM4Lp8u2iEgabefhbzQt M00PwYydvHa6cNi+5PGsQ9BI74QEO0Ta0G6kjY+0jSLBrVDqpF2oIQSppMaAy/5SJZKtuni5 RzPf3DSMz6LQIhSIgwFQVJa027SMXqURssUw+zvFyqZXT7yJS8innaa7qNqvzJZWWmPtUDmS lJb6liKubpR1PKBF5LnNZyoefvEvT5Q0NQW0ShNmP2o5ff20F3xWlY4OhHGvktCxKtn1+2oQ ZMWem7I43yJnYfLGQaG4K9SCMqbtWVSsvByhVdV7XjIZVt3X0u4Qqt4WrIVJ97AcHVZSkuC1 YzUzn8yO58nTPioRXqM0aZpPhkmy1Yn5TV+QnLy6VHavBRcryHNcgbJHbLPHeamCvOXOmmQS +Pbb0du9OyluqzIx1UBxSaaHKmXQAFl7Oic1hGULmV3ngFnpa0o38dinSSlNRla56mh3oKuj rvm7ttci4cKPNUOVWx4Nfk1+Jrc8CdaCSRm7r79uDxdWlXhJX09pdiGirgjIF1FGat1i23aa HRuaNojNpi3ngnkBVDX6eW6AKHJdq4i2mi/ek3c9NrJmE4mWvn2xPkfeSFDZp56XUo2X/NgZ VuzemGsgB7dnfvuJSS7BC1mztqNtuWJig8kiLhkn/YClpiPi2+P99KkFoW2BFKXCgazez4iT IJXwANYwWZdYQT1mL7PdbAEP+8vuuUJjLtS+kWJRGr3nmSuNwxzcA8P4Rth7PuZcjN0gfy80 cV2jKnnP1qgrU2qkVqNsjqLZ9yJu7vbV2ukNJ402jqrSzvs9KzmdrXKKz9F6gTGdU/GuFSCN F/kF/NdwA1fz7I0dSlRFIcbVDh7Lr+73LPS1dvA1P9R0CjJVh5MqO4uIRRFsOLhyutmpoZqK P1Ey8dc4l4SS3ve2AU7oLok47+mc2EvYJNoB/2b/6c6s+NIer/jODrb8ypvqR8svAIJ5fC63 qHedviELZ6ubwxa6jjVKPOQjVNInJSIYEhMkL71XRPvbunPtdJDV22CS6vdIcn3Y8eO9X9LC CbpnWt2UGu42ew8VzX7NOoXe6+z8+rnxW93tb9K982wSInHDnTcTtaPT7GlQbWNcz+yHyldr U51TdL9QTyRrruT3FIwS1iCGsQye8Ogz9zhHWO0qP/A1Dt3deempNhUmriJM/RpYV707qPEt v8114pg245laxiVcL8yFttmk8K7j2Yef2BpeC0rZFFQ/Hts4HsZa3/wwleGz5BPjU3okc+es JXmGSeNuWDcVbe7Y6jY2O9mK8JX7AJIo+1zJptj4eMvRyI/CfDs3qRpcPDiaEhG+uOrJIZYM 9zPGdyjWsy9yTm5RPGbfym+0v0UwT0/gJXhm7T0B4u6kIwLt/eHKrEhgSWp6KPOUM+dl3pfi XiWCk9UnBAhlJyOfdu2REzud63vbkBUxzro8zG1pRntZx9Tp3Bw3fC3kG+GFc3VeE9XrYrzu GnU+GxK+q7QVNAueG+LBjKd0L7SBB4+dcFxj+1AzfC5ok3btXs1SLZ87h1jI2rXjYTMbdnUS lS7a0qG1Ac4VOZYEsLHfRDZtxzlPGFcdX5tO999evnveh0A79XjE7U632tEJxFYBoH21IcVV hYcgaX1zoTGt/mQ5co2B6s6xCYG1b0wvx8mu8l5ZozvW93VvYu/dKqRbbCpsc8gtjzRyjcSy 5Su31zALbNrJI+tdIPE54wJhVAWXK0SMfQtgS75irEC5yfY1qcXDv57DTuLz1qqc6L2PFpTk j8pSp/nW1nlN6HeD1ljKfbh9ylmGRCxzW2izl1YpNxtkw65tei28j60gX2+m3GzW7A1uOXF1 r6bF+5ZLHasdIdaZndLG02P8eIDfjTDXecA4yXYbs0IN6cc1bJPU6Nu1OGKbOZjfTUBNyLsJ DtGm5bN799au+UtQ18ltYaa/EE4lt2yINKUCtm8i8i1Zd20YbNhRFBdhQUGaAlH8uXGD3xob UbVbw+lMXRn8xUY90YPofh6OgRNfaoR7KuUXKq6D8lyklP2JPdwv17u6PzPNFoz/Umnfk8Tf Ohgx4rChk+OdnqP+ZN7IGpbOHt0W0q2nX0zXETLBeTbXJ3IQFSDmEWKIK/YNZK6qVFHdwLSp 3wbUXIzhvwYnSXCUhZrQ7QL5QxIf3NMRavQiMA33u/AweFVnSZrupcPFtmdsfGwp3meN7NTv d53+qo32LjzjCig7ZYYL5wxJ4og+h/F3ije6wOq5dTw6FbdZwZ4rfZOojnQ2AZellAQl9Qj1 vfOY8YpCYHvGo2SOzgQpWmQL5vplhhx2/4w9dhQ34nT61mw9EyJgtLi9oMspAGOkopwyvY5Y wYWksowBzIoD1xVuzW4ziawiXBtqadiFe/RZ7n7wNz6n/njDhjQtmA4yC+RKp0mSpOttS98w fMknkhCQWcO2rcc+z//oWpBpKcCROSP4PFfTkzxWAQkFzVnAV5dOP8lYQcjW3GdtmeRRyohy wkD6+QE5sjigAm1LLumNtG9x2OzHTid8kp7kPi/JFZSkOPcZVv48Oten62X2twpjBsGruhKh MdFtdskgqJfzUyz5pKUCBrbyUlDzsUxVZ7SFeO699V61UNIinzDiNwuO0RHY2DarRGQbf6fc jvTu0gjAzMrwceU3Hz1JaFhF8qjTiosvX0+jSTLFmxNB05aTTnJtrFcGbTbPxcgmDM1vdw57 6iCImDlIywZ3n5dC3mZeffmWm85Xj/kRGUlLa64HGVLm0qshmvLypbzUpCjBKbWIFMCD4+ib zzkiMrz03mN7FCOt3nDO0hi7X9OBQ1eQnakysXxs0dwzK1VlpbSOgypRKN3cUVdWD6XPv0Wc SvMckk6oyRmsBBhyjFuvmnDN8ARPVU27FKbrcAhnJTUig7R1M0evWAqkiax8zIHYK3UNUjoV pavBtswT4kaFn66Ao8OK2CWjqiUTeLLV4Tcefym7a6ezaUI84+6e6i9SWv4bRbfIxPOa5DSo 4ZB2ykJrZG7M5izEVavr3pp2OtI6CTfLJyOs5DrGKKZUNxuhaemfnLxKWBS2A7kW73/18ooH j+OdZBCrsMsu6xj0ighgQtJxhGKMSTDch8/xlJrB5zrVqKcdzsRdCYN52grIQL0ERD9IBLCg qqO1y889oi/D0TqMWtQJiEmqS0eKr8v3imioMHc8alZ71KP9qBRjYn0DIy5Qyz+p1v3WguXa jolHT4KWoqcRXZi/eqg5C/tMrTgB0XLDiO+7wZrnXWMyeWwvqEiMdMeNdR64piBoB16510K8 QRFSPRCNEqWd6Gz9IMzwB2nybrVLljZL44+u17XSFYLVujStlu3cMgNSIuyD1F0AWTYBtVJL 1wyuwGZDTRSoPiIru0ySlaC+A3qoPcfFIeOTo+mxeo27X2mjTREJ81w8pVQZtcrQxbTnwlnZ Fv0PtG6e+LzytONTRtfXz+gX/PkbeXXfupSdsZQjkIxRWh1UwmIJ+k1i7IsHaRv5y+Urwhde faZOSXsd0hBaqWThIbvCyJYvPPjgxTkdN6KCIRkXnpkvonxuy6IjkekrZdpxGvq36eSKtXog I4mc+pvCQkalSWaI63akn2kzX+UqC1MbXnmmM7ukhn1e92ne52yyP4l0cTZmoGoQo0VSIH4t hXUaNLN7KdIumaR1RFBtXpffPkE0zthsgrdJ/+q0jecdYuGZwdQsyiIFzo4iJC2qzjcqP0Gu E9WBUuvYlMFtg41VsUSMc5xTVPmJpqRD2RtQ5pl1hwmd1lCd3tzrZQ5V8+KKgfSbx74+JZ1M wtzdbAlyiY/7Ep9KqB3OnXf/vjavhSH9sCwNhuJVT4pB4jDmVWNZYdaI5ufjZSGORSbDxUve S8jMIq43PQZLUnlBjnvVvTx7oTNcTTtyr5PHpSINd3c/njtHv8HkB3w4KIu1NTBC2hmdbGkk umTob4Jxc/JLTqa91rskT9SNPuvZgparYMUqkvEGMBYsM+AvS+0dHhzh3jMFk0MqY2LVsSfC PAq2d55UZbo+ya0yWdesIbXBiRRSrLZw1JxZbXMT8mVru95EHd+AsWyMcRYsm+bRC7FyZuZ4 xqg27Glhy4+dFlY0vDAeRut+jLnFz1YMO0PkftGt8AJz45V1YLcB2c6a3RKOc01u1P+EELpR lpaBWv26t7dyGtkFUuc1iltMrCfZWkwf3Sfkm2YRD+mdLEb49E5tbBHU+TdvUYZOdm2RWDdp rUNHg3Vtz5dPL5rO0FeQls8kbtHUhaxOVm8x1YUxT/pVnMDZMjhNn7zjU20LX2msRQQARv12 1o8pTUGYWmgdbGnmbZnIp9CiXleeBeNsj0u0zWwR3wlMnSLeZahviHImUZ6hFQ2aX1PYJalv s1nT3SWrxzGvXdklvtt2c01Uv+HmOrzGP24NpN84sU6+S7UnH9RQ4sIxmbJcoTgceu4Ol291 S2h6+/oTKVZ4l4/G0HmvoONB1Sv35nY+BVu5GseRy4zOST7frFhDZfEN0l07zTSiZHqhYmg2 n9m2q2TRG5VBua0PGRBiHPpwgSdfh7+8ppHanOFdB6HEGo9ATjOvhn2Punt5d3MSUeA7Uk2G uCuZi7LurHS8eQMCD+h6FZ7D+HEz18ve4tLkgwe/PJpLRFf2rRk2BtEAVt10glJI3HFB2wSJ g6ZVS/5V19MYvFrXTxbciqBdC78N56Wyua/Ucsqtey6Gi78UIxt6Z8zf3K450DuvqWjig709 m/9jE/3+vpxXbJlIF/PLZrxqzx3S80xVaKh5bo7P2J1PyJ/VeT0Uy0lLnY0mDXJdqsK+O4Pu +HC2/SnUtEC0Pyj+vY+nhWtSwDAV9DVpuiK9HH0MdcoE25CwyRlScJ6u9YMRqLVCZBaBY0ik 0zJhaSDzFQHCTl6ZAUV5pduJ1RGGFllEteIXRAXZwB95jYvft2chvzhHlNAGhZabug6K10dY D5pq9WPe2UYEdCOCZTI76UPn28eLXYZX7SXGHJqepGIZeSGk6B305JYLWjOXjPC2QUTpcxaH 9hXgbXHNTMXJPnuDPkuVsZNWOVSV2Dv3YRDmHQpB3XzdAK7qxnw6+ecP+ZzPr1/2erJcrKlo 0pjnXIO7geIQAIkPPCaNHHjU80k/vUzgequFekpZgB/ta54FePNnelJXHWz4dur4jYtFLZTp sS9z6rM5AYbUC/bXkjI/U/R4faCo6RBrrbBEzs0ix35z5ZlANa4nVBpRyEU5+tO4KkREruZn Ohc9/Kj8KvpbrXHGS10d8T6UHn/fBnBWY/qDgVfGSc6XrChFGWjsACIiLl28Rsb8QWFnOuty 3k5EfmQMTzK3VHv+w2E6BWKlPoobXJ1oPTLAyPLYuftMcSagvBc6QTI5Chzxi8yz+jFxVUZe LwJia1HdT9hZdEJ70EY8nebukr3bWIPOuK8glGpk2GYeoCow97xflXqtgfIgLVCExrOGpBgF aqOJdJLvxYnqdQNy1PKSGBzIdJ7k2FTXoXpV5aBduYHmKVGEy6pPTKYV5hTdNaBU+YEPEF03 sCecGEkGesVWLw9MW8MnH9L6mkvNiSFiV81ZUW8DcZ4J7QD5XoGnduHDUnKn3LCu4gHnefTj wxjh8iTiNappHF2dUZg3/ML5xBuuimspISYf3/e8S38KtTovqpW5+zEjdUgdNTdC5yEV9DJB TZGWVGbuk8B1j9MOHgP9CQvknm/twrsVtLZB92NDs+NDs7lk1LnGSlotAO3QQOmsvEuxrmj5 C83RkUIZ+vGqlJnRPtwAtLwDWAck3aYattmP438qYdmZ1BJ8wmyhvIaGeLX8ZNokba5l4Ot4 X4O6uT7OIoBe/YIyjaqI08u73YNxzzreO3Z5UM1nBp30o56M9j0FGc1CyzXLkTqZIdKmKnxR dJlQvSy0fPNjXyu6/Je2Gb7BvsdJv9IJuYhN8V4SjKqR/kDQEXUpLFxU0d53FtLBHQmIjLqE kwuNGJW0P9OBpkyclaXeCCbzuNH8lW5l0DbMtxrK0G8b4rtMl/+qUMY7jfVpmrKUuX3kmkzk vFwKu0vsLG1klhwTwMV/VrTD+5JT5Khs0VXVFIH8jvwOa2vBdPzV3TRV6HU5/XK67Bv46/wX +RetrEs26Zc9ZN16THvpbNA2mMXhxGH64cWR07pdrwoHLanpDQhjDYONh48tGnLHLtTk3820 wfSexwgrD+fQWqDmJ9xgfOxOzXVKrs3nhXNNVMFuWbLCujDstvWjzQmR6mCtXoJyJtrlvHHg jjaJ86f2Fy9Ozr9VtYB/27SZpbTCbE7P5HQ9Qxr3Ie6MV+xyS93YDC99mmdlZsW7eLpnWYna pDuRvAb4SYLg5u7UXo/+tMtT9v4xMbfYjMy32KUh5zrB1HR3suD81MQb1TzDmZFvqu7M9r27 73k+VvVLyO3kJt+cHpaApNclHv1YJDRcVU3KiEkpU5bMCiXhelyhY4AHdFNW9wuzhoplyZ8s VfiJ/sPg4H8sVfiJsgLBICTyd+lPyFfodwnysAT45xzbfwYfQI6SXJdtLI3+Bse1D9ZA4JA/ ACvf4SnwL+DNf5fj+p3q+YXj+o7NIOHQP+dqDmNc0IPVAvv/mP2vYlw/Xf/dE+gvGNdPvuZn uy//Saz/jqEdgDvfWbeDfaS/Y+0I5B86fnf5FxbsOz+1v8zggOY/inH9wn/9lzCun14ewCR/ gXEdGPzXMS7EfxfjOojaP8W4DifCz+3/Csb1J/IjHvzMhj/bfmJcR+S/pN3fw7hAh5+EBBL6 0xLyn2FcB/XiO1AAhEGAf8lxAWF/wXGBQeDfoQLo74sJvn/9X4RikTDkrxgXHPlrGIB/u5JC /7yS/m0u9t/19N/19N/19P9rPQUdrqd/Dtf/s3r6RzQWX1URQn9ZVeGwv6qqsH+lqv6P87HI fV//qq4eREOXRVBFWhZfRY2dHVjwnh/s/pXbUjAzwpfE7w/hwwfgewMC/2gO/vqx3Bb8YwUu an+FrSPeNdjPOO+v7739jxcyH77SgWFHDvb9/Sl4iz8MQw4ZBv+LhqFCRwwf2IX90SDykMFr xkZm6B/zu28Cuk+x4p1A/Ur9/WJaCn8nsZ9zorIysrJCQhBpISEYEr+BhYTgIHyLl8HBP1oY DP8dXw7wYiEo/GDfvs6BDCT9o4VJ/egPA/7ouy+H7evjW/jB/u9ymR99v9sGix/4YmZjLY12 MGbhkhYG7dsDg4BCSLAQBMSNH6iZAz7XDlz9O4fBl0MhCP5QEBj+MJKODqb/GPF3ddiPUe+r fx8t9MfI4OAfi7CNHA2N7Vm4JA3tbQzQDiz4pNOyN9vnASECQlAWDN4Y/pQ2snG6zaKkzv1r dvwS6O/T83OeD6ZMCo0/hWxMfunhbG+MIcXPGpBU6PcPCwwKxScVhuWHDO/r/m3c9z3WBzIo Eg46LIMJ7a/L/qNMCATff8Tm4b7Qw3oQCAx/ITkkg8LxZf6wDIk8IoPvk9x/lOE/+7eVf5SB 4Pu/Ew/1BYMP+wfBpy/0iAyGOOIzEgE8HAMhOPyoLyAE8rA9vB70SEzxSXRYD4rYZ7wPy8DQ w2ODIiHQw3pAsBDycEyF4MgjMcXrwY/IECDw4b74G3vY4Vjh9YCH++J7wg/HGYjY/61yRA9y RIaAHRkvCAw7Mh94PfhhGRiMhB2JHxIBO2IPgYAeHge+75H8AyNB4MPjAEOAR+KH1xM6PA4I BHIkX8BIMPJo3kNgR/JACCh05JyBIUFH8gAfqiN5AEMePVdhSMTR8xcJ/SVWDvZoM0tj++91 Q83M1Xi/Hgiq2tjgLx8/yoecNcaG5eBdV3LSLLqiSBAUDIKgERCEsREEg4QZQ9BIAwwIg0QY oUEwkJH4P9dA/QCW0fYO34sQvnxAEaQAgIyyLOl/AFBLAQIUABQAAAAIANlLdSyg/rnih6EA AMDwAAAOAAAAAAAAAAAAIAC2gQAAAABsY2FzLWdtcGxzLnBkZlBLBQYAAAAAAQABADwAAACz oQAAAAA= --------------4C2166AF110615735207020D Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------4C2166AF110615735207020D-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Mar 2002 18:18:47 -0800 Message-ID: <3C994217.A0452B81@nayna.com> Date: Wed, 20 Mar 2002 18:14:47 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: "Bernstein, Greg" CC: "'Maarten Vissers'" , ccamp Subject: Re: LBM comment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Maarten and Greg: Can you help me in understanding the following case? Given: LCAS is used for "hitless" increase or decrease of capacity of an end-to-end pipe. Question: How does the end nodes (of the pipe) know whether a given increase of capacity is possible dynamically? My view: I think this case can be addressed using NMS or using signaling protocol extensions. Using NMS we need to know the complete topology and "its current state". Using signaling protocol we can figure this information out either locally or by polling. This is the case being called LBM. Please comment. - sudheer "Bernstein, Greg" wrote: > Hi all, to reiterate what Maarten points out below: "LCAS takes care of the > hitless addition/removal of this trail to/from the virtual concatenated > group in service.". Eric's statement concerning LCAS being between > PTE-to-PTE also applies to Virtual Concatenation in general. > Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of the > ADMs and XCs out there don't care that the signal is virtually concatenated. > Hence all the current stuff in the SONET/SDH signaling extensions concerning > virtual concatenation is just end system information and not needed by the > network. > Is the LBM work really aimed at the virtual concatenated case? If so it > seems unnecessary. Also instead of further complicating connection signaling > couldn't we abstract things a bit to have some type of grouping/association > of multiple (pt-to-pt) connections together rather than changing the > signaling protocol? > > Greg B. > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, March 20, 2002 8:29 AM > To: ccamp > Subject: LBM comment > > Not having had time earlier to read the LBM draft, I only just came across > some > still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt. > > >From section 3: > > "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling > the bandwidth modification at end systems and setting up and > releasing circuits provisioned and configured through Network > Management Systems (NMS). However, LCAS doesn't apply to setting up > and releasing bandwidth at intermediate nodes. This means that LCAS > must be combined with an NMS system in order to offer a dynamic > connection setup throughout the network. Therefore, the advantage of > using GMPLS is that it provides a complete integrated solution, > allowing for a wide range of traffic parameter modifications." > > LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be > combined > with either NMS or ASON or GMPLS, which latter 3 take care of the set up or > release of a VC-n or ODUk trail. LCAS takes care of the hitless > addition/removal > of this trail to/from the virtual concatenated group in service. > > >From section 3: > > "Using LCAS in parallel with GMPLS implies that GMPLS traffic > parameters may be modified without the GMPLS control plane being > aware of these modifications. However, GMPLS provides native > capabilities to modify traffic parameters of an established LSP > since MPLS-TE signalling was originally conceived to allow traffic > parameter (bandwidth) modification." > > Using LCAS does *NOT* at all imply that GMPLS traffic parameters are > modified. > NMS/ASON/GMPLS are in full control of the connections setup to support the > virtual concatenated group. > > Regards, > > Maarten Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Mar 2002 09:03:41 -0800 Message-ID: <2135200C183FD5119588009027DE5723DD4B61@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Maarten Vissers'" , ccamp Subject: RE: LBM comment Date: Wed, 20 Mar 2002 09:02:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, to reiterate what Maarten points out below: "LCAS takes care of the hitless addition/removal of this trail to/from the virtual concatenated group in service.". Eric's statement concerning LCAS being between PTE-to-PTE also applies to Virtual Concatenation in general. Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of the ADMs and XCs out there don't care that the signal is virtually concatenated. Hence all the current stuff in the SONET/SDH signaling extensions concerning virtual concatenation is just end system information and not needed by the network. Is the LBM work really aimed at the virtual concatenated case? If so it seems unnecessary. Also instead of further complicating connection signaling couldn't we abstract things a bit to have some type of grouping/association of multiple (pt-to-pt) connections together rather than changing the signaling protocol? Greg B. -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Wednesday, March 20, 2002 8:29 AM To: ccamp Subject: LBM comment Not having had time earlier to read the LBM draft, I only just came across some still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt. >From section 3: "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling the bandwidth modification at end systems and setting up and releasing circuits provisioned and configured through Network Management Systems (NMS). However, LCAS doesn't apply to setting up and releasing bandwidth at intermediate nodes. This means that LCAS must be combined with an NMS system in order to offer a dynamic connection setup throughout the network. Therefore, the advantage of using GMPLS is that it provides a complete integrated solution, allowing for a wide range of traffic parameter modifications." LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be combined with either NMS or ASON or GMPLS, which latter 3 take care of the set up or release of a VC-n or ODUk trail. LCAS takes care of the hitless addition/removal of this trail to/from the virtual concatenated group in service. >From section 3: "Using LCAS in parallel with GMPLS implies that GMPLS traffic parameters may be modified without the GMPLS control plane being aware of these modifications. However, GMPLS provides native capabilities to modify traffic parameters of an established LSP since MPLS-TE signalling was originally conceived to allow traffic parameter (bandwidth) modification." Using LCAS does *NOT* at all imply that GMPLS traffic parameters are modified. NMS/ASON/GMPLS are in full control of the connections setup to support the virtual concatenated group. Regards, Maarten Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Mar 2002 08:29:52 -0800 Message-ID: <3C98B8CF.8EFA29EC@lucent.com> Date: Wed, 20 Mar 2002 17:29:03 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: LBM comment Content-Type: multipart/mixed; boundary="------------44CA7BD9F833482B8F7B754B" This is a multi-part message in MIME format. --------------44CA7BD9F833482B8F7B754B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Not having had time earlier to read the LBM draft, I only just came across some still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt. >From section 3: "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling the bandwidth modification at end systems and setting up and releasing circuits provisioned and configured through Network Management Systems (NMS). However, LCAS doesn't apply to setting up and releasing bandwidth at intermediate nodes. This means that LCAS must be combined with an NMS system in order to offer a dynamic connection setup throughout the network. Therefore, the advantage of using GMPLS is that it provides a complete integrated solution, allowing for a wide range of traffic parameter modifications." LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be combined with either NMS or ASON or GMPLS, which latter 3 take care of the set up or release of a VC-n or ODUk trail. LCAS takes care of the hitless addition/removal of this trail to/from the virtual concatenated group in service. >From section 3: "Using LCAS in parallel with GMPLS implies that GMPLS traffic parameters may be modified without the GMPLS control plane being aware of these modifications. However, GMPLS provides native capabilities to modify traffic parameters of an established LSP since MPLS-TE signalling was originally conceived to allow traffic parameter (bandwidth) modification." Using LCAS does *NOT* at all imply that GMPLS traffic parameters are modified. NMS/ASON/GMPLS are in full control of the connections setup to support the virtual concatenated group. Regards, Maarten --------------44CA7BD9F833482B8F7B754B Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------44CA7BD9F833482B8F7B754B-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Mar 2002 08:14:26 -0800 Message-ID: From: Jonathan Lang To: 'Fugui Wang' Cc: "'ccamp@ops.ietf.org'" Subject: RE: Comments on LMP draft 3 Date: Wed, 20 Mar 2002 08:04:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Fugui, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Fugui Wang [mailto:fwang@axiowave.com] > Sent: Monday, March 18, 2002 12:55 PM > To: Jonathan Lang > Cc: 'ccamp@ops.ietf.org' > Subject: Comments on LMP draft 3 > > > Hello Jonathan, > > Here are some comments regarding draft-ietf-ccamp-lmp-03.txt: > > 1. In page 5, section 3: > "Rather, a node-wide unique 32-bit non-zero integer control channel identifier > CCId) is assigned at each end of the control channel. This identifier comes > from the same space as the unnumbered interface Id." > > If the control channel is directly on ethernet instead of point-to-point > interface or IP tunnel, what should be chosen as the CCId? > For example, in the following case, if Node A, B, C are connected by > ethernet. Node B should have a control channel to A and C respectively. > What should be the CCIds for these two control channels? In this case > interface ID is not able to uniquely identify the control channel. > > .1 .2 .3 10.1.1.0/24 > ----+--------------------+----------------------+-------------- > | + | > +---+---+ +---+----+ +----+----+ > |ifId=2 | | ifId=3 | | ifId=4 | > | A | | B | | C | > | | | | | | > +-------+ +--------+ +---------+ The CCId is a local identifier. In the above case, Node B will assign two separate CCIDs for the control channels to nodes A and C. > > 2. In page 9, section 3.2: > "The LMP Hello protocol is intended to be a lightweight > keep-alive mechanism that will react to control channel failures > rapidly so that IGP Hellos are not lost and the associated link- > state adjacencies are not removed unnecessarily." > > I don't quite understand how LMP hello could prevent IGP hello lost. > My understading is: as far as there is at least > one contral channel active between the neighbor, IGP won't remove the > link-state adjacency, even without LMP detecting the control channel > failure. > Is that right? LMP can be used to maintain active control channels between neighbors. These control channels can be used to build a resilient adjacencies in routing/signaling. > > 3. In page 9, section 3.2.1: > "If the fast keep-alive mechanism of LMP is not used, the > HelloInterval and HelloDeadInterval parameters MUST be set to zero." > > This paragraph says that the Hello could be optional. However, in the > Control channel FSM, it seems that this case is not considered. The intent of the Control channel FSM was to show the state changes when LMP keep alive is used. I'm not sure how interesting/helpful it is to discuss the CC FSM when the keep alive is not used. > > > > Thanks, > Fugui > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Mar 2002 17:02:57 -0800 Message-ID: From: "Cheng, Dean" To: "'ccamp@ops.ietf.org'" Subject: FW: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-00. txt Date: Tue, 19 Mar 2002 16:28:09 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CFA6.1E3C5238" 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_000_01C1CFA6.1E3C5238 Content-Type: text/plain; charset="iso-8859-1" <<...>> This I-D was'nt presented in yesterday's meeting but will be appreciated if you can read and send comments to the mailing list. Some highlights: 1) An "address TLV" may be included in opaque LSA by ABRs and is capable of advertising multiple rechable addresses and subnets in a single opaque LSA. The LSA also includes the identity of the source area. 2) Allows TE links that represent the aggregated traffic trunks between pairs of ABRs in a given area being advertised. The information contained in the TE links also includes the identity of the source area. 3) The advertising scope of the above two may be specified according to the actual networking applications with the follwoing scenarios: 3a) AS-wide advertising using opaque type 11 LSA. 3b) per-area advertising (on-demand) using opaque type 10 LSA. 3c) per-node (head-end LSR, on-demand) using opaque type 9 LSA. 4) The information of 1) and 2) above tells the head-end LSR which area the tail-end LSR resides, and the LSR may build an optimized but loose-hop path from itself all the way to the entry ABR of the destination area. Note the hops that outside of the source area are concatenation of the ABRs in other areas. Thanks Dean -----Original Message----- From: Internet-Drafts@ietf.org Cc: ccamp@ops.ietf.org Sent: 3/4/2002 4:06 AM Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions to Support Multi-Area Traffic Engineering Author(s) : D. Cheng Filename : draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt Pages : 6 Date : 01-Mar-02 The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te- extensions-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-cheng-ccamp-ospf-multiarea-te-extensions-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-cheng-ccamp-ospf-multiarea-te-extensions-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_000_01C1CFA6.1E3C5238 Content-Type: message/rfc822 To: Subject: Date: Tue, 19 Mar 2002 16:28:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1CFA6.1E3C5238" ------_=_NextPart_002_01C1CFA6.1E3C5238 Content-Type: text/plain ------_=_NextPart_002_01C1CFA6.1E3C5238 Content-Type: application/octet-stream; name="ATT26770.txt" Content-Disposition: attachment; filename="ATT26770.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020301135034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt ------_=_NextPart_002_01C1CFA6.1E3C5238 Content-Type: message/external-body; site="internet-drafts"; dir="draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1CFA6.1E3C5238-- ------_=_NextPart_000_01C1CFA6.1E3C5238-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Mar 2002 08:43:00 -0800 Date: Tue, 19 Mar 2002 08:42:18 -0800 (PST) From: Kireeti Kompella Message-Id: <200203191642.IAA15968@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Document status Here is the document status as presented in CCAMP 53. Please read, especially if you are an author, and send corrections to Ron and me. Thanks, Kireeti. ------- Finished Last Call in MPLS and CCAMP WGs draft-ietf-mpls-generalized-cr-ldp-05.txt draft-ietf-mpls-generalized-rsvp-te-06.txt draft-ietf-mpls-generalized-signaling-07.txt have implementation status, so ready for IETF Last Call Call for consensus to send to IETF Last Call draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt -- informational draft-ietf-ccamp-gmpls-architecture-02.txt -- informational draft-ietf-ccamp-sdhsonet-control-00.txt -- informational One more WG Last Call for final changes, then IETF Last Call draft-ietf-ccamp-gmpls-sonet-sdh-03.txt -- proposed standard draft-ietf-ccamp-lmp-03.txt -- proposed standard WG Last Call draft-ietf-ccamp-gmpls-routing-02.txt -- proposed standard draft-ietf-ccamp-ospf-gmpls-extensions-04.txt -- proposed standard Call for consensus for WG Last Call draft-ietf-ccamp-lmp-mib-01.txt ? -- proposed standard draft-ietf-ccamp-lmp-wdm-00.txt -- proposed standard draft-ietf-ccamp-oli-reqts-00.txt -- informational Any objections to making this a WG document? draft-fontana-ccamp-gmpls-g709-03.txt -- proposed standard Call for consensus to make into WG documents draft-bellato-ccamp-g709-framework-01.txt -- informational draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt -- proposed standard draft-mannie-ccamp-gmpls-lbm-tdm-01.txt -- proposed standard draft-mannie-gmpls-recovery-terminology-00.txt -- informational draft-bonica-tuntrace-02.txt -- informational Update, followed by call for consensus to make WG docs draft-nadeau-ccamp-gmpls-label-mib-01.txt -- proposed standard draft-nadeau-ccamp-gmpls-lsr-mib-01.txt -- proposed standard draft-nadeau-ccamp-gmpls-tc-mib-01.txt -- proposed standard draft-nadeau-ccamp-gmpls-te-mib-01.txt -- proposed standard Call for Design Team for "GMPLS Profile for ASON/ASTN" -- understand more clearly what needs to be done here -- figure out if a design team is needed (or just a set of IDs) -- figure out where this work should be done (CCAMP vs. IPO vs. ...) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Mar 2002 08:10:08 -0800 From: Emmanuel.Desmet@alcatel.be Subject: Re: GMPLS Implementation Survey To: "'ccamp@ops.ietf.org'" , Mark_Seery Message-ID: Date: Tue, 19 Mar 2002 17:09:37 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii [ post by non-subscriber ] Did anyone catch the URL for the GMPLS implementation survey presented during CCAMP WG last night? Try http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt Thanks, -mark.s. @+ manu Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Mar 2002 08:04:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <612004A32839D21194C40060083E665403079BC9@MAILSERVER> From: Mark_Seery To: "'ccamp@ops.ietf.org'" Subject: GMPLS Implementation Survey Date: Tue, 19 Mar 2002 07:53:29 -0800 [ post by non-subscriber ] Did anyone catch the URL for the GMPLS implementation survey presented during CCAMP WG last night? Thanks, -mark.s. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 18:24:41 -0800 Message-ID: <3C96A0AC.97D33E13@lucent.com> Date: Mon, 18 Mar 2002 19:21:32 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp , Wesam Alanqar Subject: URLs & Contact Info from ITU-T Presentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, The Representative from ITU-T to ITU-T Study Group 15 is: Wesam Alanqar wesam.alanqar@mail.sprint.com The key URLs with the communications from ITU-T Study Group 15 to ccamp are: ITU-T FTP Site: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html IETF Liaison Page: http://www.ietf.org/IESG/liaison.html Several of the documents are in MS Word format, and therefore only appear on the ITU-T site. I have sent a copy of the slides to Kireeti to put on the web. Regards, Steve Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 13:14:30 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Lou Berger , ccamp@ops.ietf.org Subject: RE: new draft Generalized MPLS Signaling - Implementation Survey Date: Mon, 18 Mar 2002 22:13:32 +0100 MIME-Version: 1.0 Content-Type: text/plain Thanks Bert > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Monday, March 18, 2002 8:05 PM > To: ccamp@ops.ietf.org > Subject: Fwd: new draft Generalized MPLS Signaling - Implementation > Survey > > > FYI - the survey has been submitted... > > Thanks to all who participated! > > Lou > > >Date: Fri, 15 Mar 2002 17:18:00 -0500 > >To: internet-drafts@ietf.org > >From: Lou Berger > >Subject: new draft Generalized MPLS Signaling - Implementation Survey > >Cc: yakov@juniper.net, Kireeti Kompella > > > >Hi, > > We would like to submit a new draft, > >"Generalized MPLS Signaling - Implementation Survey". We suggest > >the name "draft-ietf-ccamp-gmpls-signaling-survey-00.txt". This > >has been approved by Kireeti, a CCAMP WG chair. The information > >on the draft is listed below, and the draft itself is available at: > >(assuming you approve of the name.) > >http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signa ling-survey-00.txt > >Thank you, >Lou and Yakov. > > >============================================ >Network Working Group Lou Berger (Movaz) - Editor >Internet Draft Yakov Rekhter (Juniper) - Editor >Expiration Date: September 2002 > > March 2002 > > > Generalized MPLS Signaling - Implementation Survey > > >Abstract > > This document provides a survey of GMPLS signaling implementations. > The primary focus of this survey are the signaling protocol > mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and > [GMPLS-SONET]. Other specifications and documents are listed if > included in the submitted form. The survey form and latest version > of this document are available from http://www.labn.net/gmpls-survey. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 12:57:09 -0800 Message-ID: From: Fugui Wang To: "'jplang@calient.net'" Cc: "'ccamp@ops.ietf.org'" Subject: Comments on LMP draft 3 Date: Mon, 18 Mar 2002 15:54:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Jonathan, Here are some comments regarding draft-ietf-ccamp-lmp-03.txt: 1. In page 5, section 3: "Rather, a node-wide unique 32-bit non-zero integer control channel identifier CCId) is assigned at each end of the control channel. This identifier comes from the same space as the unnumbered interface Id." If the control channel is directly on ethernet instead of point-to-point interface or IP tunnel, what should be chosen as the CCId? For example, in the following case, if Node A, B, C are connected by ethernet. Node B should have a control channel to A and C respectively. What should be the CCIds for these two control channels? In this case interface ID is not able to uniquely identify the control channel. .1 .2 .3 10.1.1.0/24 ----+--------------------+----------------------+-------------- | + | +---+---+ +---+----+ +----+----+ |ifId=2 | | ifId=3 | | ifId=4 | | A | | B | | C | | | | | | | +-------+ +--------+ +---------+ 2. In page 9, section 3.2: "The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link- state adjacencies are not removed unnecessarily." I don't quite understand how LMP hello could prevent IGP hello lost. My understading is: as far as there is at least one contral channel active between the neighbor, IGP won't remove the link-state adjacency, even without LMP detecting the control channel failure. Is that right? 3. In page 9, section 3.2.1: "If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero." This paragraph says that the Hello could be optional. However, in the Control channel FSM, it seems that this case is not considered. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 12:05:41 -0800 Date: Mon, 18 Mar 2002 12:04:42 -0800 (PST) From: Kireeti Kompella Message-Id: <200203182004.MAA12132@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Agenda update Agenda bashing and status update -- 15 min Blue sheets, minutes takers Steve Trowbridge -- 10 min ITU-T update Lou Berger -- 5 min GMPLS implementation survey P & R DT (Mannie) -- 15 min Members, charter, status draft-mannie-gmpls-recovery-terminology-00.txt Cheng-Yin Lee -- 5 min draft-lee-rsvp-te-xro-00.txt Kohei Shiomoto -- 5 min draft-shiomoto-ccamp-multiarea-te-00.txt Wataru Imajuku -- 5 min draft-imajuku-ml-routing-01.txt Ash, Gerald -- 5 (multiarea) Multiarea discussion -- 10 min Mannie, Eric -- 15 min draft-ietf-ccamp-gmpls-architecture-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-03.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt Dimitri.Papadimitriou@alcatel.be -- 15 min draft-ietf-ccamp-gmpls-g709-00.txt draft-mannie-ccamp-gmpls-lbm-tdm-01.txt draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Osama Aboul-Magd -- 5 min draft-aboulmagd-ccamp-call-conn-separation-00.txt. Jonathan Lang -- 5 min draft-ietf-ccamp-lmp-03.txt Ron Bonica -- 5 min draft-bonica-tunneltrace-02.txt Yoshihiko SUEMURA -- 5 min draft-suemura-gmpls-restoration-signaling-00.txt draft-suemura-protection-hierarchy-00.txt Dimitri -- 10 min draft-design-team-ccamp-recovery-analysis-00.txt Kohei Shiomoto -- time permitting discussion on draft-matsuura-gmpls-rsvp-requirements-00.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 11:07:05 -0800 Message-Id: <4.3.2.7.2.20020318140359.0291a6f8@mo-ex1> Date: Mon, 18 Mar 2002 14:05:09 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: new draft Generalized MPLS Signaling - Implementation Survey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed FYI - the survey has been submitted... Thanks to all who participated! Lou >Date: Fri, 15 Mar 2002 17:18:00 -0500 >To: internet-drafts@ietf.org >From: Lou Berger >Subject: new draft Generalized MPLS Signaling - Implementation Survey >Cc: yakov@juniper.net, Kireeti Kompella > >Hi, > We would like to submit a new draft, >"Generalized MPLS Signaling - Implementation Survey". We suggest >the name "draft-ietf-ccamp-gmpls-signaling-survey-00.txt". This >has been approved by Kireeti, a CCAMP WG chair. The information >on the draft is listed below, and the draft itself is available at: >(assuming you approve of the name.) >http://www.labn.net/gmpls-survey/draft-ietf-ccamp-gmpls-signaling-survey-00.txt > >Thank you, >Lou and Yakov. > > >============================================ >Network Working Group Lou Berger (Movaz) - Editor >Internet Draft Yakov Rekhter (Juniper) - Editor >Expiration Date: September 2002 > > March 2002 > > > Generalized MPLS Signaling - Implementation Survey > > >Abstract > > This document provides a survey of GMPLS signaling implementations. > The primary focus of this survey are the signaling protocol > mechanisms specified in [GMPLS-SIG], [GMPLS-RSVP], [GMPLS-LDP] and > [GMPLS-SONET]. Other specifications and documents are listed if > included in the submitted form. The survey form and latest version > of this document are available from http://www.labn.net/gmpls-survey. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Mar 2002 08:32:50 -0800 Message-ID: From: Jonathan Lang To: 'S Ramesh' , ccamp@ops.ietf.org Cc: Bala Rajagopalan Subject: RE: LMP Comments? Date: Mon, 18 Mar 2002 08:22:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh, Thanks for the catching the bad edits. Further clarifications inline. -Jonathan > -----Original Message----- > From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > Sent: Sunday, March 17, 2002 4:33 AM > To: ccamp@ops.ietf.org > Cc: Jonathan Lang; Bala Rajagopalan > Subject: LMP Comments? > > > Hi, > > 1. The ConfigNack Object has the Config object inclusion in the Nack > message as optional.[]. This will be mandatory right, since > there is no error code, when a Nack arrives, for a negotiable Config > or non-negotiable Config, the Config Object MUST be included and hence > mandatory. Correct. Config object is mandatory in ConfigNack object. > > 2. Some paragraphs of section 13.4.3 still speaks about the error > code. Hope missed out while editing. Correct. Text referring to Error Codes will be removed. > > 3. Already mentioned about similarities with OIF UNI 1.0. There it is > mentioned CCID == InterfaceID in in-fiber case. This draft also speaks > about in-fiber case in Section 3. According to this draft, CCID is a > 32 bit number and Interface ID can be 32 bit( IPv4 or unnumbered ) or > 128 bit > ( IPv6 ). OIF UNI is mentioning to refer IETF LMP for message > formats. So how can a 32 bit number be matched with a 128bit number? > Is this question is meaningful or am i missing something? Since OIF > UNI is mentioning IETF LMP for message formats am cross posting in > this list. Kindly clarify me in this regard. The CCID is defined as a 32-bit number. For in-fiber control channels where the interfaces are IPv4 addresses, these could be the same. > > Thanks, > Ramesh > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 17 Mar 2002 04:32:18 -0800 Message-ID: <3C948D0A.D68072E6@npd.hcltech.com> Date: Sun, 17 Mar 2002 18:03:14 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: "ccamp@ops.ietf.org" CC: Jonathan Lang , Bala Rajagopalan Subject: LMP Comments? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, 1. The ConfigNack Object has the Config object inclusion in the Nack message as optional.[]. This will be mandatory right, since there is no error code, when a Nack arrives, for a negotiable Config or non-negotiable Config, the Config Object MUST be included and hence mandatory. 2. Some paragraphs of section 13.4.3 still speaks about the error code. Hope missed out while editing. 3. Already mentioned about similarities with OIF UNI 1.0. There it is mentioned CCID == InterfaceID in in-fiber case. This draft also speaks about in-fiber case in Section 3. According to this draft, CCID is a 32 bit number and Interface ID can be 32 bit( IPv4 or unnumbered ) or 128 bit ( IPv6 ). OIF UNI is mentioning to refer IETF LMP for message formats. So how can a 32 bit number be matched with a 128bit number? Is this question is meaningful or am i missing something? Since OIF UNI is mentioning IETF LMP for message formats am cross posting in this list. Kindly clarify me in this regard. Thanks, Ramesh Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 16 Mar 2002 23:41:23 -0800 content-class: urn:content-classes:message Subject: RE: CCAMP 53 agenda Date: Sat, 16 Mar 2002 19:03:00 -0500 Message-ID: <28F05913385EAC43AF019413F674A017C8891C@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: CCAMP 53 agenda Thread-Index: AcHMlxRiDm58Y1uGRASwlgQsfcMY9gAr4W9Q From: "Ash, Gerald R (Jerry), ALASO" To: "Kireeti Kompella" , Cc: "Ash, Gerald R (Jerry), ALASO" >=20 > Ash, Gerald -- 5 (multiarea) >=20 The Internet Draft for this agenda item is draft-ash-multi-area-te-compare-00.txt http://search.ietf.org/internet-drafts/draft-ash-multi-area-te-compare-00= .txt Jerry Ash Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 19:01:23 -0800 Date: Fri, 15 Mar 2002 18:13:46 -0800 (PST) From: Kireeti Kompella Message-Id: <200203160213.SAA02384@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP 53 agenda Hi All, Here is the CCAMP agenda for next week. Speakers, please remember to keep to a very few slides (2-5), and discuss just the basic issues. Audience, please remember that the speakers are going to assume that you've read the drafts, and will not be giving a tutorial on the material. Thanks! Kireeti and Ron. --------------- Agenda bashing and status update -- 15 min Blue sheets, minutes takers Steve Trowbridge -- 10 min ITU-T update, communications P & R DT -- 10 min Members, charter, status Cheng-Yin Lee -- 5 min draft-lee-rsvp-te-xro-00.txt Kohei Shiomoto -- 5 min draft-shiomoto-ccamp-multiarea-te-00.txt Wataru Imajuku -- 5 min draft-imajuku-ml-routing-01.txt Ash, Gerald -- 5 (multiarea) Multiarea discussion -- 10 min Mannie, Eric -- 20 min draft-ietf-ccamp-gmpls-architecture-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-03.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt draft-mannie-ccamp-gmpls-lbm-tdm-01.txt Dimitri.Papadimitriou@alcatel.be -- 5 min draft-ietf-ccamp-gmpls-g709-00.txt Osama Aboul-Magd -- 5 min draft-aboulmagd-ccamp-call-conn-separation-00.txt. Jonathan Lang -- 5 min draft-ietf-ccamp-lmp-03.txt Andre/Jonathan -- 5 min draft-ietf-ccamp-lmp-wdm-00.txt Dimitri Papadimitriou -- 5 min draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Adrian Farrel -- 10 min draft-nadeau-ccamp-gmpls-tc-mib-01.txt draft-nadeau-ccamp-gmpls-label-mib-01.txt draft-nadeau-ccamp-gmpls-te-mib-01.txt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt Ron Bonica -- 5 min draft-bonica-tunneltrace-02.txt Yoshihiko SUEMURA -- 5 min draft-suemura-gmpls-restoration-signaling-00.txt draft-suemura-protection-hierarchy-00.txt Sudheer -- 10 min draft-design-team-ccamp-recovery-analysis-00.txt MATSUURA Nobuaki -- time permitting discussion on draft-matsuura-gmpls-rsvp-requirements-00.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 14:57:41 -0800 Message-ID: From: Jun Yu To: 'Kireeti Kompella' Cc: "'ccamp@ops.ietf.org'" Subject: RE: FW: path TLV & srlg TLV Date: Fri, 15 Mar 2002 17:56:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" No. I don't think so. But what I want to point out is, (1). There is inconsistency between "LSP Hierarchy with Generalized MPLS TE" and "Generalized Multi-Protocol Label Switching (GMPLS) Architecture" on this matter (whether to use path TLV or SRLG TLV in FA advertisement). (2). If we only advertise Path Information for the FA, then the SRLG information of the FA can be derived, just as you specified in the "LSP Hierarchy" draft, it is "the union of the SRLGs of the underlying TE links that make up the FA-LSP path". On the other hand, if we only advertise SRLG Information for the FA, then the FA-LSP's path information becomes opaque to all the LSRs other than the headend LSR. This makes it difficult for the LSR to make a routing decision with "Link", or "Node" diversity requirement. Thanks. -Jun > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, March 15, 2002 5:05 PM > To: Jun Yu > Cc: 'ccamp@ops.ietf.org' > Subject: Re: FW: path TLV & srlg TLV > > > > > On Fri, 15 Mar 2002, Jun Yu wrote: > > > > Section 4.1.10, the context is changed to "SRLG > Information" from the > > > previous "Path Information". > > Do you think it is useful to include both SRLG and Path information? > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 14:06:58 -0800 Date: Fri, 15 Mar 2002 14:04:58 -0800 (PST) From: Kireeti Kompella To: Jun Yu cc: "'ccamp@ops.ietf.org'" Subject: Re: FW: path TLV & srlg TLV Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Mar 2002, Jun Yu wrote: > > Section 4.1.10, the context is changed to "SRLG Information" from the > > previous "Path Information". Do you think it is useful to include both SRLG and Path information? Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 10:48:20 -0800 content-class: urn:content-classes:message Subject: RE: MPLS OAM & the IETF Date: Fri, 15 Mar 2002 13:46:43 -0500 Message-ID: <28F05913385EAC43AF019413F674A017018E428A@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: MPLS OAM & the IETF Thread-Index: AcHLdl1Hyva9ODnFQJmq5K1nExlJTQA2iHaA From: "Cuevas, Enrique G, ALASO" To: Cc: "Scott Bradner" I vote for option 1. The IETF should continue to work on IP-centric tools needed for basic IP = services. The ITU should work on the comprehensive set of OAM tools that are = needed to make MPLS a robust platform infrastructure capable of = supporting multi-services. After all, the ITU has developed Operations = and Maintenance standards for ATM, Frame Relay, SDH, ISDN, optical = fibers, etc. MPLS equipment vendors should become more involved in the = related ITU work. However, clear channels of cooperation between IETF/ITU are needed and = we are waiting for our AD to provide a more precise statement on how = this will be achieved. Enrique=20 AT&T Labs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 08:51:36 -0800 Message-Id: <4.3.2.7.2.20020315114159.02ab9918@mo-ex1> Date: Fri, 15 Mar 2002 11:49:32 -0500 To: yakov@juniper.net, Kireeti Kompella , ccamp@ops.ietf.org From: Lou Berger Subject: Proposed change to draft-ietf-ccamp-ospf-gmpls-extensions-04.txt Cc: "Dan Dovolsky" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Kireeti, Yakov, other authors... We propose the changes to the draft identified below with change bars. (To address advertisement of discrete allocation bandwidths.) What do you think? Thanks, Lou and Dan -------------------------------------------------------------------- 5.5. Interface Switching Capability Descriptor The Interface Switching Capability Descriptor is a sub-TLV of the Link TLV with type 15. The length is the length of value field in octets. The format of the value field is as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Switching Cap | Encoding | Reserved | Priority Mask | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Max LSP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Switching Capability (Switching Cap) field contains one of the following values: 1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) 51 Layer-2 Switch Capable (L2SC) 100 Time-Division-Multiplex Capable (TDM) 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC) The Encoding field contains one of the values specified in Section 3.1.1 of [GMPLS-SIG]. | Priority mask identifies the priorities levels at which Maximum LSP | Bandwidth is available. Bit 0 identifies priority 0, bit 7 | identifies priority 7. | | Maximum LSP Bandwidth is encoded as 4 octet field in | the IEEE floating point format. The units are bytes (not bits!) per | second. The content of the Switching Capability specific information field depends on the value of the Switching Capability field. When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the specific information includes Interface MTU, Minimum LSP Bandwidth, and padding. The Interface MTU is encoded as a 2 octets integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The padding is 2 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. When the Switching Capability field is L2SC, there is no specific information. When the Switching Capability field is TDM, the specific information includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The indication whether the interface supports Standard or Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the interface supports Standard SONET/SDH, and 1 if the interface supports Arbitrary SONET/SDH. The padding is 3 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. When the Switching Capability field is LSC, there is no specific information. The Interface Switching Capability Descriptor sub-TLV may occur more | than once within the Link TLV. This is used to handle interfaces | that support multiple switching capabilities, for interfaces | that have Max LSP Bandwidth values that differ by priority level, | and for interfaces that support discrete bandwidths. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 08:24:13 -0800 Message-ID: From: Jonathan Lang To: 'Su-Hun YUN' , ccamp@ops.ietf.org Subject: RE: LMP question Date: Fri, 15 Mar 2002 08:16:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Su-Hun, This was an editorial mistake and will be added to IPv4 and IPv6 C-types. Thanks, Jonathan > -----Original Message----- > From: Su-Hun YUN [mailto:s-yun@bl.jp.nec.com] > Sent: Thursday, March 14, 2002 10:10 PM > To: ccamp@ops.ietf.org > Subject: LMP question > > > [ post by non-subscriber ] > > Hi there, > > In the draft-ietf-ccamp-lmp-03.txt, direction bit to the > Channel_Status > object was added. > > However it added only to Unnumbered (C-type=3) but not to > IPv4 (C-type=1) > and IPv6 (C-type=2). Why so? > > And D (direction) bit was added only to the last Channel_Status field > and not to all Channel_Status field. Is there any reason for that? > (Then, the last Channel_Status field should be 30 bit anyway) > > Regards, > > > ------- > Su-Hun YUN > 1st Optical Network Division > NEC Corp. Japan > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 08:18:30 -0800 Message-ID: From: Jun Yu To: "'kireeti@juniper.net'" , "'ccamp@ops.ietf.org'" Subject: FW: path TLV & srlg TLV Date: Fri, 15 Mar 2002 11:16:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > I have a question regarding the latest version of "LSP Hierarchy with > Generalized MPLS TE". > > Section 4.1.10, the context is changed to "SRLG Information" from the > previous "Path Information". > > Is it the intention of the WG to advertise only SRLG info in the OSPF > LSA (for example) using SRLG sub-TLV, instead of the previous way of > advertising path information using Path sub-TLV? > > I have the confusion because the latest version of "Generalized > Multi-Protocol Label Switching (GMPLS) Architecture" (March 02) still > talks about path TLV in section 10.1 "Routing and Forwarding Adjacencies". > > Could somebody please clarify this? > > Also, if only the SRLG information is advertised, then does it implies > that GMPLS will only support SRLG diversity? Because without the path > information, Link diversity and Node diversity (as specified in OIF UNI > 1.0) will not be possible when doing source routing. > > Thanks. > -Jun Yu Firstwave Intelligent Optical Networks, (301) 345 2137 > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 05:45:34 -0800 content-class: urn:content-classes:message Subject: RE: Notify Message in GMPLS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Mar 2002 08:40:36 -0500 Message-ID: Thread-Topic: Notify Message in GMPLS Thread-Index: AcHLsL9U8T9e36oeT4uyojFdpay3+gAddkRA From: "George Young" To: "manoj juneja" , Hello manoj, See below: >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Thursday, March 14, 2002 3:38 PM >To: ccamp@ops.ietf.org >Subject: Notify Message in GMPLS > > >[ post by non-subscriber ] > >Hi All, > >Section 4.2.2 of the gmpls-rsvp-te daft mentions that >"the inclusion of a Notify Request object does not guarantee=20 >that a Notify=20 >message will be generated". > >This means that it is an optional procedure as per the drafts. > >Is there any real technical reason for introducing this=20 >message in GMPLS=20 >drafts ?=20 We're planning to use the NOTIFY message to indicate path failure to the head and the tail of an optical path, to intiate cutover to a backup path. Regards, George R. Young. Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com >What will be the criteria for a node to insert a=20 >notify request=20 >object in path/resv message ? > >Thanks in Advance, >Regards, >manoj. > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos:=20 >http://photos.msn.com/support/worldwide.aspx > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Mar 2002 02:25:34 -0800 Message-Id: <20020315145601.D42D.S-YUN@bl.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 15 Mar 2002 15:09:44 +0900 From: Su-Hun YUN To: ccamp@ops.ietf.org Subject: LMP question [ post by non-subscriber ] Hi there, In the draft-ietf-ccamp-lmp-03.txt, direction bit to the Channel_Status object was added. However it added only to Unnumbered (C-type=3) but not to IPv4 (C-type=1) and IPv6 (C-type=2). Why so? And D (direction) bit was added only to the last Channel_Status field and not to all Channel_Status field. Is there any reason for that? (Then, the last Channel_Status field should be 30 bit anyway) Regards, ------- Su-Hun YUN 1st Optical Network Division NEC Corp. Japan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Mar 2002 20:06:40 -0800 Message-Id: <4.3.2.7.2.20020314225740.01617810@funnel.cisco.com> Date: Thu, 14 Mar 2002 23:02:27 -0500 To: Jonathan Lang From: Baktha Muralidharan Subject: Comments on LMP Cc: ccamp@ops.ietf.org, muralidb@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5373146==_.ALT" --=====================_5373146==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Jonathan We have the following comments on LMP draft 3: -------------------------------------------------- 1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks about Message ID usage. It states, "Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached." What are the subsequent actions that need to take place when the above conditions occur ? 2. When Nacking a link summary, the current message format doesn't allow indicate what's wrong with each interface mapping.. "per-interface" error codes would be helpful. i.e. The TE link and each data link object in the Nack message needs an error code to localize the failure. 3. When a channel status msg is received with message ID less than an earlier (TE-Link) message, it might still be accepted per the draft. So, in the case where it is accepted, should the accepted message ID become the basis for all future message ID (validations)? 4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the current LMP draft does not support it. ------------------------------------------------------------ Thanks, /Baktha Muralidharan Cisco Systems, Inc. Chelmsford, MA. --=====================_5373146==_.ALT Content-Type: text/html; charset="us-ascii" Hi Jonathan

         We have the following comments on LMP draft 3:
--------------------------------------------------
1. In the current LMP draft (draft-ietf-ccamp-lmp-03.txt), section 7 talks
   about Message ID usage. It states,

            "Unacknowledged messages sent with the MESSAGE_ID object
             SHOULD be retransmitted until the message is acknowledged
             or until a retry limit is reached."

   What are the subsequent actions that need to take place when the
   above conditions occur ?

2. When Nacking a link summary, the current message format doesn’t allow indicate
   what's wrong with each interface mapping.. "per-interface" error codes would
   be helpful. i.e. The TE link and each data link object in the Nack message
   needs an error code to localize the failure.

3. When a channel status msg is received with message ID less than
an earlier (TE-Link) message, it might still be accepted per the
draft. So, in the case where it is accepted, should the accepted
   message ID become the basis for all future message ID (validations)?
 
4. CC ID can be numbered (i.e. IPv4 format) per OIF/OUNI. However, the current LMP
   draft does not support it.

------------------------------------------------------------
Thanks,

/Baktha Muralidharan
Cisco Systems, Inc.
Chelmsford, MA. --=====================_5373146==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Mar 2002 15:05:48 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Notify Message in GMPLS Date: Thu, 14 Mar 2002 13:38:08 -0700 [ post by non-subscriber ] Hi All, Section 4.2.2 of the gmpls-rsvp-te daft mentions that "the inclusion of a Notify Request object does not guarantee that a Notify message will be generated". This means that it is an optional procedure as per the drafts. Is there any real technical reason for introducing this message in GMPLS drafts ? What will be the criteria for a node to insert a notify request object in path/resv message ? Thanks in Advance, Regards, manoj. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Mar 2002 08:34:40 -0800 content-class: urn:content-classes:message Subject: RE: MPLS OAM & the IETF Date: Thu, 14 Mar 2002 11:32:43 -0500 Message-ID: <28F05913385EAC43AF019413F674A017C888F5@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: MPLS OAM & the IETF Thread-Index: AcHFJSjieGlXciSHTRuUdJML++/FAAEmkp4w From: "Ash, Gerald R (Jerry), ALASO" To: "Scott Bradner" , Cc: "Ash, Gerald R (Jerry), ALASO" Scott, I prefer 2a (although option 1 is a close second). Option 2a is what we were seeking in the BOF, and I agree with George = that one standards body should own a core technology. Presumable CCAMP = (?) will be chartered to do the work, while the ITU can define = extensions and bring them into the WG. OTOH, option 1 appears to be a formalized agreement to split the tasks. = My concern is whether the required coordination will be there between = ITU and IETF (as raised by Shahram, but not answered yet). Any resolution that gets the requirements met with interoperable vendor = implementations is acceptable IMO. Jerry Ash > 1 - split the tasks between the IETF and the ITU-T > 2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Mar 2002 04:56:14 -0800 Subject: Re: Please read and comment on GMPLS P&R DT documents To: ccamp@ops.ietf.org Cc: "Sudheer Dharanikota From: "Mario Molinari" Date: Thu, 14 Mar 2002 12:47:00 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi P&R Design Team, These are my comments on document draft-mannie-gmpls-recovery-terminology-00.txt. In paragraph 4.6 (Recovery types), sub-paragraphs D and E, you state that "all these (working and recovery) LSPs/spans must start and end at the same nodes". In an end-to-end restoration scheme, couldn't we have LSP's with different end nodes sharing the same restoration resources? For example, if restoration were pre-planned, the restoration path computation process might select a route sharing resources with the restoration route of other LSP's (possibly terminating on different nodes), as long as it could guarantee that there were no single risk affecting more than one of the LSP's using the same restoration resource. In paragraph 4.13 (External commands), I don't agree to some of the terms used. I would rename "Lockout of normal traffic" to "Forced switch to working" and "Forced switch for normal traffic" to "Forced switch to recovery". I'd redefine "Lockout of normal traffic" as in the following. "A configuration action initiated externally that results in the normal LSP/span being temporarily unavailable to transport traffic". I'd also rename "Manual switch for normal traffic" into "Manual switch to recovery", and add a "Manual switch to working", which would be defined as in the following. "A switch action initiated externally that switches normal traffic (back) to the working LSP/span, unless a fault condition exists on such LSPs/span or an equal or higher priority switch command is in effect." As a more general statement, it seems to me that this section borrows from G.841 terminology, but introduces some changes (like the ones for which I proposed an amendment). Which is the reason for such changes, apart of the use of "recovery" instead of "protection", which is obviously justified by the context? Mario Molinari Sudheer Dharanikota @ops.ietf.org on 13/03/2002 18.27.51 Sent by: owner-ccamp@ops.ietf.org To: CCAMP WG cc: Subject: Please read and comment on GMPLS P&R DT documents Hi Folks: Please note that the "GMPLS Protection and Restoration Design Team" has produced the following two documents (1st version)... Recovery (Protection and Restoration) Terminology for GMPLS http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminology-00.txt Analysis for GMPLS-based Recovery Mechanisms(including Protection and Restoration) http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt We request you to read and comment on them as quickly as you can. Regards, GMPLS P&R Design Team Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 15:33:03 -0800 From: "Richard Rabbat" To: "'Sudheer Dharanikota'" , Subject: RE: Please read and comment on GMPLS P&R DT documents Date: Wed, 13 Mar 2002 15:30:40 -0800 Message-ID: <001701c1cae7$16f33be0$623ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Design Team, The following is the list of comments that I have on document: draft-design-team-gmpls-recovery-analysis-00.txt Comments include both substance as well as minor text corrections. Page 2, line 53. - and (vertical hierarchy). Terminology used in this document is - conforms to the one defined in [CCAMP-TERM]. + and layering (vertical hierarchy). Terminology used in this document + conforms to the one defined in [CCAMP-TERM]. Page 2, line 41. -Signal Quality: monitors the performance of a signal. If the performance falls below a certain threshold a defect - excessive errors (EXC) or degraded signal (DEG) - is detected. This seems to imply that signal performance monitoring only applies to EXC and DEG. Changing the word to indicate that this is an example may be better. Actually, if this whole section is a re-write of SONET/SDH transport plane capability, maybe just referencing the appropriate document makes more sense to avoid duplication and possibly future changes in the future from having to be constantly updated in documents. Page 3, line 48. - comparing it with the expected identifier at the sink. Example, - the payload signal label (and the corresponding payload signal - mismatch detection). + comparing it with the expected identifier at the sink. An example + of payload types is the payload signal label (and the corresponding + payload signal mismatch detection). Page 3, line 54. - the next recovery phase) results in either: + the next recovery phase) result in either: Page 4, first paragraph. - Signal Fail (SF): A signal indicating the associated data has failed in the sense that a signal interrupting near-end defect condition (not being the degraded defect) is active. Do you mean? - Signal Fail (SF): A signal indicating that the associated data has failed. This is a signal indicating that a near-end defect condition is active (as opposed to a degraded defect). Page 4, line 16. ... In such cases, failure detection may be assisted by out-of-band communication, such as the one considered in [LMP-WDM] protocol which provides communication between the PXC and the OLS. I think this should be more forcefully described. What conditions allow for such assistance? How does the interaction between the 2 schemes work, and what takes precedence? Page 6, line 17. "Too much" and "too few". It will be hard to quantify what is meant by too much and too little information, since we do not currently discusss information overload. Maybe we should wait for some protocol on fault notification for protection to quantify the amount of information that will be passed. Page 6, line 39. - node) implies a consistent decisions based on the conditions for + node) implies that a consistent decision based on the conditions for Page 8, figure. Maybe cut the figures into 2 separate figures and explain the axis for the second figure. Page 8, line 41 - these operations are mostly planning time (using network planning + these operations are run mostly during planning time (using network planning Page 9, line 9 - There are many mechanisms available allowing overbook the recovery - There are many mechanisms available allowing the overbooking of the recovery Page 9, line 15 - best effort (recovered only if the resources are available). - unprotected (recovered only if the resources are available). It can be recovered if some restoration technique is applied. Page 9, line 47 Note: performance between the two approaches differs only by the time required for route computation and computation (and selection). What is meant by the second computation? --- I'll send an email later with the rest of the document, but I hope these comments are helpful. Richard -- Richard Rabbat, Ph.D. Fujitsu Laboratories of America, Inc. 595 Lawrence Expressway Sunnyvale, CA 94085 Phone: 1-408-530-4537. Fax: 1-408-530-4515 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 13:58:31 -0800 Message-ID: <3C8FCA5B.CC65740B@lucent.com> Date: Wed, 13 Mar 2002 14:53:31 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I didn't make this up - the argument was made in some earlier emails. One example (Eric Mannie, Feb 22): > If we change the SONET label format there are two issues: > > - already used by the OIF for UNI1.0. > - already implemented in many boxes. For the first of these issues, we have the problem that OIF declares as "final" an implementation agreement built around IDs that are not. The second is the "pre-standard" implementations I referred to in my earlier email. I did use the word "some" since I cannot claim that this is the reason for everyone who voted for (2), and I did not wish to attribute Eric's arguments onto everyone else who voted for the same alternative. Regards, Steve John Drake wrote: > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Wednesday, March 13, 2002 11:12 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF > > Snipped... > > We know that one reason that (some) voted against (1) was to protect > pre-standard implementations, which is not a valid basis for making > standards decisions. It would be good to know if there are other > reasons. > > JD: Oh really? I'm counting at least two assertions here. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 13:45:28 -0800 Message-ID: <2135200C183FD5119588009027DE5723FD2ED6@wntcsdexg02.csd.ciena.com> From: "Ong, Lyndon" To: "'Sudheer Dharanikota'" , CCAMP WG Subject: RE: Please read and comment on GMPLS P&R DT documents Date: Wed, 13 Mar 2002 13:43:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Sudheer & Team, Some comments on the Analysis document: One comment on the table on page 18: the evaluation of robustness seems to be somewhat in conflict with the text on robustness in Section 8.1, which notes that the less pre-planning that is done for recovery schemes the greater the robustness, due to the possibility of failures affecting both working and recovery paths (subject to having enough resources reserved for recovery). Also it looks like the numbering is reversed from the figure on page 8. Section 8.6.3 is a little confusing, it looks like some of the points are about SONET/SDH Protection Schemes in particular, not SONET/SDH transport in general. I'm not sure which the section was intended to discuss, characteristics of SONET/SDH protection or SONET/SDH technology. Generally like the classification of restoration schemes, it's basically the same as was defined in the GMPLS Architecture - perhaps there should be a reference to that document as well. Cheers, Lyndon Ong -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com] Sent: Wednesday, March 13, 2002 9:28 AM To: CCAMP WG Subject: Please read and comment on GMPLS P&R DT documents Hi Folks: Please note that the "GMPLS Protection and Restoration Design Team" has produced the following two documents (1st version)... Recovery (Protection and Restoration) Terminology for GMPLS http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminolo gy-00.txt Analysis for GMPLS-based Recovery Mechanisms(including Protection and Restoration) http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00. txt We request you to read and comment on them as quickly as you can. Regards, GMPLS P&R Design Team Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 13:38:42 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E274@nimbus> From: John Drake To: 'Stephen Trowbridge' , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Wed, 13 Mar 2002 13:34:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Wednesday, March 13, 2002 11:12 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Snipped... We know that one reason that (some) voted against (1) was to protect pre-standard implementations, which is not a valid basis for making standards decisions. It would be good to know if there are other reasons. JD: Oh really? I'm counting at least two assertions here. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 11:14:46 -0800 Message-ID: <3C8FA475.97DF6511@lucent.com> Date: Wed, 13 Mar 2002 12:11:49 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, > The issue is, there > are those who feel that there is a real reason not to do (1). So, I > would like to give this one more chance to get resolved. I guess by asking for simple votes instead of diatribes, we don't know all the reasons. Presumably everyone has a reason to have voted the way they did. We know that one reason that (some) voted against (1) was to protect pre-standard implementations, which is not a valid basis for making standards decisions. It would be good to know if there are other reasons. I look forward to getting this resolved in Minneapolis. Steve Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 11:02:44 -0800 Date: Wed, 13 Mar 2002 11:01:05 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Steve, On Tue, 12 Mar 2002, Stephen Trowbridge wrote: > Kireeti, > Wasn't there a default resolution indicated in your email of Feb 25? > Kireeti Kompella wrote: > (snip) > > If there isn't consensus in either direction, we'll go with one > > encoding -- that's the right thing to do in principle. > > > > Kireeti. > The way I read this, it says "If we can't agree to something > different, we will do (1)". Did I misunderstand the earlier email? You're right. Others pointed out this as well. The issue is, there are those who feel that there is a real reason not to do (1). So, I would like to give this one more chance to get resolved. Besides, if at all possible, I would prefer not to exercise a WG-chair fiat. If we can find no other resolution, it would be either the WG chairs/ADs getting together and deciding what to do, or dropping the document entirely. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Mar 2002 09:39:42 -0800 Message-ID: <3C8F8C17.EC823542@nayna.com> Date: Wed, 13 Mar 2002 09:27:51 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: CCAMP WG Subject: Please read and comment on GMPLS P&R DT documents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Folks: Please note that the "GMPLS Protection and Restoration Design Team" has produced the following two documents (1st version)... Recovery (Protection and Restoration) Terminology for GMPLS http://search.ietf.org/internet-drafts/draft-mannie-gmpls-recovery-terminology-00.txt Analysis for GMPLS-based Recovery Mechanisms(including Protection and Restoration) http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt We request you to read and comment on them as quickly as you can. Regards, GMPLS P&R Design Team Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 15:26:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Message-Id: Date: Tue, 12 Mar 2002 15:24:59 -0800 > and now you know why we don't do voting in the ietf. btw, this was not meant as a personal remark directed to anyone. i was merely trying to remind everyone of the wisdom of dave clark's statement. randy Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 14:45:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Message-Id: Date: Tue, 12 Mar 2002 14:43:54 -0800 and now you know why we don't do voting in the ietf. randy Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 14:41:35 -0800 Message-ID: <3C8E8382.5EB32092@lucent.com> Date: Tue, 12 Mar 2002 15:38:58 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, Wasn't there a default resolution indicated in your email of Feb 25? Kireeti Kompella wrote: (snip) > If there isn't consensus in either direction, we'll go with one > encoding -- that's the right thing to do in principle. > > Kireeti. The way I read this, it says "If we can't agree to something different, we will do (1)". Did I misunderstand the earlier email? Regards, Steve Kireeti Kompella wrote: > > Hi All, > > Here's what we got for each option: > > 1) Trowbridge, Brungard, Vainshtein, Eve Varma, Natale, Juergen, Ash, > Aboul-Magd, Mack-Crane, Sadler, Sankaranarayanan, Yangguang, > Zhi-Wei Lin, Silman Lionel, Vissers, Hai Vodinh, Monica Lazer, > Aguirre-Torre, Kalmanek, Yates, Molinari, Caviglia, Guangzhi Li, > Dongmei, John Strand. > -> 25 > > 2) Papadimitiriou, Mannie, Bala, Drake, Zhensheng, Kakutam, Saha, > Ayan Banerjee, Sudheer, Cheng, Dan Guo, TOMOHIRO OTANI, Grammel, > van_den_bosch, Rousseau, Dieter Beller, Gert Van Hoey, Yakov Rekhter, > Jonathan Lang, Lou Berger (4/2), Jim Jones, Luc Ceuppens, Hug Werner, > Emmanuel.Desmet. > -> 23.5 > > 3) John Fee, Curtis Brownmiller. > > 4) Greg, Sharma, Meehan, Lou Berger. > > There were some ambiguous "votes": Lou Berger was counted in 2, as > there wasn't much support for 4. Meehan seemed to say that 1 was > not acceptable in its current form, but he mentioned both 4 and 1. > > If we missed your "vote", or misinterpreted it, please let us know. > > Some of you have noticed that "voting" went on past the deadline. > I haven't broken out results by dates. The deadline was only to > give Eric time to produce a document that matched the consensus; > however, as there wasn't any clear consensus, Eric produced an > interim document just so that there is a basis for discussion. > > Others noticed that many folks from the same company voted the > same way. I didn't :-) The IETF does not recognize companies > when it comes to consensus decisions -- it's just individuals. > > THE OUTCOME IS: no consensus. Note that these are *not* votes. > In a face-to-face meeting, consensus would mean that the people in > favor of some option raised their hands, and it was obvious without > actually counting that those were by far the biggest group. > > So, on to Plan B. A closed group, including some of the authors, > the chairs and the ADs will meet at the IETF, and see if we can > craft a document that those present will sign off on. If so, that > version will be published, and there will be a 2 week Last Call > period after the IETF so that everyone in the CCAMP community can > comment on the result. Note that this Last Call will be limited > to the SONET/SDH issue: i.e., the changes between the current > version of the document and the new version that we (hopefully) > will have after the IETF. > > Ron and Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 14:19:38 -0800 Date: Tue, 12 Mar 2002 14:18:16 -0800 (PST) From: Kireeti Kompella Message-Id: <200203122218.OAA17888@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Hi All, Here's what we got for each option: 1) Trowbridge, Brungard, Vainshtein, Eve Varma, Natale, Juergen, Ash, Aboul-Magd, Mack-Crane, Sadler, Sankaranarayanan, Yangguang, Zhi-Wei Lin, Silman Lionel, Vissers, Hai Vodinh, Monica Lazer, Aguirre-Torre, Kalmanek, Yates, Molinari, Caviglia, Guangzhi Li, Dongmei, John Strand. -> 25 2) Papadimitiriou, Mannie, Bala, Drake, Zhensheng, Kakutam, Saha, Ayan Banerjee, Sudheer, Cheng, Dan Guo, TOMOHIRO OTANI, Grammel, van_den_bosch, Rousseau, Dieter Beller, Gert Van Hoey, Yakov Rekhter, Jonathan Lang, Lou Berger (4/2), Jim Jones, Luc Ceuppens, Hug Werner, Emmanuel.Desmet. -> 23.5 3) John Fee, Curtis Brownmiller. 4) Greg, Sharma, Meehan, Lou Berger. There were some ambiguous "votes": Lou Berger was counted in 2, as there wasn't much support for 4. Meehan seemed to say that 1 was not acceptable in its current form, but he mentioned both 4 and 1. If we missed your "vote", or misinterpreted it, please let us know. Some of you have noticed that "voting" went on past the deadline. I haven't broken out results by dates. The deadline was only to give Eric time to produce a document that matched the consensus; however, as there wasn't any clear consensus, Eric produced an interim document just so that there is a basis for discussion. Others noticed that many folks from the same company voted the same way. I didn't :-) The IETF does not recognize companies when it comes to consensus decisions -- it's just individuals. THE OUTCOME IS: no consensus. Note that these are *not* votes. In a face-to-face meeting, consensus would mean that the people in favor of some option raised their hands, and it was obvious without actually counting that those were by far the biggest group. So, on to Plan B. A closed group, including some of the authors, the chairs and the ADs will meet at the IETF, and see if we can craft a document that those present will sign off on. If so, that version will be published, and there will be a 2 week Last Call period after the IETF so that everyone in the CCAMP community can comment on the result. Note that this Last Call will be limited to the SONET/SDH issue: i.e., the changes between the current version of the document and the new version that we (hopefully) will have after the IETF. Ron and Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 10:33:12 -0800 Date: Tue, 12 Mar 2002 10:30:48 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Leen Mak suggests that I send mail to the list saying: "we have heard you and will come back with a conclusion." Thanks, everyone for indicating what you think should be done with the SONET/SDH label issue. We will let you know shortly what we come up with, and what the next steps are. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Mar 2002 06:26:32 -0800 Message-Id: <4.3.2.7.2.20020312091601.02024340@mo-ex1> Date: Tue, 12 Mar 2002 09:20:46 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: Reminder: Survey forms due tomorrow Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If you wish to be included in the first draft of the GMPLS signaling implementation survey, please have your forms sent in by tomorrow (March 13). Thanks, Lou Forms available from: http://www.labn.net/gmpls/sig-survey.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 16:53:56 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Lou Berger , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, Scott Bradner , IANA Subject: RE: GMPLS signaling (RSVP) assignment request. Date: Tue, 12 Mar 2002 01:53:01 +0100 MIME-Version: 1.0 Content-Type: text/plain > > PS What values would you suggest we use during the > interoperability testing > you have discussed? > So that sounds like a good reason to try and convince IANA to do the assignment earlier on. Of course you can "test" with some temp agreed values. I assume the testing is done in a controlled environment, right? Bert > At 06:50 PM 3/11/2002, Wijnen, Bert (Bert) wrote: > >Lou, nomrally the IANA assigns such number right at the > >time that the RFC gets published. The reason for that is > >that they do not want to end up with assignments for > >stuff that does not make it up to RFC. > > > >Bert > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@movaz.com] > > > Sent: Tuesday, March 12, 2002 12:44 AM > > > To: ccamp@ops.ietf.org > > > Subject: Fwd: GMPLS signaling (RSVP) assignment request. > > > > > > > > > FYI > > > > > > >Date: Mon, 11 Mar 2002 18:39:18 -0500 > > > >To: iana@iana.org > > > >From: Lou Berger > > > >Subject: GMPLS signaling (RSVP) assignment request. > > > > > > > >Hello! > > > > > > > >We'd like to request assignment of types defined in > > > >draft-ietf-mpls-generalized-rsvp-te-06. This draft has > > > >passed WG last call and is on it's way to IESG/IETF last call. > > > >Assignment is needed to ensure interoperability. > > > > > > > >Thank you, > > > >Lou Berger (and co-authors) > > > > > > > > > > > > >--------------------------------------------------------------------- > > > > > > > >RSVP related values defined in > draft-ietf-mpls-generalized-rsvp-te-06 > > > >with suggested values. > > > > > > > > >--------------------------------------------------------------------- > > > >Message Types > > > > > > > >o Notify message (suggested Message type =21) > > > > > > > > >--------------------------------------------------------------------- > > > >Class Types > > > > > > > >o RSVP_HOP (Existing C-Num 3) > > > > - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) > > > > - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) > > > > > > > >o ERROR_SPEC (Existing C-Num 6) > > > > - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) > > > > - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) > > > > > > > >o LABEL_REQUEST (Existing Class-Num 19) > > > > - Generalized_Label_Request (Suggested C-Type =4) > > > > > > > >o RSVP_LABEL (Existing Class-Num 16) > > > > - Generalized_Label (Suggested C-Type =2) > > > > - Waveband_Switching_Label C-Type (Suggested C-Type =3) > > > > > > > > >--------------------------------------------------------------------- > > > >New Class-Nums, C-Types inherited from Label object > (same as CNum16) > > > > > > > >o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) > > > >o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) > > > >o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) > > > > > > > > >--------------------------------------------------------------------- > > > >New Class-Nums > > > > > > > >o LABEL_SET Class-Num of form 0bbbbbbb > > > (suggested =36) > > > > - Type 1 (C-Type =1) > > > >o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb > > > (suggested =130) > > > > - Type 1 Acceptable_Label_Set (C-type from label_set cnum) > > > >o NOTIFY_REQUEST Class-Num of form 11bbbbbb > > > (suggested =195) > > > > - IPv4 Notify Request (C-Type =1) > > > > - IPv6 Notify Request (C-Type =2) > > > >o PROTECTION Class-Num of form 0bbbbbbb > > > (suggested =37) > > > > - Type 1 (C-Type =1) > > > >o ADMIN STATUS Class-Num of form 11bbbbbb > > > (suggested =196) > > > > - Type 1 (C-Type =1) > > > >o RESTART_CAP Class-Num of form 10bbbbbb > > > (suggested =131) > > > > - Type 1 (C-Type =1) > > > > > > > > >--------------------------------------------------------------------- > > > >ERO/RRO subobject types > > > > > > > >o Label ERO subobject > > > > Type 3 - Label > > > > > > > >o Label RRO subobject > > > > Type 3 - Label > > > > > > > > >--------------------------------------------------------------------- > > > >Error codes > > > > > > > >o "Routing problem/Label Set" > > > (Suggested value =11) > > > >o "Routing problem/Switching Type" > > > (Suggested value =12) > > > >o "Routing problem/Unacceptable label value" > > > (Suggested value =13) > > > >o "Routing problem/Unsupported Encoding" > > > (Suggested value =14) > > > >o "Routing problem/Unsupported Link Protection" > > > (Suggested value =15) > > > >o "Notify Error/Control Channel Active State" > > > (Suggested value =4) > > > >o "Notify Error/Control Channel Degraded State" > > > (Suggested value =5) > > > > >--------------------------------------------------------------------- > > > > > > > >[related section from draft] > > > >13. IANA Considerations > > > > > > > > IANA assigns values to RSVP protocol parameters. Within > > > the current > > > > document multiple objects are defined. Each of these > > > objects contain > > > > C-Types. This section defines the rules for the > > > assignment of the > > > > related C-Type values. This section uses the > > > terminology of BCP 26 > > > > "Guidelines for Writing an IANA Considerations > Section in RFCs" > > > > [BCP26]. > > > > > > > > As per [RFC2205], C-Type is an 8-bit number that > identifies the > > > > function of an object. There are no range restrictions. All > > > > possible values except zero are available for assignment. > > > > > > > > The assignment of C-Type values of the objects > defined in this > > > > document fall into three categories. The first category > > > inherit C- > > > > Types from the Label object, i.e., object class number > > > 16 [RSVP-TE]. > > > > IANA is requested to institute a policy whereby all > C-Type values > > > > assign for the Label object are also assigned for > the following > > > > objects: > > > > o Suggested_Label (Class-Num TBA) > > > > o Upstream_Label (Class-Num TBA) > > > > o Recovery_Label (Class-Num TBA) > > > > > > > > The second category of objects follow independent policies. > > > > Specifically, following the policies outlined in > [BCP26], C-Type > > > > values in the range 0x00 - 0x3F are allocated through an IETF > > > > Consensus action, values in the range 00x40 - 0x5F are > > > allocated as > > > > First Come First Served, and values in the range > 0x60 - 0x7F are > > > > reserved for Private Use. This policy applies to > the following > > > > objects. > > > > o Label_Set (Class-Num TBA) > > > > o Notify_Request (Class-Num TBA) > > > > o Protection (Class-Num TBA) > > > > o Admin Status (Class-Num TBA) > > > > o Restart_Cap (Class-Num TBA) > > > > > > > > > > > > > > > >Berger, et. al. > > > [Page 35] > > > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt > > > November 2001 > > > > > > > > > > > > The assignment of C-Type values for the remaining object, the > > > > Acceptable_Label_Set object, follows the assignment of > > > C-Type values > > > > of the Label_Set object. IANA is requested to > institute a policy > > > > whereby all C-Type values assigned for the Label_Set > > > object are also > > > > assigned for the Acceptable_Label_Set object. > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 16:38:42 -0800 Message-Id: <4.3.2.7.2.20020311191948.05ea0f08@mo-ex1> Date: Mon, 11 Mar 2002 19:37:23 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: GMPLS signaling (RSVP) assignment request. Cc: Lou Berger , ccamp@ops.ietf.org, Scott Bradner , IANA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Bert, I've seen & had many conversations on this topic. I do understand that IANA wants to avoid making assignments too early and ending up with dead/wrong assignments. But the community needs to balance this with the need to support interoperability. My experience over the years has been that the authors request values and some time later IANA assigns values. In the mean time, early adopters agree on values, interoperate and deploy using these values. This is what happens so that we establish a "running code" endorsement and the industry can make progress. As far as I can tell, there is no documented process being followed by IANA or authors, it's just the way it works. (I went looking for a documented policy, and all I could find was a statement to send a request to IANA!) I personally believe this "unofficial" IANA assignment process hurts the community, but I'm resigned to following it. - I think it took ~18 months from the time I made the request until the RSVP-TE assignments were issued... Lou PS What values would you suggest we use during the interoperability testing you have discussed? At 06:50 PM 3/11/2002, Wijnen, Bert (Bert) wrote: >Lou, nomrally the IANA assigns such number right at the >time that the RFC gets published. The reason for that is >that they do not want to end up with assignments for >stuff that does not make it up to RFC. > >Bert > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@movaz.com] > > Sent: Tuesday, March 12, 2002 12:44 AM > > To: ccamp@ops.ietf.org > > Subject: Fwd: GMPLS signaling (RSVP) assignment request. > > > > > > FYI > > > > >Date: Mon, 11 Mar 2002 18:39:18 -0500 > > >To: iana@iana.org > > >From: Lou Berger > > >Subject: GMPLS signaling (RSVP) assignment request. > > > > > >Hello! > > > > > >We'd like to request assignment of types defined in > > >draft-ietf-mpls-generalized-rsvp-te-06. This draft has > > >passed WG last call and is on it's way to IESG/IETF last call. > > >Assignment is needed to ensure interoperability. > > > > > >Thank you, > > >Lou Berger (and co-authors) > > > > > > > > >--------------------------------------------------------------------- > > > > > >RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06 > > >with suggested values. > > > > > >--------------------------------------------------------------------- > > >Message Types > > > > > >o Notify message (suggested Message type =21) > > > > > >--------------------------------------------------------------------- > > >Class Types > > > > > >o RSVP_HOP (Existing C-Num 3) > > > - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) > > > - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) > > > > > >o ERROR_SPEC (Existing C-Num 6) > > > - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) > > > - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) > > > > > >o LABEL_REQUEST (Existing Class-Num 19) > > > - Generalized_Label_Request (Suggested C-Type =4) > > > > > >o RSVP_LABEL (Existing Class-Num 16) > > > - Generalized_Label (Suggested C-Type =2) > > > - Waveband_Switching_Label C-Type (Suggested C-Type =3) > > > > > >--------------------------------------------------------------------- > > >New Class-Nums, C-Types inherited from Label object (same as CNum16) > > > > > >o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) > > >o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) > > >o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) > > > > > >--------------------------------------------------------------------- > > >New Class-Nums > > > > > >o LABEL_SET Class-Num of form 0bbbbbbb > > (suggested =36) > > > - Type 1 (C-Type =1) > > >o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb > > (suggested =130) > > > - Type 1 Acceptable_Label_Set (C-type from label_set cnum) > > >o NOTIFY_REQUEST Class-Num of form 11bbbbbb > > (suggested =195) > > > - IPv4 Notify Request (C-Type =1) > > > - IPv6 Notify Request (C-Type =2) > > >o PROTECTION Class-Num of form 0bbbbbbb > > (suggested =37) > > > - Type 1 (C-Type =1) > > >o ADMIN STATUS Class-Num of form 11bbbbbb > > (suggested =196) > > > - Type 1 (C-Type =1) > > >o RESTART_CAP Class-Num of form 10bbbbbb > > (suggested =131) > > > - Type 1 (C-Type =1) > > > > > >--------------------------------------------------------------------- > > >ERO/RRO subobject types > > > > > >o Label ERO subobject > > > Type 3 - Label > > > > > >o Label RRO subobject > > > Type 3 - Label > > > > > >--------------------------------------------------------------------- > > >Error codes > > > > > >o "Routing problem/Label Set" > > (Suggested value =11) > > >o "Routing problem/Switching Type" > > (Suggested value =12) > > >o "Routing problem/Unacceptable label value" > > (Suggested value =13) > > >o "Routing problem/Unsupported Encoding" > > (Suggested value =14) > > >o "Routing problem/Unsupported Link Protection" > > (Suggested value =15) > > >o "Notify Error/Control Channel Active State" > > (Suggested value =4) > > >o "Notify Error/Control Channel Degraded State" > > (Suggested value =5) > > >--------------------------------------------------------------------- > > > > > >[related section from draft] > > >13. IANA Considerations > > > > > > IANA assigns values to RSVP protocol parameters. Within > > the current > > > document multiple objects are defined. Each of these > > objects contain > > > C-Types. This section defines the rules for the > > assignment of the > > > related C-Type values. This section uses the > > terminology of BCP 26 > > > "Guidelines for Writing an IANA Considerations Section in RFCs" > > > [BCP26]. > > > > > > As per [RFC2205], C-Type is an 8-bit number that identifies the > > > function of an object. There are no range restrictions. All > > > possible values except zero are available for assignment. > > > > > > The assignment of C-Type values of the objects defined in this > > > document fall into three categories. The first category > > inherit C- > > > Types from the Label object, i.e., object class number > > 16 [RSVP-TE]. > > > IANA is requested to institute a policy whereby all C-Type values > > > assign for the Label object are also assigned for the following > > > objects: > > > o Suggested_Label (Class-Num TBA) > > > o Upstream_Label (Class-Num TBA) > > > o Recovery_Label (Class-Num TBA) > > > > > > The second category of objects follow independent policies. > > > Specifically, following the policies outlined in [BCP26], C-Type > > > values in the range 0x00 - 0x3F are allocated through an IETF > > > Consensus action, values in the range 00x40 - 0x5F are > > allocated as > > > First Come First Served, and values in the range 0x60 - 0x7F are > > > reserved for Private Use. This policy applies to the following > > > objects. > > > o Label_Set (Class-Num TBA) > > > o Notify_Request (Class-Num TBA) > > > o Protection (Class-Num TBA) > > > o Admin Status (Class-Num TBA) > > > o Restart_Cap (Class-Num TBA) > > > > > > > > > > > >Berger, et. al. > > [Page 35] > > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt > > November 2001 > > > > > > > > > The assignment of C-Type values for the remaining object, the > > > Acceptable_Label_Set object, follows the assignment of > > C-Type values > > > of the Label_Set object. IANA is requested to institute a policy > > > whereby all C-Type values assigned for the Label_Set > > object are also > > > assigned for the Acceptable_Label_Set object. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 15:50:51 -0800 Message-ID: From: "Wijnen, Bert (Bert)" To: Lou Berger , ccamp@ops.ietf.org Cc: Scott Bradner , IANA Subject: RE: GMPLS signaling (RSVP) assignment request. Date: Tue, 12 Mar 2002 00:50:29 +0100 MIME-Version: 1.0 Content-Type: text/plain Lou, nomrally the IANA assigns such number right at the time that the RFC gets published. The reason for that is that they do not want to end up with assignments for stuff that does not make it up to RFC. Bert > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Tuesday, March 12, 2002 12:44 AM > To: ccamp@ops.ietf.org > Subject: Fwd: GMPLS signaling (RSVP) assignment request. > > > FYI > > >Date: Mon, 11 Mar 2002 18:39:18 -0500 > >To: iana@iana.org > >From: Lou Berger > >Subject: GMPLS signaling (RSVP) assignment request. > > > >Hello! > > > >We'd like to request assignment of types defined in > >draft-ietf-mpls-generalized-rsvp-te-06. This draft has > >passed WG last call and is on it's way to IESG/IETF last call. > >Assignment is needed to ensure interoperability. > > > >Thank you, > >Lou Berger (and co-authors) > > > > > >--------------------------------------------------------------------- > > > >RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06 > >with suggested values. > > > >--------------------------------------------------------------------- > >Message Types > > > >o Notify message (suggested Message type =21) > > > >--------------------------------------------------------------------- > >Class Types > > > >o RSVP_HOP (Existing C-Num 3) > > - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) > > - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) > > > >o ERROR_SPEC (Existing C-Num 6) > > - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) > > - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) > > > >o LABEL_REQUEST (Existing Class-Num 19) > > - Generalized_Label_Request (Suggested C-Type =4) > > > >o RSVP_LABEL (Existing Class-Num 16) > > - Generalized_Label (Suggested C-Type =2) > > - Waveband_Switching_Label C-Type (Suggested C-Type =3) > > > >--------------------------------------------------------------------- > >New Class-Nums, C-Types inherited from Label object (same as CNum16) > > > >o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) > >o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) > >o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) > > > >--------------------------------------------------------------------- > >New Class-Nums > > > >o LABEL_SET Class-Num of form 0bbbbbbb > (suggested =36) > > - Type 1 (C-Type =1) > >o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb > (suggested =130) > > - Type 1 Acceptable_Label_Set (C-type from label_set cnum) > >o NOTIFY_REQUEST Class-Num of form 11bbbbbb > (suggested =195) > > - IPv4 Notify Request (C-Type =1) > > - IPv6 Notify Request (C-Type =2) > >o PROTECTION Class-Num of form 0bbbbbbb > (suggested =37) > > - Type 1 (C-Type =1) > >o ADMIN STATUS Class-Num of form 11bbbbbb > (suggested =196) > > - Type 1 (C-Type =1) > >o RESTART_CAP Class-Num of form 10bbbbbb > (suggested =131) > > - Type 1 (C-Type =1) > > > >--------------------------------------------------------------------- > >ERO/RRO subobject types > > > >o Label ERO subobject > > Type 3 - Label > > > >o Label RRO subobject > > Type 3 - Label > > > >--------------------------------------------------------------------- > >Error codes > > > >o "Routing problem/Label Set" > (Suggested value =11) > >o "Routing problem/Switching Type" > (Suggested value =12) > >o "Routing problem/Unacceptable label value" > (Suggested value =13) > >o "Routing problem/Unsupported Encoding" > (Suggested value =14) > >o "Routing problem/Unsupported Link Protection" > (Suggested value =15) > >o "Notify Error/Control Channel Active State" > (Suggested value =4) > >o "Notify Error/Control Channel Degraded State" > (Suggested value =5) > >--------------------------------------------------------------------- > > > >[related section from draft] > >13. IANA Considerations > > > > IANA assigns values to RSVP protocol parameters. Within > the current > > document multiple objects are defined. Each of these > objects contain > > C-Types. This section defines the rules for the > assignment of the > > related C-Type values. This section uses the > terminology of BCP 26 > > "Guidelines for Writing an IANA Considerations Section in RFCs" > > [BCP26]. > > > > As per [RFC2205], C-Type is an 8-bit number that identifies the > > function of an object. There are no range restrictions. All > > possible values except zero are available for assignment. > > > > The assignment of C-Type values of the objects defined in this > > document fall into three categories. The first category > inherit C- > > Types from the Label object, i.e., object class number > 16 [RSVP-TE]. > > IANA is requested to institute a policy whereby all C-Type values > > assign for the Label object are also assigned for the following > > objects: > > o Suggested_Label (Class-Num TBA) > > o Upstream_Label (Class-Num TBA) > > o Recovery_Label (Class-Num TBA) > > > > The second category of objects follow independent policies. > > Specifically, following the policies outlined in [BCP26], C-Type > > values in the range 0x00 - 0x3F are allocated through an IETF > > Consensus action, values in the range 00x40 - 0x5F are > allocated as > > First Come First Served, and values in the range 0x60 - 0x7F are > > reserved for Private Use. This policy applies to the following > > objects. > > o Label_Set (Class-Num TBA) > > o Notify_Request (Class-Num TBA) > > o Protection (Class-Num TBA) > > o Admin Status (Class-Num TBA) > > o Restart_Cap (Class-Num TBA) > > > > > > > >Berger, et. al. > [Page 35] > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt > November 2001 > > > > > > The assignment of C-Type values for the remaining object, the > > Acceptable_Label_Set object, follows the assignment of > C-Type values > > of the Label_Set object. IANA is requested to institute a policy > > whereby all C-Type values assigned for the Label_Set > object are also > > assigned for the Acceptable_Label_Set object. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 15:48:14 -0800 Message-ID: From: neil.2.harrison@bt.com To: sob@harvard.edu Cc: mazad@nortelnetworks.com, ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Mon, 11 Mar 2002 23:47:37 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C957.1F851E40" 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_01C1C957.1F851E40 Content-Type: text/plain; charset="ISO-8859-1" Scott, I agree with the proposal below. Noting that 1 (below) is already completed.....but it goes further than Mina indicated (for brevity I guess) since it also defines all the defects in terms of entry/exit criteria and consequent actions. BTW - I saw some mails (eg from George) saying they thought the principles/requirements in Y.1710 were good. And if these can be satisfied by some other way (than Y.1711) then I guess that's fine....though clearly not applications will demand this level of treatment (which is actually not that complex anyway, despite what some say), even if an alternative approach is produced. If this new option 3 is not acceptable, then my vote is for the existing option 1. regards, Neil -----Original Message----- From: Mina Azad [mailto:mazad@nortelnetworks.com] Sent: 07 March 2002 17:23 To: 'Scott Bradner'; ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF As it's been pointed out on the mailing list in a various ways, option 1 is pragmatic but needs clarification. I'd like to suggest a third option which is effectively refinement to "1". Option 3: Principles of this option: Split the OAM (M stands for management and measurement) work between ITU and ITEF with commitment on both bodies to work towards complementing solutions, taking into consideration the core competency of the two standard bodies and the business drivers behind the technologies (from vendor, operator, and standards perspectives). In specific, option 3 proposes splitting the OAM in three areas 1) Definition and mechanism for availability and measurement to be handled by ITU 2) ad-hoc diagnostic tools for ip-centric networks to be handled by IETF 3) ad-hoc diagnostic and measurement tools primarily for non-ip-centric networks to be handled by ITU Regards, Mina Azad ------_=_NextPart_001_01C1C957.1F851E40 Content-Type: text/html; charset="ISO-8859-1" RE: MPLS OAM & the IETF
Scott, I agree with the proposal below.  Noting that 1 (below) is already completed.....but it goes further than Mina indicated (for brevity I guess) since it also defines all the defects in terms of entry/exit criteria and consequent actions.
BTW - I saw some mails (eg from George) saying they thought the principles/requirements in Y.1710 were good.  And if these can be satisfied by some other way (than Y.1711) then I guess that's fine....though clearly not applications will demand this level of treatment (which is actually not that complex anyway, despite what some say), even if an alternative approach is produced.
 
If this new option 3 is not acceptable, then my vote is for the existing option 1.
 
regards, Neil
-----Original Message-----
From: Mina Azad [mailto:mazad@nortelnetworks.com]
Sent: 07 March 2002 17:23
To: 'Scott Bradner'; ccamp@ops.ietf.org
Subject: RE: MPLS OAM & the IETF

As it's been pointed out on the mailing list in a various ways, option 1 is pragmatic but needs clarification.
I'd like to suggest a third option which is effectively  refinement to "1".
 
Option 3:
Principles of this option: Split the OAM (M stands for management and measurement) work between ITU and ITEF with commitment on both bodies to work towards complementing solutions, taking into consideration the core competency of the two standard bodies and the business drivers behind the technologies (from vendor, operator, and standards perspectives).

In specific, option 3 proposes splitting the OAM in three areas

      1) Definition and mechanism for availability and measurement to be handled by ITU  
      2) ad-hoc diagnostic tools for ip-centric networks to be handled by IETF
      3) ad-hoc diagnostic and measurement tools primarily for non-ip-centric networks to be handled by ITU         

Regards,

Mina  Azad

------_=_NextPart_001_01C1C957.1F851E40-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 15:45:43 -0800 Message-Id: <4.3.2.7.2.20020311184221.05e96de0@mail.labn.net> Date: Mon, 11 Mar 2002 18:43:44 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: Fwd: GMPLS signaling (RSVP) assignment request. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed FYI >Date: Mon, 11 Mar 2002 18:39:18 -0500 >To: iana@iana.org >From: Lou Berger >Subject: GMPLS signaling (RSVP) assignment request. > >Hello! > >We'd like to request assignment of types defined in >draft-ietf-mpls-generalized-rsvp-te-06. This draft has >passed WG last call and is on it's way to IESG/IETF last call. >Assignment is needed to ensure interoperability. > >Thank you, >Lou Berger (and co-authors) > > >--------------------------------------------------------------------- > >RSVP related values defined in draft-ietf-mpls-generalized-rsvp-te-06 >with suggested values. > >--------------------------------------------------------------------- >Message Types > >o Notify message (suggested Message type =21) > >--------------------------------------------------------------------- >Class Types > >o RSVP_HOP (Existing C-Num 3) > - IPv4 IF_ID RSVP_HOP (Suggested C-type =3) > - IPv6 IF_ID RSVP_HOP (Suggested C-type =4) > >o ERROR_SPEC (Existing C-Num 6) > - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3) > - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4) > >o LABEL_REQUEST (Existing Class-Num 19) > - Generalized_Label_Request (Suggested C-Type =4) > >o RSVP_LABEL (Existing Class-Num 16) > - Generalized_Label (Suggested C-Type =2) > - Waveband_Switching_Label C-Type (Suggested C-Type =3) > >--------------------------------------------------------------------- >New Class-Nums, C-Types inherited from Label object (same as CNum16) > >o RECOVERY_LABEL Class-Num of form 0bbbbbbb (suggested =34) >o SUGGESTED_LABEL Class-Num of form 10bbbbbb (suggested =129) >o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (suggested =35) > >--------------------------------------------------------------------- >New Class-Nums > >o LABEL_SET Class-Num of form 0bbbbbbb (suggested =36) > - Type 1 (C-Type =1) >o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (suggested =130) > - Type 1 Acceptable_Label_Set (C-type from label_set cnum) >o NOTIFY_REQUEST Class-Num of form 11bbbbbb (suggested =195) > - IPv4 Notify Request (C-Type =1) > - IPv6 Notify Request (C-Type =2) >o PROTECTION Class-Num of form 0bbbbbbb (suggested =37) > - Type 1 (C-Type =1) >o ADMIN STATUS Class-Num of form 11bbbbbb (suggested =196) > - Type 1 (C-Type =1) >o RESTART_CAP Class-Num of form 10bbbbbb (suggested =131) > - Type 1 (C-Type =1) > >--------------------------------------------------------------------- >ERO/RRO subobject types > >o Label ERO subobject > Type 3 - Label > >o Label RRO subobject > Type 3 - Label > >--------------------------------------------------------------------- >Error codes > >o "Routing problem/Label Set" (Suggested value =11) >o "Routing problem/Switching Type" (Suggested value =12) >o "Routing problem/Unacceptable label value" (Suggested value =13) >o "Routing problem/Unsupported Encoding" (Suggested value =14) >o "Routing problem/Unsupported Link Protection" (Suggested value =15) >o "Notify Error/Control Channel Active State" (Suggested value =4) >o "Notify Error/Control Channel Degraded State" (Suggested value =5) >--------------------------------------------------------------------- > >[related section from draft] >13. IANA Considerations > > IANA assigns values to RSVP protocol parameters. Within the current > document multiple objects are defined. Each of these objects contain > C-Types. This section defines the rules for the assignment of the > related C-Type values. This section uses the terminology of BCP 26 > "Guidelines for Writing an IANA Considerations Section in RFCs" > [BCP26]. > > As per [RFC2205], C-Type is an 8-bit number that identifies the > function of an object. There are no range restrictions. All > possible values except zero are available for assignment. > > The assignment of C-Type values of the objects defined in this > document fall into three categories. The first category inherit C- > Types from the Label object, i.e., object class number 16 [RSVP-TE]. > IANA is requested to institute a policy whereby all C-Type values > assign for the Label object are also assigned for the following > objects: > o Suggested_Label (Class-Num TBA) > o Upstream_Label (Class-Num TBA) > o Recovery_Label (Class-Num TBA) > > The second category of objects follow independent policies. > Specifically, following the policies outlined in [BCP26], C-Type > values in the range 0x00 - 0x3F are allocated through an IETF > Consensus action, values in the range 00x40 - 0x5F are allocated as > First Come First Served, and values in the range 0x60 - 0x7F are > reserved for Private Use. This policy applies to the following > objects. > o Label_Set (Class-Num TBA) > o Notify_Request (Class-Num TBA) > o Protection (Class-Num TBA) > o Admin Status (Class-Num TBA) > o Restart_Cap (Class-Num TBA) > > > >Berger, et. al. [Page 35] >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt November 2001 > > > The assignment of C-Type values for the remaining object, the > Acceptable_Label_Set object, follows the assignment of C-Type values > of the Label_Set object. IANA is requested to institute a policy > whereby all C-Type values assigned for the Label_Set object are also > assigned for the Acceptable_Label_Set object. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 12:06:31 -0800 From: "Vip Sharma" To: Cc: "'Scott Bradner'" Subject: RE: MPLS OAM & the IETF Date: Mon, 11 Mar 2002 14:59:17 -0500 Message-ID: <008101c1c937$39bee2c0$7400a8c0@zagrosnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I vote for 2. If we add the buerocracy of working with ITU we will add significant delays. IETF should come out with solutions and then market forces will cause them to be adopted or not. Anyway, ITU folks should also participated (if they want) and make this a complete solution... vip -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas D. Nadeau Sent: Sunday, March 10, 2002 12:28 PM To: ccamp@ops.ietf.org Cc: Scott Bradner Subject: Re: MPLS OAM & the IETF I vote for 2. Although I think there is room for input in the form of requirements/requests and such from the ITU, I think that having to interface with the ITU for this work is going to lead to interop problems as well as delay the work. The IETF created the standards for MPLS and continues to evolve the technology, so it makes sense to me that we continue to create and evolve the standards for managing MPLS. --Tom >Scott Bradner wrote: > > > > > 0/ you think I do not understand the issue > > > > 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and > > cede to the ITU-T work on the more telco-like OAM. In this option the IETF > > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an > > MPLS reserved label value for use by the ITU-T to identify Y.1711 > > information. > > > > 2/ The IETF work on a suite of technologies ranging from the > > ping/traceroute-like mechanisms to the more telephone system OAM ones. The > > IETF could try to figure out how to do this in conjunction with the ITU, > > though it is a bit late for that considering the state of Y.1711, or be in > > competition with the ITU-T. > > > > So - please indicate your opinion on how the IETF should proceed > > > > 1 - split the tasks between the IETF and the ITU-T > > 2 - IETF produce standards track documents covering both areas > > 2a - trying to work with the ITU-T to produce common technology > > 2b - in competition with the ITU-T > > > > In any case, it would be good to provide feedback to the ITU-T on Y.1711 if > > you see anything that looks broken. > > > > Scott (with sub-ip AD hat on) ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 08:30:41 -0800 Message-ID: <3C8CDBC8.7020905@juniper.net> Date: Mon, 11 Mar 2002 08:31:04 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Scott Bradner CC: ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Scott, Here is my view: we have been looking at this matter for a long time. As the same time, the data-plane problem has not gone away and is making every provider nervous. Part of the culture in many standardization bodies is a tendency to debate and argue and raise every issue to the highest level of abstraction. This process has almost become one of the elegance of the definition of the problem rather than the actual execution of an action plan. IETF should avoid this. In option 1, we will split the task among IETF and ITU. Don't think this will fly. First of all, we have just at least doubled our engineering work to solve the same problem. Second, we need to develop yet another plan to solve the integration problem so that the providers can actually figure out what to do in case of network trouble. Option 2 does sound a lot better, and I hope people can focus on solving the problem. Regards! - Ping Scott Bradner wrote: > It seems to me that there are two options on what we (the IETF) could do at > this point. > > 0/ you think I do not understand the issue > > 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and > cede to the ITU-T work on the more telco-like OAM. In this option the IETF > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an > MPLS reserved label value for use by the ITU-T to identify Y.1711 > information. > > 2/ The IETF work on a suite of technologies ranging from the > ping/traceroute-like mechanisms to the more telephone system OAM ones. The > IETF could try to figure out how to do this in conjunction with the ITU, > though it is a bit late for that considering the state of Y.1711, or be in > competition with the ITU-T. > > So - please indicate your opinion on how the IETF should proceed > > 1 - split the tasks between the IETF and the ITU-T > 2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T > > In any case, it would be good to provide feedback to the ITU-T on Y.1711 if > you see anything that looks broken. > > > Scott (with sub-ip AD hat on) > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 07:38:28 -0800 From: "Mohammad Siddiqui" To: ccamp@ops.ietf.org Cc: mpls-ops@mplsrc.com Bcc: Subject: Finding Remote IfIndex for OSPF for Unnumbered case Date: Mon, 11 Mar 2002 15:36:25 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, In ISIS, an attempt to add "Link Identifier TLV" was made to discover remote Link Identifier for Unnumbered Interfaces [draft-ietf-isis-gmpls-extensions-08.txt]. It was pointed out that ISIS already has an existing mechanism to exchange link identifiers - see draft-ietf-isis-3way-05.txt. Any way, while we're covered well in ISIS for this purpose, I was wondering what is the mechanism that should be used in OSPF in this regard? Is there anything that exists today and we can use, or there are some plans for adding a new sub-TLV, similar to "Link Identifier TLV" that was added to ISIS? Thanks /MS _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Mar 2002 05:23:20 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6019CBFD0@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Scott Bradner , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Mon, 11 Mar 2002 08:18:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C8FF.39CB3940" 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_01C1C8FF.39CB3940 Content-Type: text/plain; charset="iso-8859-1" Hi Scott I vote for 1. This seems to be the practical solution. Many have mentioned we need to keep the lines of communication open and I am for that. But 2a just seems too much like what we are doing right now and I don't think we are making progress. Don >1 - split the tasks between the IETF and the ITU-T > >2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T ------_=_NextPart_001_01C1C8FF.39CB3940 Content-Type: text/html; charset="iso-8859-1" RE: MPLS OAM & the IETF

Hi Scott

I vote for 1.

This seems to be the practical solution. Many have mentioned we
need to keep the lines of communication open and I am for that.
But 2a just seems too much like what we are doing right now and
I don't think we are making progress.

Don




>1 - split the tasks between the IETF and the ITU-T
>
>2 - IETF produce standards track documents covering both areas
>  2a - trying to work with the ITU-T to produce common technology
>  2b - in competition with the ITU-T

------_=_NextPart_001_01C1C8FF.39CB3940-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 10 Mar 2002 13:38:47 -0800 From: "Mohammad Siddiqui" To: tnadeau@cisco.com, ccamp@ops.ietf.org Cc: sob@harvard.edu Bcc: Subject: Re: MPLS OAM & the IETF Date: Sun, 10 Mar 2002 21:37:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: I second this and vote for 2. >From: "Thomas D. Nadeau" >To: ccamp@ops.ietf.org >CC: Scott Bradner >Subject: Re: MPLS OAM & the IETF >Date: Sun, 10 Mar 2002 12:28:19 -0500 > > > I vote for 2. Although I think there is room >for input in the form of requirements/requests and such >from the ITU, I think that having to interface with >the ITU for this work is going to lead to interop >problems as well as delay the work. The IETF created the >standards for MPLS and continues to evolve the technology, >so it makes sense to me that we continue to create and evolve >the standards for managing MPLS. > > --Tom > > >>Scott Bradner wrote: >> >> > >> > 0/ you think I do not understand the issue >> > >> > 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms >>and >> > cede to the ITU-T work on the more telco-like OAM. In this option the >>IETF >> > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign >>an >> > MPLS reserved label value for use by the ITU-T to identify Y.1711 >> > information. >> > >> > 2/ The IETF work on a suite of technologies ranging from the >> > ping/traceroute-like mechanisms to the more telephone system OAM ones. >>The >> > IETF could try to figure out how to do this in conjunction with the >>ITU, >> > though it is a bit late for that considering the state of Y.1711, or be >>in >> > competition with the ITU-T. >> > >> > So - please indicate your opinion on how the IETF should proceed >> > >> > 1 - split the tasks between the IETF and the ITU-T >> > 2 - IETF produce standards track documents covering both areas >> > 2a - trying to work with the ITU-T to produce common technology >> > 2b - in competition with the ITU-T >> > >> > In any case, it would be good to provide feedback to the ITU-T on >>Y.1711 if >> > you see anything that looks broken. >> > >> > Scott (with sub-ip AD hat on) > > > >------------------------------------------------------------------------ >Mathematics is the supreme nostalgia of our time. > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 10 Mar 2002 09:32:07 -0800 Message-Id: <4.3.2.7.2.20020310122319.01eef918@161.44.167.72> Date: Sun, 10 Mar 2002 12:28:19 -0500 To: ccamp@ops.ietf.org From: "Thomas D. Nadeau" Subject: Re: MPLS OAM & the IETF Cc: Scott Bradner Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I vote for 2. Although I think there is room for input in the form of requirements/requests and such from the ITU, I think that having to interface with the ITU for this work is going to lead to interop problems as well as delay the work. The IETF created the standards for MPLS and continues to evolve the technology, so it makes sense to me that we continue to create and evolve the standards for managing MPLS. --Tom >Scott Bradner wrote: > > > > > 0/ you think I do not understand the issue > > > > 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and > > cede to the ITU-T work on the more telco-like OAM. In this option the IETF > > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an > > MPLS reserved label value for use by the ITU-T to identify Y.1711 > > information. > > > > 2/ The IETF work on a suite of technologies ranging from the > > ping/traceroute-like mechanisms to the more telephone system OAM ones. The > > IETF could try to figure out how to do this in conjunction with the ITU, > > though it is a bit late for that considering the state of Y.1711, or be in > > competition with the ITU-T. > > > > So - please indicate your opinion on how the IETF should proceed > > > > 1 - split the tasks between the IETF and the ITU-T > > 2 - IETF produce standards track documents covering both areas > > 2a - trying to work with the ITU-T to produce common technology > > 2b - in competition with the ITU-T > > > > In any case, it would be good to provide feedback to the ITU-T on Y.1711 if > > you see anything that looks broken. > > > > Scott (with sub-ip AD hat on) ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 10 Mar 2002 06:04:02 -0800 Message-ID: <3C8B6738.C6812009@acm.org> Date: Sun, 10 Mar 2002 09:01:28 -0500 From: Matt Squire Reply-To: mattsquire@acm.org MIME-Version: 1.0 To: Scott Bradner CC: ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A vote for (1). The IETF should focus on the simple and ip-oriented utilities and get the darn thing done. The ITU should focus on the more generic MPLS utilities which need to get done but is a larger problem. Certainly this might lead to interoperability problems, but I hope the ITU will submit drafts to the IETF mailing lists for review. Drawing on the expertise of the IETF can help minimize the problems. There are also many testing labs and bakeoffs where problems can get found. Every extension has the possibility of creating interoperability problems yet they seem to keep coming, so lets split it up and be done with it. - Matt Scott Bradner wrote: > > 0/ you think I do not understand the issue > > 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and > cede to the ITU-T work on the more telco-like OAM. In this option the IETF > would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an > MPLS reserved label value for use by the ITU-T to identify Y.1711 > information. > > 2/ The IETF work on a suite of technologies ranging from the > ping/traceroute-like mechanisms to the more telephone system OAM ones. The > IETF could try to figure out how to do this in conjunction with the ITU, > though it is a bit late for that considering the state of Y.1711, or be in > competition with the ITU-T. > > So - please indicate your opinion on how the IETF should proceed > > 1 - split the tasks between the IETF and the ITU-T > 2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T > > In any case, it would be good to provide feedback to the ITU-T on Y.1711 if > you see anything that looks broken. > > Scott (with sub-ip AD hat on) Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 10 Mar 2002 02:36:11 -0800 Message-ID: <004e01c1c81e$674c1ce0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Scott Bradner" , Subject: Re: MPLS OAM & the IETF Date: Sun, 10 Mar 2002 10:27:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 2a An old and wise consultant used to advise me that there were management solutions to technical problems but never technical solutions to management problems. IETF and ITU-T are both successful organisations - else I would never get your messages nor you mine - but with very different ways of working and until we find a way that works for both of us, solving the management problem, we can never resolve technical issues such as these. Tom Petch, Network Consultant nwnetworks@dial.pipex.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 13:21:28 -0800 Message-ID: <31D95529A6F0D51193320008C791A76060D647@boca215a.boca.ssc.siemens.com> From: "Meehan, John" To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 8 Mar 2002 16:20:50 -0500 MIME-Version: 1.0 Content-Type: text/plain #4. Would be #1 if it didn't make it sound like SONET doesn't exist anymore as Eric Mannie said. But I must say I agree with Bob's statements below, the word "should" does bother me. -----Original Message----- From: Natale, Robert C (Bob) [mailto:bnatale@lucent.com] Sent: Friday, March 01, 2002 3:48 PM To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Hi, Apologies in advance for this post going against the grain of the AD's guidance for this thread. I am not (I hope!) posting a "diatribe" here :-) -- I am just curious about something and maybe the answer to it will affect my own and possibly others' assessment of the options before us.... As a non-expert (re the diffs between SONET and SDH as they might necessarily affect labeling requirements or not), I opted for #1 (or #4, which I consider to be its moral equivalent) on the basis of my interpretation of s/w engineering principles and my (negative) experience with allowing optionality in widely deployed standards. Since the respondents seems largely divided between #1 and #2 (with the few mentioning #4 as an acceptable alternative about equally divided between #1 and #2 as another acceptable choice for them), my attention is naturally drawn to the absence of any "votes" for #3 (apologies if I've missed anyone's vote for #3)...? The only diff that I can discern between #2 and #3 is the SHOULD in #2 vs the MUST in #3. It is that SHOULD in #2 that caused me to discount it up front. I am curious to know how the people expressing a preference for #2 feel about #3 -- that is, do they see it important that we specify #2 rather than #3, or rather than #1? I'm really against that SHOULD in #2. But -- although I do prefer #1 (or, second, #4) for the reasons mentioned above -- I might not feel as determinedly antagonistic to #3, if that were to end up being the WG's consensus. Thanks, BobN >At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote: >If people want to express their support for this 4th option >then that is fine with me. WG chair(s) do you agree too >(don't want to step on your toes or sit in your chair). > >Bert > > > -----Original Message----- > > From: Mannie, Eric > [mailto:Eric.Mannie@ebone.com] > > Sent: Tuesday, February 26, 2002 11:32 AM > > To: 'Wijnen, Bert (Bert)'; ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > > Hello Bert and all, > > > > One question is missing: > > > > 4) Do you think we should have just a single set of traffic > > parameters and label format (values) for both SDH and SONET. > > > > In 1) "none for SONET" assumes that SONET doesn't exist > > anymore. Note also that the traffic parameters are already > > identical, the only difference is about the label. As editor > > of these drafts I would like at least to see the right > > questions asked on the mailing list. > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > [mailto:bwijnen@lucent.com] > > Sent: Tuesday, February 26, 2002 10:37 AM > > To: ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic > > > parameters and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in > > > RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 12:32:48 -0800 Message-Id: <200203081858.NAA05075@telescope.cisco.com> To: "Don Fedyk" cc: George Swallow , Peter Willis , erosen@cisco.com, ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF Date: Fri, 08 Mar 2002 13:58:03 -0500 From: George Swallow > > > And the difference betwenn IP tunnels and circuits would be? > > > > At the service level not much except that ordered delivery cannot be > > assumed. > > > > But in between the end points - > > > > A circuit has a static (fixed) route, IP is dynamic. > > > > Intermediate nodes carrying a circuit usually have state associated > > with those circuits, IP nodes have no such state. > > MPLS LSPs have state associated with the LSPS on the intermediate > nodes. Seem like a case for circuit based diagnostics for MPLS! > > Don The statement I responded to (at the top of this message) did not mention MPLS. The point is circuit like techinique cannot and should not be applied across the board to all LSPs because not all LSPs behave like circuits (actually make that the overwhelming majority of LSPs). ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 11:55:08 -0800 Message-Id: <200203081953.OAA29696@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-fontana-ccamp-gmpls-g709-03.txt Date: Fri, 08 Mar 2002 14:53:11 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : D. Papadimitriou et al. Filename : draft-fontana-ccamp-gmpls-g709-03.txt Pages : 19 Date : 08-Mar-02 This document is a companion to the Generalized MPLS (GMPLS) signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It describes the G.709 [ITUT-G709] technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fontana-ccamp-gmpls-g709-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-fontana-ccamp-gmpls-g709-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-fontana-ccamp-gmpls-g709-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: <20020308144018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fontana-ccamp-gmpls-g709-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-fontana-ccamp-gmpls-g709-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020308144018.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 09:10:09 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60197C6C9@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: George Swallow , Peter Willis Cc: erosen@cisco.com, ccamp@ops.ietf.org Subject: RE: Tunnels v. circuits was Re: MPLS OAM & the IETF Date: Fri, 8 Mar 2002 12:08:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C6C3.EED874D0" 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_01C1C6C3.EED874D0 Content-Type: text/plain; charset="iso-8859-1" George > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, March 08, 2002 10:24 AM > To: Peter Willis > Cc: erosen@cisco.com; ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF > > > > And the difference betwenn IP tunnels and circuits would be? > > At the service level not much except that ordered delivery cannot be > assumed. > > But in between the end points - > > A circuit has a static (fixed) route, IP is dynamic. > > Intermediate nodes carrying a circuit usually have state associated > with those circuits, IP nodes have no such state. MPLS LSPs have state associated with the LSPS on the intermediate nodes. Seem like a case for circuit based diagnostics for MPLS! Don > > So in terms of diagnostics they are vastly different. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > ------_=_NextPart_001_01C1C6C3.EED874D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Tunnels v. circuits was Re: MPLS OAM & the IETF

George

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Friday, March 08, 2002 10:24 AM
> To: Peter Willis
> Cc: erosen@cisco.com; ccamp@ops.ietf.org; = swallow@cisco.com
> Subject: Re: Tunnels v. circuits was Re: MPLS = OAM & the IETF
>
>
> > And the difference betwenn IP tunnels and = circuits would be?
>
> At the service level not much except that = ordered delivery cannot be
> assumed.
>
> But in between the end points -
>
> A circuit has a static (fixed) route, IP is = dynamic.
>
> Intermediate nodes carrying a circuit usually = have state associated
> with those circuits, IP nodes have no such = state.

MPLS LSPs have state associated with the LSPS on the = intermediate
nodes. Seem like a case for circuit based = diagnostics for MPLS!

Don

>
> So in terms of diagnostics they are vastly = different.
>
> ...George
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow       Cisco = Systems           = ;       (978) 497-8143
>          = ;            250 = Apollo Drive
>          = ;            = Chelmsford, Ma 01824
>
>

------_=_NextPart_001_01C1C6C3.EED874D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 08:43:59 -0800 Date: Fri, 08 Mar 2002 11:36:14 -0500 From: Ron Bonica Subject: Gentle Reminder To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, Anyone producing Internet Drafts should read http://www.rfc-editor.org/policy.html and http://www.ietf.org/ID-nits.html. The ADs remind us that if a draft departs significantly from these guidelines, it may not be accepted. (Be careful about number of authors and be specific about reference types). =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Not all who wander are lost." -- J.R.R. Tolkien Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 07:53:18 -0800 Message-Id: <4.3.2.7.2.20020308104609.01e61980@161.44.167.72> Date: Fri, 08 Mar 2002 10:47:34 -0500 To: George Swallow From: "Thomas D. Nadeau" Subject: Re: draft-bonica-tunneltrace-02 Cc: neil.2.harrison@bt.com, pingpan@juniper.net, ecuevas@att.com, ccamp@ops.ietf.org, swallow@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Neil - > > > Thanks Ping.....nice to see a positive response from a specific > manufacturer > > to our concerns as operators on this. This is a really good positive step > > IMO. Its a shame other manufacturers have discounted Y.1710, as what > Enrique > >Unlike the ITU, members of the IETF act as individuals. It is >inappropriate to generalize the remarks of one person to an entire >company. >Further I believe that Tom was confused between Y.1710 and >Y.1711. George is correct. I mixed up the document numbers. Indeed, the OAM requirements are a very positive first step. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 07:26:35 -0800 Message-Id: <200203081524.KAA05234@telescope.cisco.com> To: Peter Willis cc: erosen@cisco.com, ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Tunnels v. circuits was Re: MPLS OAM & the IETF Date: Fri, 08 Mar 2002 10:24:07 -0500 From: George Swallow > And the difference betwenn IP tunnels and circuits would be? At the service level not much except that ordered delivery cannot be assumed. But in between the end points - A circuit has a static (fixed) route, IP is dynamic. Intermediate nodes carrying a circuit usually have state associated with those circuits, IP nodes have no such state. So in terms of diagnostics they are vastly different. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 04:01:38 -0800 Message-Id: <200203081156.GAA29262@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-03.txt Date: Fri, 08 Mar 2002 06:56:19 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang et al. Filename : draft-ietf-ccamp-lmp-03.txt Pages : 68 Date : 07-Mar-02 Optical networks are being developed to include photonic switches, optical crossconnects, and routers that are configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-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-lmp-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-lmp-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: <20020307115831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115831.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 02:22:51 -0800 Message-Id: <200203081021.KAA03413@celiborn.ip-engineering.bt.com> To: erosen@cisco.com cc: ccamp@ops.ietf.org Subject: Tunnels v. circuits was Re: MPLS OAM & the IETF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 10:21:02 +0000 From: Peter Willis Eric said: > It's that they think of LSPs as being more like IP tunnels than like > circuits. And the difference betwenn IP tunnels and circuits would be? ......... Not such a crazy question when you start to think about it! Regards, Peter Willis BTexact Technologies. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Mar 2002 00:57:56 -0800 Date: Fri, 08 Mar 2002 17:51:31 +0900 From: Yutaka SAKAI To: ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Message-Id: <20020308174956.6D5D.SAKAI@lab.jrc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit i am not expert but... If trend of communication move more ip-centric, *ip-based* #2a is more better. but i feel that ITU-T considers #1 or #3 (both well cared for legacy) as far as i heard about abstract report from last SG13 attendees. if something is wrong, please correct me. below figures are my current poor understandings. #0 starting point ------------------------------------------------- telco's OAM stack IETF tools (mainly ITU-T) ping, tracert etc | upper | |---------| | | | MPLS | | | |---------| | lower | #1 split the tasks ------------------------------------------------- telco's OAM stack IETF tools | upper | +----------+---------| | | | | MPLS OAM | MPLS | | ITU-T? | IETF? | +----------+---------| | lower | issue: How to split ? Does ITU-T want *all* OAM ? #2a produce common ------------------------------------------------- ******* *** ***** **** ***** | upper | |---------+----------+ | | common | | MPLS | MPLS OAM | | | ITU&IETF | |---------+----------+ | lower | issue: Which does it stand up for non-ip-centric or ip-centric ? #2b compete ------------------------------------------------- telco's OAM stack IETF tools | upper | + -- -- +---------+ -- -- + | | | MPLS OAM | MPLS | MPLS OAM | ITU-T | | IETF + -- -- +---------+ -- -- + | lower | issue: Are there more two ways ? #2b-1 at last, select only one or #2b-2 fight forever (=not same as #3) #3 split & dual adhoc (by Mina Azad) ------------------------------------------------- telco's OAM stack IETF tools | upper | +----------+---------+----------+ | non-ip.. | | ip-based | | MPLS OAM | MPLS | MPLS OAM | | ITU-T | | IETF | +----------+---------+----------+ | lower | issue: Do we want to swim in muddy waters ? #3-2 for non-ip-centric by ITU and #3-3 for ip-centric by IETF regards, Yutaka Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 15:34:44 -0800 Message-ID: From: Raj Sharma To: 'Scott Bradner' , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 15:30:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2a > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Wednesday, March 06, 2002 7:34 AM > To: ccamp@ops.ietf.org > Subject: MPLS OAM & the IETF > > > subject: MPLS OAM & the IETF > > The result of the MPLS OAM BOF in Salt Lake City has been > confirmed over > the last few days in the mailing list thread > "draft-bonica-tunneltrace-02." > > > That result was and is that there are at least two quite > different views on > the type of OAM tools and technologies needed for MPLS networks. > > My reading of the groups is that one group, who are mostly > concerned with > the transport of IP over MPLS, generally feel that tools > approximating the > traditional "ping" and "traceroute" tools used on IP networks are > sufficient. A second group seems to feel that those tools do > not provide > enough of a view of the service a customer is getting to be > sufficient and > that tools approximating traditional telephone system OAM > tools are needed > to get the complete picture. > > Meanwhile, the ITU-T has been working in this area and has a > document in > their equivalent of the IETF Last-Call. Brian Moore, the > ITU-T Study Group > 13 chair, kindly arraigned for the ITU-T document (known as > Y.1711) to be > put on an ftp site so interested IETF folk can take a look at > what they > have done. The URL is > http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht ml (IETF folk have to register to use the FTP site.) It seems to me that there are two options on what we (the IETF) could do at this point. 0/ you think I do not understand the issue 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and cede to the ITU-T work on the more telco-like OAM. In this option the IETF would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an MPLS reserved label value for use by the ITU-T to identify Y.1711 information. 2/ The IETF work on a suite of technologies ranging from the ping/traceroute-like mechanisms to the more telephone system OAM ones. The IETF could try to figure out how to do this in conjunction with the ITU, though it is a bit late for that considering the state of Y.1711, or be in competition with the ITU-T. So - please indicate your opinion on how the IETF should proceed 1 - split the tasks between the IETF and the ITU-T 2 - IETF produce standards track documents covering both areas 2a - trying to work with the ITU-T to produce common technology 2b - in competition with the ITU-T In any case, it would be good to provide feedback to the ITU-T on Y.1711 if you see anything that looks broken. Scott (with sub-ip AD hat on) Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 11:20:12 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Message-Id: Date: Thu, 07 Mar 2002 11:19:05 -0800 > I think the essence of the questions raised by Scott at this point is > not whether IETF should work on simple tools presented or not, rather > should IETF also work on the comprehensive OAM tools, as described in > the BOF, or leave it to ITU. we transport ip over atm, but someone else does the non-ip atm tools. we do the ip-oriented tools. i am not jealous of the itu. each body brings expertise to the table. we need the best expertise focused on any issue. where we need to overlap is ensuring we have a consistent architecture and harmonious non-conflicting details. randy Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 10:44:19 -0800 Date: Thu, 7 Mar 2002 13:42:38 -0500 (EST) From: Scott Bradner Message-Id: <200203071842.g27Igci16581@newdev.harvard.edu> To: ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Shahram sez: > I think the essence of the questions raised by Scott at this point is > not whether IETF should work on simple tools presented or not, rather > should IETF also work on the comprehensive OAM tools, as described > in the BOF, or leave it to ITU. that is what I tried to ask - thanks for making it clearer Scott Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 09:24:28 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34021C2909@zcard0ka.ca.nortel.com> From: "Mina Azad" To: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 12:23:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5FC.CAE0B8C0" 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_01C1C5FC.CAE0B8C0 Content-Type: text/plain; charset="iso-8859-1" As it's been pointed out on the mailing list in a various ways, option 1 is pragmatic but needs clarification. I'd like to suggest a third option which is effectively refinement to "1". Option 3: Principles of this option: Split the OAM (M stands for management and measurement) work between ITU and ITEF with commitment on both bodies to work towards complementing solutions, taking into consideration the core competency of the two standard bodies and the business drivers behind the technologies (from vendor, operator, and standards perspectives). In specific, option 3 proposes splitting the OAM in three areas 1) Definition and mechanism for availability and measurement to be handled by ITU 2) ad-hoc diagnostic tools for ip-centric networks to be handled by IETF 3) ad-hoc diagnostic and measurement tools primarily for non-ip-centric networks to be handled by ITU Regards, Mina Azad ------_=_NextPart_001_01C1C5FC.CAE0B8C0 Content-Type: text/html; charset="iso-8859-1" RE: MPLS OAM & the IETF
As it's been pointed out on the mailing list in a various ways, option 1 is pragmatic but needs clarification.
I'd like to suggest a third option which is effectively  refinement to "1".
 
Option 3:
Principles of this option: Split the OAM (M stands for management and measurement) work between ITU and ITEF with commitment on both bodies to work towards complementing solutions, taking into consideration the core competency of the two standard bodies and the business drivers behind the technologies (from vendor, operator, and standards perspectives).

In specific, option 3 proposes splitting the OAM in three areas

      1) Definition and mechanism for availability and measurement to be handled by ITU  
      2) ad-hoc diagnostic tools for ip-centric networks to be handled by IETF
      3) ad-hoc diagnostic and measurement tools primarily for non-ip-centric networks to be handled by ITU         

Regards,

Mina  Azad

------_=_NextPart_001_01C1C5FC.CAE0B8C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 09:04:19 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34021C28A2@zcard0ka.ca.nortel.com> From: "David Allan" To: John Drake , "'George Swallow'" , Shahram Davari Cc: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 12:03:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5FA.06C64EC0" 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_01C1C5FA.06C64EC0 Content-Type: text/plain; charset="iso-8859-1" John/George: Superficially this would appear to be a sensible view, but we have gotten to this point because for whatever reasons, on this subject the IETF has not served a portion of its community, both vendors and providers. This has been an ongoing issue. I agree with Eric that '1' is a pragmatic view that acknowledges how we got to this point, and given the volume of past discussions on the subject, no other method of arbitration appears to be tractable. IMHO '1' will need refinement to become more workable. If we can get to agreement that the OAM stuff should be done elsewhere, and bundle that with some agreement to cooperate on the key interoperablity issues (mainly IANA concerns), that should provide some form of workable framework. Ultimately it is the folks that buy this stuff that demand interoperability, and we will be answerable to them for all our sins. ;-) Dave > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, March 07, 2002 10:42 AM > To: 'George Swallow'; Shahram Davari > Cc: 'Scott Bradner'; ccamp@ops.ietf.org > Subject: RE: MPLS OAM & the IETF > > > George, > > A very sensible view. > > Thanks, > > John > > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, March 06, 2002 9:26 AM > To: Shahram Davari > Cc: 'Scott Bradner'; ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: MPLS OAM & the IETF > > > > Could you please clarify option (1) a bit more? If this route is > > taken, still cooperation is needed between ITU and IETF. For example > > ITU may need MPLS signaling extensions. Also in some cases packet > > processing may need to be aligned between ITU and IETF in order to > > avoid conflicts. For example ITU may consider an MPLS > path-trace that > > uses TTL expiration, which requires a TTL expired MPLS packet to be > > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL > > expired packets to ICMP/GTTP module. There needs to be a > coordination > > between IETF and ITU in order to find a common method which could > > determine whether a packet should be forwarded to OAM or ICMP/GTTP > > module. > > It's precisely issues such as these that lead me to believe that it > would be best if *only one* standards body owns a core technology. > Certainly other bodies should be free to create applications, define > extentions, and do implementation agreements. But when it come to > something a central as the basic forwarding plane, one group alone > should handle it. > > Allowing another body to redifine core functions WILL lead to > interoperability problems. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > ------_=_NextPart_001_01C1C5FA.06C64EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS OAM & the IETF

John/George:

Superficially this would appear to be a sensible = view, but we have gotten to this point because for whatever reasons, on = this subject the IETF has not served a portion of its community, both = vendors and providers. This has been an ongoing issue.

I agree with Eric that '1' is a pragmatic view that = acknowledges how we got to this point, and given the volume of past = discussions on the subject, no other method of arbitration appears to = be tractable. IMHO '1' will need refinement to become more = workable.

If we can get to agreement that the OAM stuff should = be done elsewhere, and bundle that with some agreement to cooperate on = the key interoperablity issues (mainly IANA concerns), that should = provide some form of workable framework.  Ultimately it is the = folks that buy this stuff that demand interoperability, and we will be = answerable to them for all our sins. ;-)

Dave

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]=
> Sent: Thursday, March 07, 2002 10:42 AM
> To: 'George Swallow'; Shahram Davari
> Cc: 'Scott Bradner'; ccamp@ops.ietf.org
> Subject: RE: MPLS OAM & the IETF
>
>
> George,
>
> A very sensible view.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, March 06, 2002 9:26 AM
> To: Shahram Davari
> Cc: 'Scott Bradner'; ccamp@ops.ietf.org; = swallow@cisco.com
> Subject: Re: MPLS OAM & the IETF
>
>
> > Could you please clarify option (1) a bit = more? If this route is
> > taken, still cooperation is needed between = ITU and IETF. For example
> > ITU may need MPLS signaling extensions. = Also in some cases packet
> > processing may need to be aligned between = ITU and IETF in order to
> > avoid conflicts. For example ITU may = consider an MPLS
> path-trace that
> > uses TTL expiration, which requires a TTL = expired MPLS packet to be
> > forwarded to MPLS OAM module, while GTTP = considers sending MPLS TTL
> > expired packets to ICMP/GTTP module. There = needs to be a
> coordination
> > between IETF and ITU in order to find a = common method which could
> > determine whether a packet should be = forwarded to OAM or ICMP/GTTP
> > module.
>
> It's precisely issues such as these that lead = me to believe that it
> would be best if *only one* standards body owns = a core technology.
> Certainly other bodies should be free to create = applications, define
> extentions, and do implementation = agreements.  But when it come to
> something a central as the basic forwarding = plane, one group alone
> should handle it.
>
> Allowing another body to redifine core = functions WILL lead to
> interoperability problems.
>
> ...George
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow       Cisco = Systems           = ;       (978) 497-8143
>          = ;            250 = Apollo Drive
>          = ;            = Chelmsford, Ma 01824
>
>

------_=_NextPart_001_01C1C5FA.06C64EC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 08:48:11 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5FC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Joel M. Halpern'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 08:47:33 -0800 MIME-Version: 1.0 Content-Type: text/plain Joel, I think the essence of the questions raised by Scott at this point is not whether IETF should work on simple tools presented or not, rather should IETF also work on the comprehensive OAM tools, as described in the BOF, or leave it to ITU. -Shahram > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Thursday, March 07, 2002 11:30 AM > To: ccamp@ops.ietf.org > Subject: RE: MPLS OAM & the IETF > > > Having watched some of the discussion in SLC, and much of the > discussion on > this list, a couple of things were and are clear. > > There are two different sets of objectives. Sharam and Neil want a > comprehensive OAM solution. In contrast, Ron and others are > looking to > define a simple tool. It was agreed in Salt Lake that these > are different > tasks. > > My understanding is that the CCAMP working group has agreed > to undertake > the task of defining a simple tool for a simple problem. The > ADs have > agreed that this is within scope. > > The debate then should focus on the documents for that simple > problem. One > should have, at this point, a relatively small number of > clear choices: > You can argue that the working group should not define a > solution for the > simple case. I thought there was consensus to solve this, if > there really > isn't then we should not have a working group document. > You can argue that the description of the problem in the proposed > requirements draft is completely off base. In that case, > given the stage > of development, I think you should bring in a draft as to what the > requirements you do see FOR THE SIMPLE CASE. A complete > draft about what > the full set of OAM needs for an operator are does not > address the question. > In the absence of an alternative draft, and given the > consensus to work on > the simple case, we should take the starting point we have, and fix > whatever problems there are. Taking it as a working group > document is not > a vacuous action, but it does not mean "it is done, start > last call". It > means this is a decent starting point. (And having a > starting point is the > only way to make progress.) > > Yours, > Joel M. Halpern > > At 08:05 AM 3/7/02 -0800, Shahram Davari wrote: > >Giles, > > > > > Agreed. > > > > > > I'm not sure which of Scott's options this corresponds > to, though! I > > > don't want to see the IETF working on MPLS OAM as per > option 2, but > > > option 1 seems to be a step down the road of allowing the ITU to > > > "co-own" MPLS? > > > > > > >It seems that developing non-IP OAM tools for MPLS is not in > the spirit of > >IETF. However, it seems that many operators want functions > more than ping > >and trace-route for their MPLS networks that are used to carry their > >legacy traffic. > > > >Y.1711 and future ITU recommendations would possibly use > MPLS data-plane > >to carry the MPLS OAM packets, but that doesn't mean that > ITU will co-own > >the MPLS. Everybody knows that the MPLS data-plane as well as MPLS > >IP-based control-plane and MPLS IP-based management-plane > are owned by IETF. > > > >Besides any need by ITU for extensions to IETF standards > will formally go > >through IETF channels, and therefore be under IETF control. > > > >Therefore I think if there is a clear delineation of work > and procedures > >for the cooperation, then most of your concerns could be addressed. > > > >Yours, > >-Shahram > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 08:35:26 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5FB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ron Bonica'" Cc: ccamp@ops.ietf.org Subject: NEW SUBJECT: draft-bonica-tunproto-01.txt Date: Thu, 7 Mar 2002 08:35:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C5F6.0AA72F40" 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_01C1C5F6.0AA72F40 Content-Type: text/plain; charset="iso-8859-1" Hi Ron, As you may know after some discussions with Ping Pan regarding the use of ICMP-ping/LSP-Ping is non-IP carrying LSPs, he revised his draft and added the following text: " To test an LSP that carries non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, the IPv4 Explicit NULL label should be prepended to such messages." It seems to me that the same principle applies to GTTP. Therefore I would like to suggest adding the same kind of text to your GTTP draft for this special case. Yours, -Shahram ------_=_NextPart_001_01C1C5F6.0AA72F40 Content-Type: text/html; charset="iso-8859-1" RE: draft-bonica-tunneltrace-02
Hi Ron,
 
As you may know after some discussions with Ping Pan regarding the use of ICMP-ping/LSP-Ping is non-IP carrying LSPs, he revised his draft and added the following text:
 
"  To test an LSP that carries non-IP traffic, before injecting ICMP and
   MPLS ping messages into the LSP, the IPv4 Explicit NULL label should
   be prepended to such messages."
 
It seems to me that the same principle applies to GTTP. Therefore I would like to suggest adding the same kind of text to your GTTP draft for this special case.
 
Yours,
-Shahram
------_=_NextPart_001_01C1C5F6.0AA72F40-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 08:32:09 -0800 Message-Id: <4.2.2.20020307112327.00c14380@mail.stevecrocker.com> Date: Thu, 07 Mar 2002 11:30:02 -0500 To: ccamp@ops.ietf.org From: "Joel M. Halpern" Subject: RE: MPLS OAM & the IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Having watched some of the discussion in SLC, and much of the discussion on this list, a couple of things were and are clear. There are two different sets of objectives. Sharam and Neil want a comprehensive OAM solution. In contrast, Ron and others are looking to define a simple tool. It was agreed in Salt Lake that these are different tasks. My understanding is that the CCAMP working group has agreed to undertake the task of defining a simple tool for a simple problem. The ADs have agreed that this is within scope. The debate then should focus on the documents for that simple problem. One should have, at this point, a relatively small number of clear choices: You can argue that the working group should not define a solution for the simple case. I thought there was consensus to solve this, if there really isn't then we should not have a working group document. You can argue that the description of the problem in the proposed requirements draft is completely off base. In that case, given the stage of development, I think you should bring in a draft as to what the requirements you do see FOR THE SIMPLE CASE. A complete draft about what the full set of OAM needs for an operator are does not address the question. In the absence of an alternative draft, and given the consensus to work on the simple case, we should take the starting point we have, and fix whatever problems there are. Taking it as a working group document is not a vacuous action, but it does not mean "it is done, start last call". It means this is a decent starting point. (And having a starting point is the only way to make progress.) Yours, Joel M. Halpern At 08:05 AM 3/7/02 -0800, Shahram Davari wrote: >Giles, > > > Agreed. > > > > I'm not sure which of Scott's options this corresponds to, though! I > > don't want to see the IETF working on MPLS OAM as per option 2, but > > option 1 seems to be a step down the road of allowing the ITU to > > "co-own" MPLS? > > > >It seems that developing non-IP OAM tools for MPLS is not in the spirit of >IETF. However, it seems that many operators want functions more than ping >and trace-route for their MPLS networks that are used to carry their >legacy traffic. > >Y.1711 and future ITU recommendations would possibly use MPLS data-plane >to carry the MPLS OAM packets, but that doesn't mean that ITU will co-own >the MPLS. Everybody knows that the MPLS data-plane as well as MPLS >IP-based control-plane and MPLS IP-based management-plane are owned by IETF. > >Besides any need by ITU for extensions to IETF standards will formally go >through IETF channels, and therefore be under IETF control. > >Therefore I think if there is a clear delineation of work and procedures >for the cooperation, then most of your concerns could be addressed. > >Yours, >-Shahram > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 08:06:06 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5FA@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" , George Swallow Cc: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 08:05:45 -0800 MIME-Version: 1.0 Content-Type: text/plain Giles, > Agreed. > > I'm not sure which of Scott's options this corresponds to, though! I > don't want to see the IETF working on MPLS OAM as per option 2, but > option 1 seems to be a step down the road of allowing the ITU to > "co-own" MPLS? > It seems that developing non-IP OAM tools for MPLS is not in the spirit of IETF. However, it seems that many operators want functions more than ping and trace-route for their MPLS networks that are used to carry their legacy traffic. Y.1711 and future ITU recommendations would possibly use MPLS data-plane to carry the MPLS OAM packets, but that doesn't mean that ITU will co-own the MPLS. Everybody knows that the MPLS data-plane as well as MPLS IP-based control-plane and MPLS IP-based management-plane are owned by IETF. Besides any need by ITU for extensions to IETF standards will formally go through IETF channels, and therefore be under IETF control. Therefore I think if there is a clear delineation of work and procedures for the cooperation, then most of your concerns could be addressed. Yours, -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 07:58:36 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5F9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'John Drake'" , "'George Swallow'" Cc: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 07:58:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, I have to disagree with you here. I don't think defining a non-IP based OAM for MPLS is in-line with what you described as "redefining core functions". -Shahram > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, March 07, 2002 10:42 AM > To: 'George Swallow'; Shahram Davari > Cc: 'Scott Bradner'; ccamp@ops.ietf.org > Subject: RE: MPLS OAM & the IETF > > > George, > > A very sensible view. > > Thanks, > > John > > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, March 06, 2002 9:26 AM > To: Shahram Davari > Cc: 'Scott Bradner'; ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: MPLS OAM & the IETF > > > > Could you please clarify option (1) a bit more? If this route is > > taken, still cooperation is needed between ITU and IETF. For example > > ITU may need MPLS signaling extensions. Also in some cases packet > > processing may need to be aligned between ITU and IETF in order to > > avoid conflicts. For example ITU may consider an MPLS > path-trace that > > uses TTL expiration, which requires a TTL expired MPLS packet to be > > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL > > expired packets to ICMP/GTTP module. There needs to be a > coordination > > between IETF and ITU in order to find a common method which could > > determine whether a packet should be forwarded to OAM or ICMP/GTTP > > module. > > It's precisely issues such as these that lead me to believe that it > would be best if *only one* standards body owns a core technology. > Certainly other bodies should be free to create applications, define > extentions, and do implementation agreements. But when it come to > something a central as the basic forwarding plane, one group alone > should handle it. > > Allowing another body to redifine core functions WILL lead to > interoperability problems. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 07:42:17 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E24A@nimbus> From: John Drake To: 'George Swallow' , Shahram Davari Cc: 'Scott Bradner' , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 07:41:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, A very sensible view. Thanks, John -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Wednesday, March 06, 2002 9:26 AM To: Shahram Davari Cc: 'Scott Bradner'; ccamp@ops.ietf.org; swallow@cisco.com Subject: Re: MPLS OAM & the IETF > Could you please clarify option (1) a bit more? If this route is > taken, still cooperation is needed between ITU and IETF. For example > ITU may need MPLS signaling extensions. Also in some cases packet > processing may need to be aligned between ITU and IETF in order to > avoid conflicts. For example ITU may consider an MPLS path-trace that > uses TTL expiration, which requires a TTL expired MPLS packet to be > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL > expired packets to ICMP/GTTP module. There needs to be a coordination > between IETF and ITU in order to find a common method which could > determine whether a packet should be forwarded to OAM or ICMP/GTTP > module. It's precisely issues such as these that lead me to believe that it would be best if *only one* standards body owns a core technology. Certainly other bodies should be free to create applications, define extentions, and do implementation agreements. But when it come to something a central as the basic forwarding plane, one group alone should handle it. Allowing another body to redifine core functions WILL lead to interoperability problems. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 07:17:51 -0800 Message-Id: <200203071515.KAA24538@erosen-u10.cisco.com> To: Scott Bradner cc: ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Mar 2002 10:15:07 -0500 From: Eric Rosen Scott> My reading of the groups is that one group, who are mostly concerned Scott> with the transport of IP over MPLS, generally feel that tools Scott> approximating the traditional "ping" and "traceroute" tools used on IP Scott> networks are sufficient. A second group seems to feel that those Scott> tools do not provide enough of a view of the service a customer is Scott> getting to be sufficient and that tools approximating traditional Scott> telephone system OAM tools are needed to get the complete picture. I would pick just two nits with this statement: - It's not so much that the first group are concerned mostly with the transport of IP over MPLS, since many in the first group are actively involved in the PWE3 and L2VPN efforts. It's that they think of LSPs as being more like IP tunnels than like circuits. - The criteria for something falling into the category of "traditional telephone system OAM tools" need to be well specified. Every time we propose to work on a management tool, we don't want to spend a year debating whether it falls into that category or not. Assuming that we can specify such criteria, the advantage of Scott's option 1 is that it excludes the telco-style stuff from the IETF, thereby breaking the logjams that we've been seeing in the this and other WGs. While option 2a seems reasonable at first glance, I don't think it is implementable. In some ways, option 2b is the most attractive; it doesn't prevent the IETF from working on anything, and doesn't constrain the IETF in any way. This is in fact the status quo situation. But it seems to be preventing progress in the WGs. Whether this is really a systemic problem, or simply a matter of personalities, is unclear. So 2b isn't working out well, but 1 might be overly constraining to the IETF. I have to wonder whether there is something short of 1 which could eliminate the WG logjams. All we really need to break the logjam right now is a decision to pursue the ping and traceroute tools; maybe we don't need a grandiose meta-chartering decision. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 02:57:33 -0800 Message-ID: <3C8747D2.7020104@packetexchange.net> Date: Thu, 07 Mar 2002 10:58:26 +0000 From: Giles Heron Organization: PacketExchange Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit personally I'm not too worried either way whether the IETF works on GMPLS or not. But in any case I don't think anyone in the IETF was suggesting using GMPLS as a mechanism for changing the forwarding plane of SDH or OTNs? Giles neil.2.harrison@bt.com wrote: > Come on guys...you cannot say this and still allow IETF to countenance GMPLS > work on SDH/OTNs. It also presupposes one has agreement on some quite > fundamental networking principles that *have* to embrace cnls, co/pkt-sw and > co/cct-sw, and to date I am not comfortable I can 'trust' one body to create > the required networking solutions I need. > > regards, Neil > > Giles Heron wrote 06 March 2002 23:17 > >>George Swallow wrote: >> >> >>>>Could you please clarify option (1) a bit more? If this route is >>>>taken, still cooperation is needed between ITU and IETF. For example >>>>ITU may need MPLS signaling extensions. Also in some cases packet >>>>processing may need to be aligned between ITU and IETF in order to >>>>avoid conflicts. For example ITU may consider an MPLS >>>> >>path-trace that >> >>>>uses TTL expiration, which requires a TTL expired MPLS packet to be >>>>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL >>>>expired packets to ICMP/GTTP module. There needs to be a >>>> >>coordination >> >>>>between IETF and ITU in order to find a common method which could >>>>determine whether a packet should be forwarded to OAM or ICMP/GTTP >>>>module. >>>> >>>> >>>It's precisely issues such as these that lead me to believe that it >>>would be best if *only one* standards body owns a core technology. >>>Certainly other bodies should be free to create applications, define >>>extentions, and do implementation agreements. But when it come to >>>something a central as the basic forwarding plane, one group alone >>>should handle it. >>> >>>Allowing another body to redifine core functions WILL lead to >>>interoperability problems. >>> >> >>Agreed. >> >>I'm not sure which of Scott's options this corresponds to, though! I >>don't want to see the IETF working on MPLS OAM as per option 2, but >>option 1 seems to be a step down the road of allowing the ITU to >>"co-own" MPLS? >> >>Giles >> >> > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 02:56:32 -0800 Message-ID: From: "Gibson, Mark" To: ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 10:49:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2a) So - please indicate your opinion on how the IETF should proceed 1 - split the tasks between the IETF and the ITU-T 2 - IETF produce standards track documents covering both areas 2a - trying to work with the ITU-T to produce common technology 2b - in competition with the ITU-T In any case, it would be good to provide feedback to the ITU-T on Y.1711 if you see anything that looks broken. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 02:40:35 -0800 Message-ID: From: neil.2.harrison@bt.com To: giles@packetexchange.net Cc: ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Thu, 7 Mar 2002 10:34:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Come on guys...you cannot say this and still allow IETF to countenance GMPLS work on SDH/OTNs. It also presupposes one has agreement on some quite fundamental networking principles that *have* to embrace cnls, co/pkt-sw and co/cct-sw, and to date I am not comfortable I can 'trust' one body to create the required networking solutions I need. regards, Neil Giles Heron wrote 06 March 2002 23:17 > George Swallow wrote: > > >>Could you please clarify option (1) a bit more? If this route is > >>taken, still cooperation is needed between ITU and IETF. For example > >>ITU may need MPLS signaling extensions. Also in some cases packet > >>processing may need to be aligned between ITU and IETF in order to > >>avoid conflicts. For example ITU may consider an MPLS > path-trace that > >>uses TTL expiration, which requires a TTL expired MPLS packet to be > >>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL > >>expired packets to ICMP/GTTP module. There needs to be a > coordination > >>between IETF and ITU in order to find a common method which could > >>determine whether a packet should be forwarded to OAM or ICMP/GTTP > >>module. > >> > > > > It's precisely issues such as these that lead me to believe that it > > would be best if *only one* standards body owns a core technology. > > Certainly other bodies should be free to create applications, define > > extentions, and do implementation agreements. But when it come to > > something a central as the basic forwarding plane, one group alone > > should handle it. > > > > Allowing another body to redifine core functions WILL lead to > > interoperability problems. > > > Agreed. > > I'm not sure which of Scott's options this corresponds to, though! I > don't want to see the IETF working on MPLS OAM as per option 2, but > option 1 seems to be a step down the road of allowing the ITU to > "co-own" MPLS? > > Giles > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 02:40:32 -0800 Message-ID: From: neil.2.harrison@bt.com To: swallow@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 7 Mar 2002 10:34:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks George.....I accept/agree. neil > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 06 March 2002 18:41 > To: neil.2.harrison@bt.com > Cc: pingpan@juniper.net; ecuevas@att.com; tnadeau@cisco.com; > ccamp@ops.ietf.org; swallow@cisco.com > Subject: Re: draft-bonica-tunneltrace-02 > > > Neil - > > > Thanks Ping.....nice to see a positive response from a > specific manufacturer > > to our concerns as operators on this. This is a really > good positive step > > IMO. Its a shame other manufacturers have discounted > Y.1710, as what Enrique > > Unlike the ITU, members of the IETF act as individuals. It is > inappropriate to generalize the remarks of one person to an entire > company. Further I believe that Tom was confused between Y.1710 and > Y.1711. > > Y.1710 is a reasonable document. Mostly great stuff that any vendor > wanting to sell to carriers should take very seriously. As do I. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Mar 2002 00:12:25 -0800 Message-ID: From: neil.2.harrison@bt.com To: jdrake@calient.net Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 7 Mar 2002 08:10:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John...see below. regards, Neil > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 07 March 2002 04:39 > To: 'neil.2.harrison@bt.com'; erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Neil, > > I asked a simple question and expected a simple answer. > Instead, you send > this example of incoherence raised to an arm form. NH=> It's not incoherent to me and many others. Not sure I would class it as an 'art form' its just compelling logic to me. > > Since you raised the specter of GMPLS, NH=> Interesting choice of word to describe GMPLS.....have you seen the future? ;-) > did you consider that > we could just > as easily take the fault detection/isolation procedures of GMPLS and > re-apply them to MPLS? NH=> But that's exactly what I said! That is, it is the *principles* of having defect detection/handling in the data-plane that is the thing that is invariant/common, not the 1 size fits all *specific* mechanism which is attempted to be force-fed to all layers. And 2 of the most important/fundamantal principles here are: - decoupled from any client/server technologies (ie the layer violation issue....absolutely critical for data-plane protocol evolation) - decoupled from any control or management plane protocols (or indeed the data plane on which these protocols run....since in many cct-sw/co technologies this is *not* congruent topologically (and certainly not functionally) with the data-plane of the traffic). Again absolutely critical for protocol evolution (all planes). The rest then follows as I explained. So...to re-interate the key message.....the thing that is *common* are the principles, the actual mechanism has variations dependent on transfer mode (ie cnls vs co) and (for co) whether cct-sw or pkt sw. If you are stuggling still to grasp the point I am making think about the control-plane and the GMPLS example you mention. The basic (network) function is 'find/route/connect' and this applies to all network layers (OAM addresses the 'maintain' part of these basic functions that also applies to all layer networks). So we need addressing/routing (applies to both cnls/co) and signalling (for co) facets for all layer networks. The actual choice of addressing, routing protocol and signalling protocol is purely a matter of 'fit for purpose', there are lots of options and there will be ongoing development in each. So the only thing that is enduring is the 'find/route/connect' principle and the functions they cover, not some specific protocol embodiment that is current today. Now if you are asking me whether the actual protocols chosen for deploying a control-plane for SDH/OTN are 'fit for purpose' that is a different question that raises both (i) commercial and (ii) technical issues that need careful consideration.....and I don't want to get into that one here. > Thanks, > > John > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, March 05, 2002 4:08 PM > To: John Drake; erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > No problem John......really glad you asked this question as > the answer is > dead easy: > > The simple/one-liner answer is to ask you to read > Y.1710.....I wrote this > after a conversation Maartin Vissers and I had a few years > ago (on a bus in > Turin or somewhere) where we effectively said: > - the network problems are effectively the same > irrespective of the > technology, ie find/route/connect/maintain > - there are some differences dependent on transfer mode, > ie cnls is > different to co, and in co there are some differnces wrt to cct-sw vs > pkt-sw....but in essence, the 'network' problems are invariant > - and focusssing in the OAM aspects one can lay down some > principles > that are largely technology independent and quite > generic....ergo Y.1710. > > However, assuming one has never read Y.1710 the arguments follow this > general reasoning: > > - 1st define the defects specific to the layer > network/technology of > interest....now clearly these are different in specifics > whether one is > considering an OTN trail, a SDH VC-4 trail, an ATM VP trails > or an MPLS LSP > trail (etc)........but they all clearly embrace: > * simple breaks within/below the layer of interest > * swapped/misconfigured trails > * mismerged trails (these can only happen with co pkt > modes *and* > relative addressing, ie labels....cnls pkts use *absolute* > addressing, ie > each pkt carries a trail-trace by definition (ie source > address), which is a > generic requirement as noted below and so complies). > > - 2nd, since we know the data-plane trails carrying the > *traffic* can > be totally decoupled from the data-plane trails carrying control > (signalling/routing) or management plane protocols then each > data-plane must > have its own defect detection/handling mechanisms which are (i) not > dependent on any other specific client/server layer networks > (essential for > technology compatibility/evolution....aka layer violations) > and (ii) not > dependent on any specific control/mananagent-plane protocols (or their > data-plane), inc none, for similar reasons....very obvious in > cct-sw/GMPLS > applications IMO; > > - 3rd, given above, its obvious that the data-plane (be > it carrying > traffic/control/management protocols, which can be in > orthogonal data-plane > network embodiments please note) must carry its own OAM > mechanisms.....again, very obvious in the case of cct-sw (esp > OTN), but same > applies to pkt-sw. Not so true in case of cnls.....where one can ask > certain (higher level) control (say) plane protocols to proxy > for data-plane > OAM. The generic solution is here it to send some > 'trail-trace' identifier > periodically source/sink......this is exactly what is done in > SDH VCs for > example, and same should be done in pkt networks, ie same > generic principle. > And as I noted above, cnls protocols like IP carry a trail-trace (ie > absolute source address) in each/every pkt since the > addressing is absolute > not relative (assuming globally unique addressing of > course).....so IP also > fits the model for this aspect. > > > - 4th, then define the entry/exit criteria for each defect inc the > consequent actions one needs for each....some obvious ones being: > * let's not have multiple client layer alarm storms > above the level > of the defect (esp since these can be geograhically/organisationally > disperse)...so we need some form of FDI (Forward Defect > Indication) for > this. So again this is a generic function, aka AIS in SDH/OTN. > * some local alarm is needed....again pretty generic. > * its useful to tell the source of far end failures in > some cases > (ie single-ended both-direction monitoring of > QoS/availability SLAs say, or > N:M prot-sw).....so this requires a generic BDI (Backward > Derect Indication) > of some kind that mirrors the FDI. > * with swapped/mismerged connections traffic > suppression is in order > to protect the customer information integrity....again quite generic. > > - 5th, in CO networks (be they pkt or cct-sw) > availabililty is the key > perf metric. So we can define this based on defect > persistence. QoS metric > measurements only makes sense when in the 'available' > state.....so if you > want to offer/measure availability/QoS SLAs you need to pay > attention to > this point. > BTW - In Y.1711 I have drawn out the near-end/far-end > processing for LSPs > wrt availability state to help people since this is the hard > bit.....though > the actual protocol is trivial, ie its only 1 > keepalive/trail-trace (CV) pkt > in the up-state, and 2 pkts (FDI/BDI) in the down-state. I > simply don't > know where those who scream 'too complex' against this get it > from....I > suspect they have never read and/or understood it. > > So John, to return to your question. SDH and OTNs frame > structures have the > above concepts defined in them you will find and embody the > principles I > outlined....all I have done is do the same for MPLS. It's > got zero to do > with any control-plane (or management-plane) protocols for > very obvious (esp > here) reasons. > > In summary, I would say what we have proposed for MPLS OAM is > actually very > generic and not technology specific.....and so IMO is actually more > in-keeping with the spirit of CCAMPs as a title (ie > 'common'). However, I > can't take GTTP and say I can apply it to GMPLS......since its the > *principles* that are enduring, not trying to force one > specific technology > embodiment to fit all layers. > > And that's about it....Neil > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: 05 March 2002 19:40 > > To: 'neil.2.harrison@bt.com'; erosen@cisco.com > > Cc: ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > Neil, > > > > As a related question, would you please explain how your OAM > > proposal fits > > against GMPLS? > > > > Thanks, > > > > John Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 20:43:25 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E246@nimbus> From: John Drake To: "'neil.2.harrison@bt.com'" , erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 6 Mar 2002 20:39:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Neil, I asked a simple question and expected a simple answer. Instead, you send this example of incoherence raised to an arm form. Since you raised the specter of GMPLS, did you consider that we could just as easily take the fault detection/isolation procedures of GMPLS and re-apply them to MPLS? Thanks, John -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Tuesday, March 05, 2002 4:08 PM To: John Drake; erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 No problem John......really glad you asked this question as the answer is dead easy: The simple/one-liner answer is to ask you to read Y.1710.....I wrote this after a conversation Maartin Vissers and I had a few years ago (on a bus in Turin or somewhere) where we effectively said: - the network problems are effectively the same irrespective of the technology, ie find/route/connect/maintain - there are some differences dependent on transfer mode, ie cnls is different to co, and in co there are some differnces wrt to cct-sw vs pkt-sw....but in essence, the 'network' problems are invariant - and focusssing in the OAM aspects one can lay down some principles that are largely technology independent and quite generic....ergo Y.1710. However, assuming one has never read Y.1710 the arguments follow this general reasoning: - 1st define the defects specific to the layer network/technology of interest....now clearly these are different in specifics whether one is considering an OTN trail, a SDH VC-4 trail, an ATM VP trails or an MPLS LSP trail (etc)........but they all clearly embrace: * simple breaks within/below the layer of interest * swapped/misconfigured trails * mismerged trails (these can only happen with co pkt modes *and* relative addressing, ie labels....cnls pkts use *absolute* addressing, ie each pkt carries a trail-trace by definition (ie source address), which is a generic requirement as noted below and so complies). - 2nd, since we know the data-plane trails carrying the *traffic* can be totally decoupled from the data-plane trails carrying control (signalling/routing) or management plane protocols then each data-plane must have its own defect detection/handling mechanisms which are (i) not dependent on any other specific client/server layer networks (essential for technology compatibility/evolution....aka layer violations) and (ii) not dependent on any specific control/mananagent-plane protocols (or their data-plane), inc none, for similar reasons....very obvious in cct-sw/GMPLS applications IMO; - 3rd, given above, its obvious that the data-plane (be it carrying traffic/control/management protocols, which can be in orthogonal data-plane network embodiments please note) must carry its own OAM mechanisms.....again, very obvious in the case of cct-sw (esp OTN), but same applies to pkt-sw. Not so true in case of cnls.....where one can ask certain (higher level) control (say) plane protocols to proxy for data-plane OAM. The generic solution is here it to send some 'trail-trace' identifier periodically source/sink......this is exactly what is done in SDH VCs for example, and same should be done in pkt networks, ie same generic principle. And as I noted above, cnls protocols like IP carry a trail-trace (ie absolute source address) in each/every pkt since the addressing is absolute not relative (assuming globally unique addressing of course).....so IP also fits the model for this aspect. - 4th, then define the entry/exit criteria for each defect inc the consequent actions one needs for each....some obvious ones being: * let's not have multiple client layer alarm storms above the level of the defect (esp since these can be geograhically/organisationally disperse)...so we need some form of FDI (Forward Defect Indication) for this. So again this is a generic function, aka AIS in SDH/OTN. * some local alarm is needed....again pretty generic. * its useful to tell the source of far end failures in some cases (ie single-ended both-direction monitoring of QoS/availability SLAs say, or N:M prot-sw).....so this requires a generic BDI (Backward Derect Indication) of some kind that mirrors the FDI. * with swapped/mismerged connections traffic suppression is in order to protect the customer information integrity....again quite generic. - 5th, in CO networks (be they pkt or cct-sw) availabililty is the key perf metric. So we can define this based on defect persistence. QoS metric measurements only makes sense when in the 'available' state.....so if you want to offer/measure availability/QoS SLAs you need to pay attention to this point. BTW - In Y.1711 I have drawn out the near-end/far-end processing for LSPs wrt availability state to help people since this is the hard bit.....though the actual protocol is trivial, ie its only 1 keepalive/trail-trace (CV) pkt in the up-state, and 2 pkts (FDI/BDI) in the down-state. I simply don't know where those who scream 'too complex' against this get it from....I suspect they have never read and/or understood it. So John, to return to your question. SDH and OTNs frame structures have the above concepts defined in them you will find and embody the principles I outlined....all I have done is do the same for MPLS. It's got zero to do with any control-plane (or management-plane) protocols for very obvious (esp here) reasons. In summary, I would say what we have proposed for MPLS OAM is actually very generic and not technology specific.....and so IMO is actually more in-keeping with the spirit of CCAMPs as a title (ie 'common'). However, I can't take GTTP and say I can apply it to GMPLS......since its the *principles* that are enduring, not trying to force one specific technology embodiment to fit all layers. And that's about it....Neil > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 05 March 2002 19:40 > To: 'neil.2.harrison@bt.com'; erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Neil, > > As a related question, would you please explain how your OAM > proposal fits > against GMPLS? > > Thanks, > > John > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, March 05, 2002 11:32 AM > To: erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Eric...can you please explain how GMPLS fits against this > statement please? > > regards, Neil > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: 05 March 2002 14:52 > > To: Shahram Davari > > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > > Subject: Re: draft-bonica-tunneltrace-02 > > > > > > > > Shahram> What is the difference between ATM, FR, or any CO > > technology and > > Shahram> MPLS > > > > Well, for one thing, MPLS isn't a CO technology. It's got > > lots of stuff > > that doesn't really make sense from a CO perspective. Of > > course, when the > > CO guys run across these features (multipoint-to-point, > > php, liberal > > retention, independent mode, equal cost load balancing, > > dynamic rerouting > > with no signaling, ttl, lack of packet sequencing, IP > > control plane, etc., > > etc.) they assume that those features are there by mistake! > > > > This misconception that MPLS is a CO technology, shared > > as it is by the > > "pure IP" crowd and by the ITU/ATM crowd, is the source > > of much wasted > > time. > > > > MPLS is actually an IP-derived technology that facilitates > > the application > > of certain circuit-like characteristics to IP > > networks. As an IP > > technology, the usual IP diagnostic tools, such as ping > > and traceroute, > > should be applicable. That's what this whole useless > > discussion is about. > > One the one side are people who think that IP networks > > are inherently > > unmanageable (after all, they don't follow ITU standards), > > and on the other > > side are people who think that the IP-based paradigms are the best. > > > > It is true that MPLS can be used to provide something which > > is very like a > > CO network, but it doesn't have to be used this way, and > > usually isn't. > > Those of use who are not particularly interested in CO > > networks just don't > > want to be saddled with the legacy CO mechanisms. > > Presumably, if all these > > legacy CO mechanisms were so great there would not be such > > a great rush to > > IP. > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 15:23:49 -0800 Message-id: <00b001c1c562$444c4300$414632a6@wcomnet.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Date: Wed, 06 Mar 2002 16:57:16 -0600 From: John Fee Subject: FW: RE: SONET/SDH label agreement for IETF, ITU-T and OIF To: ccamp@ops.ietf.org Cc: yong.xue@wcom.com, curtis.brownmiller@wcom.com [ post by non-subscriber ] I vote #3. Regards, John Fee WCOM ---- -----Original Message----- From: Yong Xue [mailto:yong.xue@wcom.com] Sent: Wednesday, March 06, 2002 9:32 AM To: John.Fee@wcom.com; Curtis Brownmiller Cc: Yong Xue Subject: Fwd: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Take this and reply to 'ccamp-wg ' >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Tuesday, February 26, 2002 10:37 AM >To: ccamp-wg >Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > >CCAMP WG members, > >before we start down another many 100s of emails re-discussing >the same topic.... > >PLEASE express your support for one of the 3 options that Kireeti >posed to the WG. Don't elaborate... just help the WG chair(s) to >figure out the (rough) consensus of the WG. The choices formulated >by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > >Thanks >Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 15:17:59 -0800 Message-ID: <3C86A367.1060800@packetexchange.net> Date: Wed, 06 Mar 2002 23:16:55 +0000 From: Giles Heron Organization: PacketExchange Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 MIME-Version: 1.0 To: George Swallow CC: Shahram Davari , 'Scott Bradner' , ccamp@ops.ietf.org Subject: Re: MPLS OAM & the IETF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Swallow wrote: >>Could you please clarify option (1) a bit more? If this route is >>taken, still cooperation is needed between ITU and IETF. For example >>ITU may need MPLS signaling extensions. Also in some cases packet >>processing may need to be aligned between ITU and IETF in order to >>avoid conflicts. For example ITU may consider an MPLS path-trace that >>uses TTL expiration, which requires a TTL expired MPLS packet to be >>forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL >>expired packets to ICMP/GTTP module. There needs to be a coordination >>between IETF and ITU in order to find a common method which could >>determine whether a packet should be forwarded to OAM or ICMP/GTTP >>module. >> > > It's precisely issues such as these that lead me to believe that it > would be best if *only one* standards body owns a core technology. > Certainly other bodies should be free to create applications, define > extentions, and do implementation agreements. But when it come to > something a central as the basic forwarding plane, one group alone > should handle it. > > Allowing another body to redifine core functions WILL lead to > interoperability problems. Agreed. I'm not sure which of Scott's options this corresponds to, though! I don't want to see the IETF working on MPLS OAM as per option 2, but option 1 seems to be a step down the road of allowing the ITU to "co-own" MPLS? Giles > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 13:26:20 -0800 Message-ID: <3C8682B4.23D622CA@bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 06 Mar 2002 15:57:24 -0500 From: Igor Faynberg To: Scott Bradner , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Scott Bradner wrote: [ post by non-subscriber ] > So - please indicate your opinion on how the IETF should proceed > > 1 - split the tasks between the IETF and the ITU-T > 2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T I would support option 1 (although it is not necessarily in conflict with option 2a in that it will involve working with the ITU-T to produce common technology, in my opinion). Thanks to Scott for the precise summary of the issues! Igor Faynberg Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 10:42:19 -0800 Message-Id: <200203061840.NAA07871@telescope.cisco.com> To: neil.2.harrison@bt.com cc: pingpan@juniper.net, ecuevas@att.com, tnadeau@cisco.com, ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: draft-bonica-tunneltrace-02 Date: Wed, 06 Mar 2002 13:40:36 -0500 From: George Swallow Neil - > Thanks Ping.....nice to see a positive response from a specific manufacturer > to our concerns as operators on this. This is a really good positive step > IMO. Its a shame other manufacturers have discounted Y.1710, as what Enrique Unlike the ITU, members of the IETF act as individuals. It is inappropriate to generalize the remarks of one person to an entire company. Further I believe that Tom was confused between Y.1710 and Y.1711. Y.1710 is a reasonable document. Mostly great stuff that any vendor wanting to sell to carriers should take very seriously. As do I. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 09:53:32 -0800 Date: Wed, 6 Mar 2002 12:52:55 -0500 (EST) From: Scott Bradner Message-Id: <200203061752.g26Hqt408319@newdev.harvard.edu> To: ccamp@ops.ietf.org, Shahram_Davari@pmc-sierra.com, sob@harvard.edu Subject: RE: MPLS OAM & the IETF > Are these kind of cooperations considered in option 1? please advise ---- >From Shahram_Davari@pmc-sierra.com Wed Mar 6 11:35:12 2002 From: Shahram Davari To: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Wed, 6 Mar 2002 08:34:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Scott, Could you please clarify option (1) a bit more? If this route is taken, still cooperation is needed between ITU and IETF. For example ITU may need MPLS signaling extensions. Also in some cases packet processing may need to be aligned between ITU and IETF in order to avoid conflicts. For example ITU may consider an MPLS path-trace that uses TTL expiration, which requires a TTL expired MPLS packet to be forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL expired packets to ICMP/GTTP module. There needs to be a coordination between IETF and ITU in order to find a common method which could determine whether a packet should be forwarded to OAM or ICMP/GTTP module. Are these kind of cooperations considered in option 1? Shahram > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Wednesday, March 06, 2002 10:34 AM > To: ccamp@ops.ietf.org > Subject: MPLS OAM & the IETF > > > subject: MPLS OAM & the IETF > > The result of the MPLS OAM BOF in Salt Lake City has been > confirmed over > the last few days in the mailing list thread > "draft-bonica-tunneltrace-02." > > > That result was and is that there are at least two quite > different views on > the type of OAM tools and technologies needed for MPLS networks. > > My reading of the groups is that one group, who are mostly > concerned with > the transport of IP over MPLS, generally feel that tools > approximating the > traditional "ping" and "traceroute" tools used on IP networks are > sufficient. A second group seems to feel that those tools do > not provide > enough of a view of the service a customer is getting to be > sufficient and > that tools approximating traditional telephone system OAM > tools are needed > to get the complete picture. > > Meanwhile, the ITU-T has been working in this area and has a > document in > their equivalent of the IETF Last-Call. Brian Moore, the > ITU-T Study Group > 13 chair, kindly arraigned for the ITU-T document (known as > Y.1711) to be > put on an ftp site so interested IETF folk can take a look at > what they > have done. The URL is > http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht ml (IETF folk have to register to use the FTP site.) It seems to me that there are two options on what we (the IETF) could do at this point. 0/ you think I do not understand the issue 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and cede to the ITU-T work on the more telco-like OAM. In this option the IETF would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an MPLS reserved label value for use by the ITU-T to identify Y.1711 information. 2/ The IETF work on a suite of technologies ranging from the ping/traceroute-like mechanisms to the more telephone system OAM ones. The IETF could try to figure out how to do this in conjunction with the ITU, though it is a bit late for that considering the state of Y.1711, or be in competition with the ITU-T. So - please indicate your opinion on how the IETF should proceed 1 - split the tasks between the IETF and the ITU-T 2 - IETF produce standards track documents covering both areas 2a - trying to work with the ITU-T to produce common technology 2b - in competition with the ITU-T In any case, it would be good to provide feedback to the ITU-T on Y.1711 if you see anything that looks broken. Scott (with sub-ip AD hat on) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 09:38:49 -0800 Message-Id: <200203061737.MAA20978@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-02.txt Date: Wed, 06 Mar 2002 12:37:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-architecture-02.txt Pages : 56 Date : 05-Mar-02 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-architecture-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134030.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 09:26:54 -0800 Message-Id: <200203061725.MAA12808@telescope.cisco.com> To: Shahram Davari cc: "'Scott Bradner'" , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: MPLS OAM & the IETF Date: Wed, 06 Mar 2002 12:25:49 -0500 From: George Swallow > Could you please clarify option (1) a bit more? If this route is > taken, still cooperation is needed between ITU and IETF. For example > ITU may need MPLS signaling extensions. Also in some cases packet > processing may need to be aligned between ITU and IETF in order to > avoid conflicts. For example ITU may consider an MPLS path-trace that > uses TTL expiration, which requires a TTL expired MPLS packet to be > forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL > expired packets to ICMP/GTTP module. There needs to be a coordination > between IETF and ITU in order to find a common method which could > determine whether a packet should be forwarded to OAM or ICMP/GTTP > module. It's precisely issues such as these that lead me to believe that it would be best if *only one* standards body owns a core technology. Certainly other bodies should be free to create applications, define extentions, and do implementation agreements. But when it come to something a central as the basic forwarding plane, one group alone should handle it. Allowing another body to redifine core functions WILL lead to interoperability problems. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 08:36:03 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5F4@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: MPLS OAM & the IETF Date: Wed, 6 Mar 2002 08:34:58 -0800 MIME-Version: 1.0 Content-Type: text/plain Scott, Could you please clarify option (1) a bit more? If this route is taken, still cooperation is needed between ITU and IETF. For example ITU may need MPLS signaling extensions. Also in some cases packet processing may need to be aligned between ITU and IETF in order to avoid conflicts. For example ITU may consider an MPLS path-trace that uses TTL expiration, which requires a TTL expired MPLS packet to be forwarded to MPLS OAM module, while GTTP considers sending MPLS TTL expired packets to ICMP/GTTP module. There needs to be a coordination between IETF and ITU in order to find a common method which could determine whether a packet should be forwarded to OAM or ICMP/GTTP module. Are these kind of cooperations considered in option 1? Shahram > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Wednesday, March 06, 2002 10:34 AM > To: ccamp@ops.ietf.org > Subject: MPLS OAM & the IETF > > > subject: MPLS OAM & the IETF > > The result of the MPLS OAM BOF in Salt Lake City has been > confirmed over > the last few days in the mailing list thread > "draft-bonica-tunneltrace-02." > > > That result was and is that there are at least two quite > different views on > the type of OAM tools and technologies needed for MPLS networks. > > My reading of the groups is that one group, who are mostly > concerned with > the transport of IP over MPLS, generally feel that tools > approximating the > traditional "ping" and "traceroute" tools used on IP networks are > sufficient. A second group seems to feel that those tools do > not provide > enough of a view of the service a customer is getting to be > sufficient and > that tools approximating traditional telephone system OAM > tools are needed > to get the complete picture. > > Meanwhile, the ITU-T has been working in this area and has a > document in > their equivalent of the IETF Last-Call. Brian Moore, the > ITU-T Study Group > 13 chair, kindly arraigned for the ITU-T document (known as > Y.1711) to be > put on an ftp site so interested IETF folk can take a look at > what they > have done. The URL is > http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.ht ml (IETF folk have to register to use the FTP site.) It seems to me that there are two options on what we (the IETF) could do at this point. 0/ you think I do not understand the issue 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and cede to the ITU-T work on the more telco-like OAM. In this option the IETF would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an MPLS reserved label value for use by the ITU-T to identify Y.1711 information. 2/ The IETF work on a suite of technologies ranging from the ping/traceroute-like mechanisms to the more telephone system OAM ones. The IETF could try to figure out how to do this in conjunction with the ITU, though it is a bit late for that considering the state of Y.1711, or be in competition with the ITU-T. So - please indicate your opinion on how the IETF should proceed 1 - split the tasks between the IETF and the ITU-T 2 - IETF produce standards track documents covering both areas 2a - trying to work with the ITU-T to produce common technology 2b - in competition with the ITU-T In any case, it would be good to provide feedback to the ITU-T on Y.1711 if you see anything that looks broken. Scott (with sub-ip AD hat on) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 08:09:41 -0800 From: ananth.nagarajan@mail.sprint.com Date: Wed, 6 Mar 2002 10:07:42 -0600 Message-Id: Subject: RE: MPLS OAM & the IETF MIME-Version: 1.0 TO: ccamp@ops.ietf.org, sob@harvard.edu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 6 Mar 2002 10:07:41 -0600" Content-Transfer-Encoding: 7bit 2a is ideal. If that doesn't work (for several reasons :-) ), 1 is acceptable. Ananth [snip] >1 - split the tasks between the IETF and the ITU-T >2 - IETF produce standards track documents covering both areas > 2a - trying to work with the ITU-T to produce common technology > 2b - in competition with the ITU-T Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 07:59:50 -0800 Message-Id: <4.3.2.7.2.20020306104810.01ea76e0@161.44.167.72> Date: Wed, 06 Mar 2002 10:58:52 -0500 To: "David Allan" From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: Shahram Davari , "'Ron Bonica'" , erosen@cisco.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Tom & co... > >I have to admit I am not finding some of these arguments to be >consistent...... > >If traceroute is an excellent example of a protocol that works, why not >simply re-use it. Genericize Ron's proposal for MPLS extensions to ICMP >and you're done. No more justification or requirements required. > >If the intent is to fix shortcomings with traceroute by inventing a new >protocol, then all bets should be off, because you are saying the working >example of a good solution is broken or lacking in some way. And the >requirements document should cover in detail the problems to be solved (or >re-solved as the case may be e.g. broadcast filtering etc.). In this >regard I would consider the requirements document to be seriously lacking. > >Now process wise, if the intent is to have the cart before the horse (or >it is that way accidentally or for some historical reasons), why are not >the requirements and the solution proposed as WG documents >simultaneously?...they are joined at the hip anyway. If the actual binding >is not so simple, then the specific dependencies between the two should be >eliminated before this is a genuine "work item". I think that this thread has made it clear that Ron's requirements document should be a WG document in either case, since there is a clear need to capture these requirements in an IETF document, regardless of whether you agree with the current working of the requirements. If you do not, then we should (and have) discuss changing them. As a WG document we can work towards constructively specifying the requirements so that we can make solutions work for the working group. The GTTP document proposes one solution to the requirements in the document. If you think you have a better solution, feel free to post a draft with the details. 8) --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 07:42:31 -0800 Message-Id: <200203061542.KAA21755@telescope.cisco.com> To: Giles Heron cc: David Allan , erosen@cisco.com, Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Well off the original thread topic... draft-bonica-tunneltrace-02 Date: Wed, 06 Mar 2002 10:42:10 -0500 From: George Swallow > > > 2) MPLS VPN (RFC2547). I won't go into the pros and cons of > > > this right > > > now ;-) > > > > Current implementation is MPLS but I don't think there is a sustainable > > dependency there...LDP permits the undelying MPLS network to behave like > > an IP network. Seems to me they should be interchangable. > > > they are - the above issues notwithstanding. Which is a very good argument at to why IP based OAM tools are a good idea. Maybe even a *requirement*. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 07:38:41 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD340215CEE8@zcard0ka.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" , Shahram Davari Cc: "'Ron Bonica'" , erosen@cisco.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 6 Mar 2002 10:38:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C524.EEC46F30" 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_01C1C524.EEC46F30 Content-Type: text/plain; charset="iso-8859-1" Tom & co... I have to admit I am not finding some of these arguments to be consistent...... If traceroute is an excellent example of a protocol that works, why not simply re-use it. Genericize Ron's proposal for MPLS extensions to ICMP and you're done. No more justification or requirements required. If the intent is to fix shortcomings with traceroute by inventing a new protocol, then all bets should be off, because you are saying the working example of a good solution is broken or lacking in some way. And the requirements document should cover in detail the problems to be solved (or re-solved as the case may be e.g. broadcast filtering etc.). In this regard I would consider the requirements document to be seriously lacking. Now process wise, if the intent is to have the cart before the horse (or it is that way accidentally or for some historical reasons), why are not the requirements and the solution proposed as WG documents simultaneously?...they are joined at the hip anyway. If the actual binding is not so simple, then the specific dependencies between the two should be eliminated before this is a genuine "work item". my last two cents Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, March 05, 2002 3:56 PM > To: Shahram Davari > Cc: 'Ron Bonica'; erosen@cisco.com; Allan, David [CAR:NS00:EXCH]; > ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > At 12:25 PM 3/5/2002 -0800, Shahram Davari wrote: > >Ron, > > > > > We should not be surprised that > > > the enhanced > > > route tracing application resembles the current "traceroute" > > > in that a) it > > > is based upon probes and responses, b) UDP carries its PDUs, > > > and c) it is > > > stateless. > > > > > > >I am not surprised at all. What you are suggesting is > >your desire to resemble the IP traceroute. But this is only > >a desire and there is no technical reason why it should or it > >should not resemble the IP traceroute. > > Sure there is; IP traceroute works. This is one of > the best reasons > in my mind. > > --Tom > > > >A requirements document should leave the door open for other > >innovative ideas, unless you can prove that the traceroute-like > >mechanism is the BEST. > > > >-Shahram > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > ------_=_NextPart_001_01C1C524.EEC46F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

Tom & co...

I have to admit I am not finding some of these = arguments to be consistent......

If traceroute is an excellent example of a protocol = that works, why not simply re-use it. Genericize Ron's proposal for = MPLS extensions to ICMP and you're done. No more justification or = requirements required.

If the intent is to fix shortcomings with traceroute = by inventing a new protocol, then all bets should be off, because you = are saying the working example of a good solution is broken or lacking = in some way. And the requirements document should cover in detail the = problems to be solved (or re-solved as the case may be e.g. broadcast = filtering etc.). In this regard I would consider the requirements = document to be seriously lacking.

Now process wise, if the intent is to have the cart = before the horse (or it is that way accidentally or for some historical = reasons), why are not the requirements and the solution proposed as WG = documents simultaneously?...they are joined at the hip anyway. If the = actual binding is not so simple, then the specific dependencies between = the two should be eliminated before this is a genuine "work = item".

my last two cents
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, March 05, 2002 3:56 PM
> To: Shahram Davari
> Cc: 'Ron Bonica'; erosen@cisco.com; Allan, = David [CAR:NS00:EXCH];
> ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> At 12:25 PM 3/5/2002 -0800, Shahram Davari = wrote:
> >Ron,
> >
> > > We should not be surprised = that
> > > the enhanced
> > > route tracing application resembles = the current "traceroute"
> > > in that a) it
> > > is based upon probes and responses, = b) UDP carries its PDUs,
> > > and c) it is
> > > stateless.
> > >
> >
> >I am not surprised at all. What you are = suggesting is
> >your desire to resemble the IP traceroute. = But this is only
> >a desire and there is no technical reason = why it should or it
> >should not resemble the IP = traceroute.
>
>          = Sure there is; IP traceroute works.  This is one of
> the best reasons
> in my mind.
>
>          = --Tom
>
>
> >A requirements document should leave the = door open for other
> >innovative ideas, unless you can prove that = the traceroute-like
> >mechanism is the BEST.
> >
> >-Shahram
>
>
>
> = --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our = time.
>
>

------_=_NextPart_001_01C1C524.EEC46F30-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 07:38:12 -0800 Date: Wed, 6 Mar 2002 10:33:52 -0500 (EST) From: Scott Bradner Message-Id: <200203061533.g26FXq607136@newdev.harvard.edu> To: ccamp@ops.ietf.org Subject: MPLS OAM & the IETF subject: MPLS OAM & the IETF The result of the MPLS OAM BOF in Salt Lake City has been confirmed over the last few days in the mailing list thread "draft-bonica-tunneltrace-02." That result was and is that there are at least two quite different views on the type of OAM tools and technologies needed for MPLS networks. My reading of the groups is that one group, who are mostly concerned with the transport of IP over MPLS, generally feel that tools approximating the traditional "ping" and "traceroute" tools used on IP networks are sufficient. A second group seems to feel that those tools do not provide enough of a view of the service a customer is getting to be sufficient and that tools approximating traditional telephone system OAM tools are needed to get the complete picture. Meanwhile, the ITU-T has been working in this area and has a document in their equivalent of the IETF Last-Call. Brian Moore, the ITU-T Study Group 13 chair, kindly arraigned for the ITU-T document (known as Y.1711) to be put on an ftp site so interested IETF folk can take a look at what they have done. The URL is http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html (IETF folk have to register to use the FTP site.) It seems to me that there are two options on what we (the IETF) could do at this point. 0/ you think I do not understand the issue 1/ split the tasks: The IETF focus on the ping/traceroute mechanisms and cede to the ITU-T work on the more telco-like OAM. In this option the IETF would publish draft-ohta-mpls-label-value-01.txt as an RFC and assign an MPLS reserved label value for use by the ITU-T to identify Y.1711 information. 2/ The IETF work on a suite of technologies ranging from the ping/traceroute-like mechanisms to the more telephone system OAM ones. The IETF could try to figure out how to do this in conjunction with the ITU, though it is a bit late for that considering the state of Y.1711, or be in competition with the ITU-T. So - please indicate your opinion on how the IETF should proceed 1 - split the tasks between the IETF and the ITU-T 2 - IETF produce standards track documents covering both areas 2a - trying to work with the ITU-T to produce common technology 2b - in competition with the ITU-T In any case, it would be good to provide feedback to the ITU-T on Y.1711 if you see anything that looks broken. Scott (with sub-ip AD hat on) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 04:58:10 -0800 Message-ID: From: "Mannie, Eric" To: ccamp@ops.ietf.org Subject: Re-published SDH/SONET drafts Date: Wed, 6 Mar 2002 13:55:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear All, FYI, I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-03.txt I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt The two SDH/SONET drafts have been re-published as they were sent in December on the CCAMP mailing list in agreement with the WG chairs (i.e. before the discussion that just occurred on the CCAMP mailing list). They were published to have a common basis for discussion, to reflect the changes that were requested during the last IETF, and simply to be available in the directory of internet-drafts. Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 03:19:45 -0800 Message-Id: <200203061119.GAA01223@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-02.txt Date: Wed, 06 Mar 2002 06:19:07 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-architecture-02.txt Pages : 56 Date : 05-Mar-02 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-architecture-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134030.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 03:19:40 -0800 Message-Id: <200203061119.GAA01211@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-sonet-sdh-extensions-01.txt Date: Wed, 06 Mar 2002 06:19:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Extensions to Control Non-Standard SONET and SDH Features Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt Pages : 12 Date : 05-Mar-02 This document is a companion to the GMPLS signaling extensions to control SONET and SDH document [GMPLS-SONET-SDH] that defines the SONET/SDH technology specific information needed when using GMPLS signaling. This informational document defines GMPLS signaling extensions to control three optional non-standard (i.e. proprietary) SONET and SDH features: arbitrary concatenation, per byte transparency and the virtual concatenation of contiguously concatenated signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-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-gmpls-sonet-sdh-extensions-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-gmpls-sonet-sdh-extensions-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: <20020305134017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134017.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 03:19:37 -0800 Message-Id: <200203061118.GAA01199@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-sonet-sdh-03.txt Date: Wed, 06 Mar 2002 06:18:58 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Extensions for SONET and SDH Control Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-ccamp-gmpls-sonet-sdh-03.txt Pages : 19 Date : 05-Mar-02 This document is a companion to the Generalized MPLS signaling documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines the SONET/SDH technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-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-sonet-sdh-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-sonet-sdh-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: <20020305134002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134002.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Mar 2002 03:00:29 -0800 Message-ID: From: Sasha Vainshtein To: 'Scott Bradner' , loa.andersson@utfors.se, mlazer@att.com Cc: afferton@att.com, bwijnen@lucent.com, ccamp@ops.ietf.org, dbrungard@att.com, gash@att.com, yakov@juniper.net Subject: RE: WG document status Date: Wed, 6 Mar 2002 12:49:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Scott, Thank you for clarification. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Tuesday, March 05, 2002 6:23 PM > To: loa.andersson@utfors.se; mlazer@att.com; Sasha@AXERRA.com > Cc: afferton@att.com; bwijnen@lucent.com; ccamp@ops.ietf.org; > dbrungard@att.com; gash@att.com; yakov@juniper.net > Subject: RE: WG document status > > > > Does not RFC 2026 overrule the previous requirements, > > the pp in 2026 you note gives the IESG (backing up a AD for example) > flexibility to support the type of thing that the routing AD did > > from 2026 sec 4.1.1 > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > Scott > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 16:22:59 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: AdSpec Object usage in GMPLS Date: Tue, 05 Mar 2002 15:43:31 -0700 [ post by non-subscriber ] Hi All, Can someone please explain the usage of AdSpec object in establishment of LSC/FSC/TDM LSP in GMPLS-RSVP-TE ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 16:08:13 -0800 Message-ID: From: neil.2.harrison@bt.com To: jdrake@calient.net, erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 6 Mar 2002 00:07:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" No problem John......really glad you asked this question as the answer is dead easy: The simple/one-liner answer is to ask you to read Y.1710.....I wrote this after a conversation Maartin Vissers and I had a few years ago (on a bus in Turin or somewhere) where we effectively said: - the network problems are effectively the same irrespective of the technology, ie find/route/connect/maintain - there are some differences dependent on transfer mode, ie cnls is different to co, and in co there are some differnces wrt to cct-sw vs pkt-sw....but in essence, the 'network' problems are invariant - and focusssing in the OAM aspects one can lay down some principles that are largely technology independent and quite generic....ergo Y.1710. However, assuming one has never read Y.1710 the arguments follow this general reasoning: - 1st define the defects specific to the layer network/technology of interest....now clearly these are different in specifics whether one is considering an OTN trail, a SDH VC-4 trail, an ATM VP trails or an MPLS LSP trail (etc)........but they all clearly embrace: * simple breaks within/below the layer of interest * swapped/misconfigured trails * mismerged trails (these can only happen with co pkt modes *and* relative addressing, ie labels....cnls pkts use *absolute* addressing, ie each pkt carries a trail-trace by definition (ie source address), which is a generic requirement as noted below and so complies). - 2nd, since we know the data-plane trails carrying the *traffic* can be totally decoupled from the data-plane trails carrying control (signalling/routing) or management plane protocols then each data-plane must have its own defect detection/handling mechanisms which are (i) not dependent on any other specific client/server layer networks (essential for technology compatibility/evolution....aka layer violations) and (ii) not dependent on any specific control/mananagent-plane protocols (or their data-plane), inc none, for similar reasons....very obvious in cct-sw/GMPLS applications IMO; - 3rd, given above, its obvious that the data-plane (be it carrying traffic/control/management protocols, which can be in orthogonal data-plane network embodiments please note) must carry its own OAM mechanisms.....again, very obvious in the case of cct-sw (esp OTN), but same applies to pkt-sw. Not so true in case of cnls.....where one can ask certain (higher level) control (say) plane protocols to proxy for data-plane OAM. The generic solution is here it to send some 'trail-trace' identifier periodically source/sink......this is exactly what is done in SDH VCs for example, and same should be done in pkt networks, ie same generic principle. And as I noted above, cnls protocols like IP carry a trail-trace (ie absolute source address) in each/every pkt since the addressing is absolute not relative (assuming globally unique addressing of course).....so IP also fits the model for this aspect. - 4th, then define the entry/exit criteria for each defect inc the consequent actions one needs for each....some obvious ones being: * let's not have multiple client layer alarm storms above the level of the defect (esp since these can be geograhically/organisationally disperse)...so we need some form of FDI (Forward Defect Indication) for this. So again this is a generic function, aka AIS in SDH/OTN. * some local alarm is needed....again pretty generic. * its useful to tell the source of far end failures in some cases (ie single-ended both-direction monitoring of QoS/availability SLAs say, or N:M prot-sw).....so this requires a generic BDI (Backward Derect Indication) of some kind that mirrors the FDI. * with swapped/mismerged connections traffic suppression is in order to protect the customer information integrity....again quite generic. - 5th, in CO networks (be they pkt or cct-sw) availabililty is the key perf metric. So we can define this based on defect persistence. QoS metric measurements only makes sense when in the 'available' state.....so if you want to offer/measure availability/QoS SLAs you need to pay attention to this point. BTW - In Y.1711 I have drawn out the near-end/far-end processing for LSPs wrt availability state to help people since this is the hard bit.....though the actual protocol is trivial, ie its only 1 keepalive/trail-trace (CV) pkt in the up-state, and 2 pkts (FDI/BDI) in the down-state. I simply don't know where those who scream 'too complex' against this get it from....I suspect they have never read and/or understood it. So John, to return to your question. SDH and OTNs frame structures have the above concepts defined in them you will find and embody the principles I outlined....all I have done is do the same for MPLS. It's got zero to do with any control-plane (or management-plane) protocols for very obvious (esp here) reasons. In summary, I would say what we have proposed for MPLS OAM is actually very generic and not technology specific.....and so IMO is actually more in-keeping with the spirit of CCAMPs as a title (ie 'common'). However, I can't take GTTP and say I can apply it to GMPLS......since its the *principles* that are enduring, not trying to force one specific technology embodiment to fit all layers. And that's about it....Neil > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 05 March 2002 19:40 > To: 'neil.2.harrison@bt.com'; erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Neil, > > As a related question, would you please explain how your OAM > proposal fits > against GMPLS? > > Thanks, > > John > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, March 05, 2002 11:32 AM > To: erosen@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Eric...can you please explain how GMPLS fits against this > statement please? > > regards, Neil > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: 05 March 2002 14:52 > > To: Shahram Davari > > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > > Subject: Re: draft-bonica-tunneltrace-02 > > > > > > > > Shahram> What is the difference between ATM, FR, or any CO > > technology and > > Shahram> MPLS > > > > Well, for one thing, MPLS isn't a CO technology. It's got > > lots of stuff > > that doesn't really make sense from a CO perspective. Of > > course, when the > > CO guys run across these features (multipoint-to-point, > > php, liberal > > retention, independent mode, equal cost load balancing, > > dynamic rerouting > > with no signaling, ttl, lack of packet sequencing, IP > > control plane, etc., > > etc.) they assume that those features are there by mistake! > > > > This misconception that MPLS is a CO technology, shared > > as it is by the > > "pure IP" crowd and by the ITU/ATM crowd, is the source > > of much wasted > > time. > > > > MPLS is actually an IP-derived technology that facilitates > > the application > > of certain circuit-like characteristics to IP > > networks. As an IP > > technology, the usual IP diagnostic tools, such as ping > > and traceroute, > > should be applicable. That's what this whole useless > > discussion is about. > > One the one side are people who think that IP networks > > are inherently > > unmanageable (after all, they don't follow ITU standards), > > and on the other > > side are people who think that the IP-based paradigms are the best. > > > > It is true that MPLS can be used to provide something which > > is very like a > > CO network, but it doesn't have to be used this way, and > > usually isn't. > > Those of use who are not particularly interested in CO > > networks just don't > > want to be saddled with the legacy CO mechanisms. > > Presumably, if all these > > legacy CO mechanisms were so great there would not be such > > a great rush to > > IP. > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 16:08:10 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 6 Mar 2002 00:07:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" So do mine. Ours are documented in Y.1710 where are your documented? regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 05 March 2002 19:42 > To: neil.2.harrison > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > >Tom...I suspect Enrique is saying this because that is the > only place he is > >aware that they are written down and, since this is from the ITU, by > >definition must have operator agreement. Can you please > provide us with a > >reference to the requirements documents that you are working to? > > My requirements come from my customers' operational > departments. > > --Tom > > > > >thanks & regards, Neil > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: 05 March 2002 17:01 > > > To: Cuevas, Enrique G, ALASO > > > Cc: David Allan; Shahram Davari; ccamp > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > Why are we still discussing Y.1710? I thought that this > > > was the IETF. The following seem to comply with the operational > > > OAM requirements I am hearing from operators. > > > > > > LSP "ping", > > > LSP Traceroute > > > MIBs > > > > > > Others may be required. > > > > > > --Tom > > > > > > > > > >Could you provide us with a matrix (comply/does not comply) > > > of the tools > > > >you are > > > >talking about vs. the requirements given in Y.1710? > > > > > > > >Enrique > > > >_______________ > > > >ecuevas@att.com > > > >Tel. (732)-420-3252 > > > > > > > > > > > > >-----Original Message----- > > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > >Sent: Tuesday, March 05, 2002 9:07 AM > > > > >To: David Allan > > > > >Cc: Shahram Davari; ccamp@ops.ietf.org > > > > >Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > > > > > > > > > > > > > >>Your statement that requirements support the tools/mechanisms > > > > >that work > > > > >>today is the nib of my concern. Basically the > requirments step is > > > > >>redundant at that point. We are now in a tight > embrace where the > > > > >>requirements justify the solution and the solution > dictates the > > > > >>requirements. Suggesting the requirements is a WG work item > > > > >would appear > > > > >>to be an oxymoron. > > > > > > > > > > As I mentioned, some of the tools have > already been worked > > > > >out, so yes, the cart is before the horse in some > cases. However, > > > > >I don't think that this is necessarily a problem. > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > >>Dave > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: Thomas D. Nadeau > > > > >> [mailto:tnadeau@cisco.com] > > > > >> > Sent: Monday, March 04, 2002 5:47 PM > > > > >> > To: Shahram Davari > > > > >> > Cc: ccamp@ops.ietf.org > > > > >> > Subject: RE: draft-bonica-tunneltrace-02 > > > > >> > > > > > >> > > > > > >> > > > > > >> > >Thanks for your positive response. With regards to the > > > > >> > protocol requirements, > > > > >> > >which ones do you think MUST be there and why? > > > > >> > > > > > >> > I think that the protocol requirements for those > > > > >> > solutions that > > > > >> > currently > > > > >> > exist should be in there. I understand your point about > > > > >> > reverse engineering the tools, but unfortunately the > > > > >> > requirement writing effort > > > > >> > started after we had some solutions working. Therefore > > > > >> > protocol requirements > > > > >> > do matter because they support the > tools/mechanisms that work > > > > >> > today. No > > > > >> > need to obviate those things at this point. > > > > >> > > > > > >> > >In my view protocol requirements should not unnecessarily > > > > >> > restrict the > > > > >> > >solution, > > > > >> > >unless they violate application requirements. > > > > >> > > > > > >> > I think that protocol requirements should > be in line > > > > >> > with the > > > > >> > application > > > > >> > requirements that have come from operational folks > working at > > > > >> > SPs. However, > > > > >> > application requirements should fit within > existing protocols > > > > >> > as much as > > > > >> > possible (to promote reuse of existing software/tools). > > > > >We should not > > > > >> > be forced to reinvent the wheel just for the sake > of doing so. > > > > >> > > > > > >> > --Tom > > > > >> > > > > > >> > > > > > >> > > > > > >> > >-Shahram > > > > >> > > > > > > >> > > > -----Original Message----- > > > > >> > > > From: Thomas D. Nadeau > > > > >> [mailto:tnadeau@cisco.com] > > > > >> > > > Sent: Monday, March 04, 2002 4:25 PM > > > > >> > > > To: Shahram Davari > > > > >> > > > Cc: ccamp@ops.ietf.org > > > > >> > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > >I think instead of debating whether Y.1711 is > better than > > > > >> > > > LSP-ping/GTTP or > > > > >> > > > >vice versa, it would be more > > > > >> > > > >constructive to identify and document the > applicability of > > > > >> > > > each proposal > > > > >> > > > >for various tunneling applications. > > > > >> > > > > > > > >> > > > This sounds like a move in the right > direction. > > > > >> > > > > > > > >> > > > >For this particular draft my suggestion at > this stage is > > > > >> > > > that the Bonica's > > > > >> > > > >requirement draft be revised to: > > > > >> > > > > > > > > >> > > > >1) Add text (or at least a place holder) for > additional > > > > >> > > > security issues > > > > >> > > > >raised on the list. > > > > >> > > > >2) Add backward compatibility, simplicity and > > > scalability as > > > > >> > > > requirements. > > > > >> > > > > > > > >> > > > I can go along with those. > > > > >> > > > > > > > >> > > > >3) Remove the protocol requirements section, since any > > > > >> > > > requirement here > > > > >> > > > >will be viewed as a reverse engineering of > some solution. > > > > >> > > > > > > > >> > > > Although this might sound reasonable > to some, I > > > > >> > > > think that some > > > > >> > > > may object to this > > > > >> > > > since the protocol requirements are viewed by some as > > > > >> > > > fundamental to the > > > > >> > > > requirements > > > > >> > > > of any particular solution. In the flurry of > emails on the > > > > >> > > > topic, I have > > > > >> > > > not been able to > > > > >> > > > keep track of what the consensus on this might > be (either > > > > >> > > > way). Perhaps Ron > > > > >> > > > has been keeping > > > > >> > > > track? > > > > >> > > > > > > > >> > > > >Then any offered solution should have text to > show to what > > > > >> > > > extent they > > > > >> > > > >fulfill the > > > > >> > > > >requirements, and what is their applicability and > > > > >restrictions. > > > > >> > > > > > > > >> > > > Sounds reasonable. > > > > >> > > > > > > > >> > > > --Tom > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > -------------------------------------------------------------- > > > > >> > > > ---------- > > > > >> > > > Mathematics is the supreme nostalgia of our time. > > > > >> > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > -------------------------------------------------------------- > > > > >> > ---------- > > > > >> > Mathematics is the supreme nostalgia of our time. > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > >--------------------------------------------------------------- > > > > >--------- > > > > >Mathematics is the supreme nostalgia of our time. > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > Mathematics is the supreme nostalgia of our time. > > > > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 16:02:41 -0800 Message-ID: From: "Karmakar, Soumen" To: ccamp@ops.ietf.org Subject: Adspec object in Path (GMPLS) Date: Tue, 5 Mar 2002 16:02:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi All, Is the inclusion of AdSpec object allowed in GMPLS RSVP-TE Path message for establishing the LSC/FSC/TDM LSP ? If yes then what is the usage of this one ? Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 15:58:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: AdSpec Object in GMPLS Date: Tue, 05 Mar 2002 11:43:27 -0700 [ post by non-subscriber ] Hi All, Does GMPLS extensions to RSVP-TE support AdSpec Object ? If yes then what is its usage in GMPLS ? Regards, manoj. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 15:32:40 -0800 Message-ID: <39469E08BD83D411A3D900204840EC55763041@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Yakov Rekhter'" , ccamp@ops.ietf.org Subject: RE: Unnumbered support with ISIS - using exiting TLV Date: Tue, 5 Mar 2002 18:31:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Yakov: -> To support unnumbered links the current GMPLS ISIS routing spec -> defines new TLV, Link Identifier, to be carried in ISIS Hellos. It -> was pointed out that ISIS already has an existing mechanism to -> exchange link identifiers - see draft-ietf-isis-3way-05.txt. So, -> unless there are specific technical objections, I would suggest we -> replace Link Identifier TLV with the mechanism described in -> draft-ietf-isis-3way-05.txt AFAIK, ISIS 3-Way handshake is optional and It is fully interoperable with systems that do not support the extension. I think we are making a dependency here - ISIS Unnumbered extensions (for (G)MPLS-TE purpose and not for normal hop-by-hop routing) will be supported only with 3-way handshake extensions. If that is not a big problem, I completely agree with your proposal. Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 15:14:22 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5F2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Gray'" Cc: "'Ron Bonica'" , erosen@cisco.com, David Allan , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 15:13:52 -0800 MIME-Version: 1.0 Content-Type: text/plain Eric, I think it all depends on the meaning of requirement. Here is the Webster dictionary meaning of requirements: "something essential to the existence or occurrence of something else" Based on this definition could you please explain why it is essential to have a solution that looks a certain way? -Shahram > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Tuesday, March 05, 2002 5:06 PM > To: Shahram Davari > Cc: 'Ron Bonica'; erosen@cisco.com; David Allan; 'Thomas D. Nadeau'; > ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > Shahram, > > On the contrary, it is quite reasonable to propose scoping > requirements such as "tab B it should fit into slot A" in any > proposal for requirements that are intended ever to be filled. > Resemblance to existing tools is a very good example of an > appropriate scoping requirement proposal. What I saw Ron > commenting on was a similar scoping proposal which might > not be as likely of success in this forum. > > You wrote: > > >Ron, > > > >>We should not be surprised that > >>the enhanced > >>route tracing application resembles the current "traceroute" > >>in that a) it > >>is based upon probes and responses, b) UDP carries its PDUs, > >>and c) it is > >>stateless. > >> > > > >I am not surprised at all. What you are suggesting is > >your desire to resemble the IP traceroute. But this is only > >a desire and there is no technical reason why it should or it > >should not resemble the IP traceroute. > > > >A requirements document should leave the door open for other > >innovative ideas, unless you can prove that the traceroute-like > >mechanism is the BEST. > > > >-Shahram > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 15:11:08 -0800 Message-Id: <200203052310.g25NA4T34546@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: Unnumbered support with ISIS - using exiting TLV MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84479.1015369804.1@juniper.net> Date: Tue, 05 Mar 2002 15:10:04 -0800 From: Yakov Rekhter Folks, To support unnumbered links the current GMPLS ISIS routing spec defines new TLV, Link Identifier, to be carried in ISIS Hellos. It was pointed out that ISIS already has an existing mechanism to exchange link identifiers - see draft-ietf-isis-3way-05.txt. So, unless there are specific technical objections, I would suggest we replace Link Identifier TLV with the mechanism described in draft-ietf-isis-3way-05.txt Yakov, Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:45:00 -0800 Message-Id: <4.3.2.7.2.20020305173933.01e5bc28@161.44.167.72> Date: Tue, 05 Mar 2002 17:43:58 -0500 To: neil.2.harrison@bt.com From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ecuevas@att.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Agreed Enrique.....I have asked Tom to point us to where similar >requirements that he says he is working to (or more accurately, that he >'hears') are defined. You/I know they exist in Y.1710...since we agreed >them with other operators.....but Tom may have additional ones. I am sure >we would like to see them now. >BTW - I find it rather sad that operator defined requirements in ITU are >somehow deemed worthless in IETF.....at least in Tom's view. Neil puts words in my mouth. I never said that the requirements were worthless. I said that a) they are not defined here in the IETF, and we need a set defined here that we can work to. I don't think that the IETF works towards requirements defined elsewhere. I am also not hearing the same Y.1710 requirements from all of the operators I am working with. --Tom >regards, Neil > > > -----Original Message----- > > From: Cuevas, Enrique G, ALASO [mailto:ecuevas@att.com] > > Sent: 05 March 2002 17:48 > > To: Ping Pan > > Cc: Thomas D. Nadeau; ccamp > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > Ping, > > Here are some functions to consider. I am sure others can add > > to this list. > > > > 1) We need a function that can detect defects automatically > > and trigger corrective actions This function should also > > support statically configured MPLS networks. > > 2) We need a function to detect not only LSP breaks and > > miss-routing but also defects such as LSP replication into > > another LSP. > > 3) We need a function to immediately suppress the user > > traffic at the egress PE when an LSP is routed-routed. > > 4) To support PWE3 applications, we need a function to > > generate AIS for the tunneled circuits at the egress PE, when > > a defect is detected in the MPLS network. > > 5) We need a function to measure LSP performance accurately. > > 6) > > > > Enrique > > _______________ > > ecuevas@att.com > > Tel. (732)-420-3252 > > > > > > >-----Original Message----- > > >From: Ping Pan [mailto:pingpan@juniper.net] > > >Sent: Tuesday, March 05, 2002 10:15 AM > > >To: Cuevas, Enrique G, ALASO > > >Cc: Thomas D. Nadeau; ccamp@ops.ietf.org > > >Subject: Re: draft-bonica-tunneltrace-02 > > > > > > > > >The proposed stuff: > > > - a tool that can "ping" through a LSP, > > > - a tool that can do traceroute to a LSP > > > - a set of MIBs that can provide info on data traffic. > > > > > >They are not some projects dreamt by some bored developers. They are > > >required by our customers. Now, as a person who works for a > > provider, > > >would you please forget about XUZ standard from XYZ > > organization for a > > >moment, :-) and tell us what other functionality that we > > >should consider? > > > > > >Thank you! > > > > > >- Ping > > > > > >Cuevas, Enrique G, ALASO wrote: > > > > > >> Tom, > > >> Could you provide us with a matrix (comply/does not comply) > > >of the tools you are talking > > > > > >> about vs. the requirements given in Y.1710? > > >> > > >> Enrique > > > > > > > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:27:45 -0800 Message-ID: From: neil.2.harrison@bt.com To: pingpan@juniper.net, ecuevas@att.com Cc: tnadeau@cisco.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 22:26:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Ping.....nice to see a positive response from a specific manufacturer to our concerns as operators on this. This is a really good positive step IMO. Its a shame other manufacturers have discounted Y.1710, as what Enrique is saying here is simply a summary of some of the requirements stuff in there. regards, Neil > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: 05 March 2002 18:07 > To: Cuevas, Enrique G, ALASO > Cc: Thomas D. Nadeau; ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > Cuevas, Enrique G, ALASO wrote: > > > Ping, > > Here are some functions to consider. I am sure others can > add to this list. > > > > 1) We need a function that can detect defects automatically > and trigger corrective actions. > > > OK. > > > > 2) We need a function to detect not only LSP breaks and > miss-routing but also defects such as > > > LSP replication into another LSP. > > > OK. Good thinking... > > > > 3) We need a function to immediately suppress the user > traffic at the egress PE when an LSP > > > is routed-routed. > > > Actually, this is up to the NOC operators. > > > > 4) To support PWE3 applications, we need a function to > generate AIS for the tunneled circuits > > > at the egress PE, when a defect is detected in the MPLS network. > > > In fact, the detection mechanism should go beyond > protocol-level (RSVP > and LDP) probing. All MPLS applications, such as > L2-VPN/L3-VPN, should > be able to check the connectivity of their circuits. > > > 5) We need a function to measure LSP performance accurately. > > > OK. > > > > 6) > > > > > And, 6) We need more useful input like you have provided. :-) > > Many thanks! > > - Ping > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:27:42 -0800 Message-ID: From: neil.2.harrison@bt.com To: erosen@cisco.com, dallan@nortelnetworks.com Cc: Shahram_Davari@pmc-sierra.com, tnadeau@cisco.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 22:26:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" > > I understand that you don't think that MPLS, viewed as > an IP tunneling > protocol, is worthwhile. NH=> This sentence does not make sense Eric. MPLS is a layer network (proof by existence if you like), whether you would like it to be viewed as such or not. It may carry an IP client or it may not......that is irrelevant. The network object that we operators need to manage is the LSP.....inc those instantiated without any control-plane assistance. We are seeking as-generic-as-possible a solution, whereas you appear to only a advocate a restrictive solution. But that's not the question. > The question is > whether a traceroute tool that works through IP tunnels > (including MPLS > tunnels) is worth standardizing. NH=> You argument does not compute Eric. You are arguing for a generic tool (any server technology) but that view clearly breaks once you consider GMPLS....or more accurately SDH VCs or OTN trails. GTTP does not compute here as I hope you agree....however the *principles* of fault-managing the data-plane trail do (any layer).....and it is these principles that are truly generic, not the attempt to force some single mechanism across all (technology) layers. BTW - I know you find the concept of layered networks hard to swallow/accept but I can't help you on that one.....you will just have to either accept it or (we will all have to) live with the problem that you can't. This question doesn't > seem to have > anything to do with CO networks. Thus I don't understand > why a discussion > of CO networking is even relevant to the discussion of > the tunneltrace > requirements. NH=> This is an example of what I mean with us having to live your problem. > > Dave> I would also similarly invert the "saddled with > CO mechanisms" > Dave> statement as it would appear that bringing some CO > properties to IP is > Dave> what MPLS is all about. > > Certainly MPLS facilitates the bringing of some CO properties > to IP. NH=> Is this a 1st step to realisation there is life outside the cnls world? One of > the ideas of MPLS was to be able to bring the (few) good > properties without > also bringing the (much larger number of) bad properties. NH=> This smacks of .....'I know its true deep down, but boy does it hurt me to admit it'. As I pointed out to you in an earlier mail, our whole industry is totally dependent on having a cct-sw/CO technology *somewhere* below IP.......you can't connect IP transfer-mode boxes together without it (and if I may add your company has done very well on this very principle!). Why not just face it Eric? MPLS can/does create new data-plane trail entities....you may pretend this is not what they are, but we operators still have to manage them on this basis (ie they have functions/behaviours that are not based on IP...or any other layer network.....and as such require their own mtce processes). > Another idea was > to do this while using an IP control plane. So I hope you > can understand > why "let's do OAM the way it is done in CO networks", > and "let's do > something that doesn't require IP", is an argument that > does not resonate > very well with many of us. NH=> I can understand this view from someone like yourself with an IETF hat on....but to be honest it does not compute with GMPLS as I hope you can honestly agree. So where does one draw the cnls/co line? I actually don't think you need to draw any line *providing* we agree on the principles.....it is these that are enduring (ie the set of 'network problems' that are common to all cnls/co technologies), rather than trying to bludgeon a '1-size-fits-all mechanism' through (when it clearly does not). I can also understand other views here. When I discount the regligion, these simple facts remaim for MPLS: - MPLS does create new layer networks.....has to by definition of new OH/functionality. I mean would LDP, CR-LDP or RSVT-TE for example exist in an IP-only network? Does IP issue labels?, etc - MPLS can carry payloads other than IP......PWE3 is working on just such behaviour. - MPLS LSPs can have failure modes that are not relevant to any client layer or any server layer (nor should their 'behaviour' be dependent on any control-plane or management-plane protocols in use at peer/client/server layers). We therefore need tools to manage the defect detection/handling of MPLS failures that are generic and not a function of what appears above/below MPLS, nor how the LSPs are instantiated. This seems intuitively obvious to me and other like-minded operators/manufacturers. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:27:39 -0800 Message-ID: From: neil.2.harrison@bt.com To: ecuevas@att.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 22:26:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Agreed Enrique.....I have asked Tom to point us to where similar requirements that he says he is working to (or more accurately, that he 'hears') are defined. You/I know they exist in Y.1710...since we agreed them with other operators.....but Tom may have additional ones. I am sure we would like to see them now. BTW - I find it rather sad that operator defined requirements in ITU are somehow deemed worthless in IETF.....at least in Tom's view. regards, Neil > -----Original Message----- > From: Cuevas, Enrique G, ALASO [mailto:ecuevas@att.com] > Sent: 05 March 2002 17:48 > To: Ping Pan > Cc: Thomas D. Nadeau; ccamp > Subject: RE: draft-bonica-tunneltrace-02 > > > Ping, > Here are some functions to consider. I am sure others can add > to this list. > > 1) We need a function that can detect defects automatically > and trigger corrective actions This function should also > support statically configured MPLS networks. > 2) We need a function to detect not only LSP breaks and > miss-routing but also defects such as LSP replication into > another LSP. > 3) We need a function to immediately suppress the user > traffic at the egress PE when an LSP is routed-routed. > 4) To support PWE3 applications, we need a function to > generate AIS for the tunneled circuits at the egress PE, when > a defect is detected in the MPLS network. > 5) We need a function to measure LSP performance accurately. > 6) > > Enrique > _______________ > ecuevas@att.com > Tel. (732)-420-3252 > > > >-----Original Message----- > >From: Ping Pan [mailto:pingpan@juniper.net] > >Sent: Tuesday, March 05, 2002 10:15 AM > >To: Cuevas, Enrique G, ALASO > >Cc: Thomas D. Nadeau; ccamp@ops.ietf.org > >Subject: Re: draft-bonica-tunneltrace-02 > > > > > >The proposed stuff: > > - a tool that can "ping" through a LSP, > > - a tool that can do traceroute to a LSP > > - a set of MIBs that can provide info on data traffic. > > > >They are not some projects dreamt by some bored developers. They are > >required by our customers. Now, as a person who works for a > provider, > >would you please forget about XUZ standard from XYZ > organization for a > >moment, :-) and tell us what other functionality that we > >should consider? > > > >Thank you! > > > >- Ping > > > >Cuevas, Enrique G, ALASO wrote: > > > >> Tom, > >> Could you provide us with a matrix (comply/does not comply) > >of the tools you are talking > > > >> about vs. the requirements given in Y.1710? > >> > >> Enrique > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:06:32 -0800 Message-ID: <3C854149.9060806@sandburst.com> Date: Tue, 05 Mar 2002 17:06:01 -0500 From: Eric Gray MIME-Version: 1.0 To: Shahram Davari Cc: 'Ron Bonica' , erosen@cisco.com, David Allan , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Shahram, On the contrary, it is quite reasonable to propose scoping requirements such as "tab B it should fit into slot A" in any proposal for requirements that are intended ever to be filled. Resemblance to existing tools is a very good example of an appropriate scoping requirement proposal. What I saw Ron commenting on was a similar scoping proposal which might not be as likely of success in this forum. You wrote: >Ron, > >>We should not be surprised that >>the enhanced >>route tracing application resembles the current "traceroute" >>in that a) it >>is based upon probes and responses, b) UDP carries its PDUs, >>and c) it is >>stateless. >> > >I am not surprised at all. What you are suggesting is >your desire to resemble the IP traceroute. But this is only >a desire and there is no technical reason why it should or it >should not resemble the IP traceroute. > >A requirements document should leave the door open for other >innovative ideas, unless you can prove that the traceroute-like >mechanism is the BEST. > >-Shahram > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 14:06:28 -0800 Message-ID: <3C85416D.1010504@packetexchange.net> Date: Tue, 05 Mar 2002 22:06:37 +0000 From: Giles Heron Organization: PacketExchange Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: Well off the original thread topic... draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Allan wrote: > Hi Giles...long time no hear...;-) yeah, I've been resisting the temptation join the melee. Don't always succeed of course... ;-) > Another thread I have my regrets about....comments in line... > > > > > > Actually there are other things you can do with "just" LDP that you > > can't do with IP. > > > > 1) draft-martini etc. Sure, IP equivalents of this are now being > > defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available, > > and are much less efficient encapsulation-wise (as they require an IP > > header plus a tunnel header instead of a couple of labels). > > If you're discussing: > - i) using extended LDP adjacencies to hand out PW labels > - ii) the relative effy. of MPLS labels vs. IP headers > no argument, but that is somewhat orthogonal to the discussion of the > value that LDP-DU tied to routing may or may not provide. In fact it is the use of LDP-DU (or RSVP-TE) to hand out the tunnel label that gives us efficiency wrt L2TPv3 et al (and also seems to give us the availability of code - few of the vendors support L2TPv3 or draft-martini over GRE at this point - though of course practical issues like availability of code should be kept out of IETF discussions...) > > 2) MPLS VPN (RFC2547). I won't go into the pros and cons of > > this right > > now ;-) > > Current implementation is MPLS but I don't think there is a sustainable > dependency there...LDP permits the undelying MPLS network to behave like > an IP network. Seems to me they should be interchangable. they are - the above issues notwithstanding. > > 3) BGP free network core. This may improve stability > > (though there's > > certainly a strong argument that BGP is less destabilising than LDP > > right now) and security (the core doesn't need to know how to > > get to the > > Internet.) Also this allows you to layer multiple distinct > > IP backbones > > over one MPLS core. > > Left that one out of my analysis, not sure how simple LDP helps here. I > thought you LSP meshed your BGP speakers (which would be explicit > routes) and eliminated IGP. Yes, you LSP mesh the BGP speakers over LDP-DU tunnels using the IGP that is carried through the core. So the core doesn't need to know about the BGP routes. > > > It is when I get into topology manipulation independent of dynamic IP > > > routing that MPLS starts to add value and to claim this is not > > > connection oriented use of MPLS forwarding IMHO smacks of the same > > > "tunnel"/"layer" semantic debate that can also be said to > > waste much time. > > > > this is your view. And it is certainly one view. But it isn't > > necessarily the only valid view ;-) > > The "topology manipulation" part or the "terminology part" ? ;-) the "starts to add value" part - I think :) Giles > later > Dave > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 13:12:34 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD340215C789@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: erosen@cisco.com, Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Well off the original thread topic... draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 16:11:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C48A.55035FE0" 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_01C1C48A.55035FE0 Content-Type: text/plain; charset="iso-8859-1" Hi Giles...long time no hear...;-) Another thread I have my regrets about....comments in line... > > Actually there are other things you can do with "just" LDP that you > can't do with IP. > > 1) draft-martini etc. Sure, IP equivalents of this are now being > defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available, > and are much less efficient encapsulation-wise (as they require an IP > header plus a tunnel header instead of a couple of labels). If you're discussing: - i) using extended LDP adjacencies to hand out PW labels - ii) the relative effy. of MPLS labels vs. IP headers no argument, but that is somewhat orthogonal to the discussion of the value that LDP-DU tied to routing may or may not provide. > > 2) MPLS VPN (RFC2547). I won't go into the pros and cons of > this right > now ;-) Current implementation is MPLS but I don't think there is a sustainable dependency there...LDP permits the undelying MPLS network to behave like an IP network. Seems to me they should be interchangable. > 3) BGP free network core. This may improve stability > (though there's > certainly a strong argument that BGP is less destabilising than LDP > right now) and security (the core doesn't need to know how to > get to the > Internet.) Also this allows you to layer multiple distinct > IP backbones > over one MPLS core. Left that one out of my analysis, not sure how simple LDP helps here. I thought you LSP meshed your BGP speakers (which would be explicit routes) and eliminated IGP. > > It is when I get into topology manipulation independent of dynamic IP > > routing that MPLS starts to add value and to claim this is not > > connection oriented use of MPLS forwarding IMHO smacks of the same > > "tunnel"/"layer" semantic debate that can also be said to > waste much time. > > this is your view. And it is certainly one view. But it isn't > necessarily the only valid view ;-) The "topology manipulation" part or the "terminology part" ? ;-) later Dave ------_=_NextPart_001_01C1C48A.55035FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well off the original thread topic... = draft-bonica-tunneltrace-02

Hi Giles...long time no hear...;-)

Another thread I have my regrets about....comments in = line...

<snip>
>
> Actually there are other things you can do with = "just" LDP that you
> can't do with IP.
>
> 1)  draft-martini etc.  Sure, IP = equivalents of this are now being
> defined (UTI^H^H^H L2TPv3 et al) but they = aren't as widely available,
> and are much less efficient encapsulation-wise = (as they require an IP
> header plus a tunnel header instead of a couple = of labels).

If you're discussing:
- i) using extended LDP adjacencies to hand out PW = labels
- ii) the relative effy. of MPLS labels vs. IP = headers
no argument, but that is somewhat orthogonal to the = discussion of the value that LDP-DU tied to routing may or may not = provide.

>
> 2)  MPLS VPN (RFC2547).  I won't go = into the pros and cons of
> this right
> now ;-)

Current implementation is MPLS but I don't think = there is a sustainable dependency there...LDP permits the undelying = MPLS network to behave like an IP network. Seems to me they should be = interchangable.

> 3)  BGP free network core.  This may = improve stability
> (though there's
> certainly a strong argument that BGP is less = destabilising than LDP
> right now) and security (the core doesn't need = to know how to
> get to the
> Internet.)  Also this allows you to layer = multiple distinct
> IP backbones
> over one MPLS core.

Left that one out of my analysis, not sure how simple = LDP helps here. I thought you LSP meshed your BGP speakers (which would = be explicit routes) and eliminated IGP.

> > It is when I get into topology manipulation = independent of dynamic IP
> > routing that MPLS starts to add value and = to claim this is not
> > connection oriented use of MPLS forwarding = IMHO smacks of the same
> > "tunnel"/"layer" = semantic debate that can also be said to
> waste much time.
>
> this is your view.  And it is certainly = one view.  But it isn't
> necessarily the only valid view ;-)

The "topology manipulation" part or the = "terminology part" ? ;-)

later
Dave
 
 

------_=_NextPart_001_01C1C48A.55035FE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 12:57:16 -0800 Message-Id: <4.3.2.7.2.20020305155438.01d6fd38@161.44.167.72> Date: Tue, 05 Mar 2002 15:55:32 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: "'Ron Bonica'" , erosen@cisco.com, David Allan , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:25 PM 3/5/2002 -0800, Shahram Davari wrote: >Ron, > > > We should not be surprised that > > the enhanced > > route tracing application resembles the current "traceroute" > > in that a) it > > is based upon probes and responses, b) UDP carries its PDUs, > > and c) it is > > stateless. > > > >I am not surprised at all. What you are suggesting is >your desire to resemble the IP traceroute. But this is only >a desire and there is no technical reason why it should or it >should not resemble the IP traceroute. Sure there is; IP traceroute works. This is one of the best reasons in my mind. --Tom >A requirements document should leave the door open for other >innovative ideas, unless you can prove that the traceroute-like >mechanism is the BEST. > >-Shahram ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 12:26:31 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5EF@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ron Bonica'" , erosen@cisco.com, David Allan Cc: "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 12:25:44 -0800 MIME-Version: 1.0 Content-Type: text/plain Ron, > We should not be surprised that > the enhanced > route tracing application resembles the current "traceroute" > in that a) it > is based upon probes and responses, b) UDP carries its PDUs, > and c) it is > stateless. > I am not surprised at all. What you are suggesting is your desire to resemble the IP traceroute. But this is only a desire and there is no technical reason why it should or it should not resemble the IP traceroute. A requirements document should leave the door open for other innovative ideas, unless you can prove that the traceroute-like mechanism is the BEST. -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 12:13:53 -0800 Date: Tue, 05 Mar 2002 15:06:23 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: erosen@cisco.com, David Allan Cc: Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Folks, Eric has hit the nail on the head. The enhanced route-tracing application described in draft-bonica is an IP debugging tool. Specifically, it traces the path between any two points in an IP network. If one or more IP tunnels (e.g., MPLS) support the traced path, the application can reveal tunnel details. The tool is admittedly IP-centric. It assumes the ubiquity of IP, but does not assume that any particular tunneling technology has been deployed. This is a safe assumption for those of us who will use the tool to maintain IP networks. Given this starting point, the protocol requirements enumerated by the draft are a logical consequence. We should not be surprised that the enhanced route tracing application resembles the current "traceroute" in that a) it is based upon probes and responses, b) UDP carries its PDUs, and c) it is stateless. Ron (speaking as individual contributor) > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Eric Rosen > Sent: Tuesday, March 05, 2002 1:32 PM > To: David Allan > Cc: Shahram Davari; 'Thomas D. Nadeau'; ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > > I understand that you don't think that MPLS, viewed as an > IP tunneling > protocol, is worthwhile. But that's not the question. The > question is > whether a traceroute tool that works through IP tunnels > (including MPLS > tunnels) is worth standardizing. This question doesn't > seem to have > anything to do with CO networks. Thus I don't understand why a > discussion > of CO networking is even relevant to the discussion of the > tunneltrace > requirements. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 11:43:13 -0800 Message-Id: <4.3.2.7.2.20020305144027.01dc1b58@161.44.167.72> Date: Tue, 05 Mar 2002 14:42:17 -0500 To: From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Tom...I suspect Enrique is saying this because that is the only place he is >aware that they are written down and, since this is from the ITU, by >definition must have operator agreement. Can you please provide us with a >reference to the requirements documents that you are working to? My requirements come from my customers' operational departments. --Tom >thanks & regards, Neil > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: 05 March 2002 17:01 > > To: Cuevas, Enrique G, ALASO > > Cc: David Allan; Shahram Davari; ccamp > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > Why are we still discussing Y.1710? I thought that this > > was the IETF. The following seem to comply with the operational > > OAM requirements I am hearing from operators. > > > > LSP "ping", > > LSP Traceroute > > MIBs > > > > Others may be required. > > > > --Tom > > > > > > >Could you provide us with a matrix (comply/does not comply) > > of the tools > > >you are > > >talking about vs. the requirements given in Y.1710? > > > > > >Enrique > > >_______________ > > >ecuevas@att.com > > >Tel. (732)-420-3252 > > > > > > > > > >-----Original Message----- > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > >Sent: Tuesday, March 05, 2002 9:07 AM > > > >To: David Allan > > > >Cc: Shahram Davari; ccamp@ops.ietf.org > > > >Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > > > > > > > > >>Your statement that requirements support the tools/mechanisms > > > >that work > > > >>today is the nib of my concern. Basically the requirments step is > > > >>redundant at that point. We are now in a tight embrace where the > > > >>requirements justify the solution and the solution dictates the > > > >>requirements. Suggesting the requirements is a WG work item > > > >would appear > > > >>to be an oxymoron. > > > > > > > > As I mentioned, some of the tools have already been worked > > > >out, so yes, the cart is before the horse in some cases. However, > > > >I don't think that this is necessarily a problem. > > > > > > > > --Tom > > > > > > > > > > > > > > > >>Dave > > > >> > > > >> > -----Original Message----- > > > >> > From: Thomas D. Nadeau > > > >> [mailto:tnadeau@cisco.com] > > > >> > Sent: Monday, March 04, 2002 5:47 PM > > > >> > To: Shahram Davari > > > >> > Cc: ccamp@ops.ietf.org > > > >> > Subject: RE: draft-bonica-tunneltrace-02 > > > >> > > > > >> > > > > >> > > > > >> > >Thanks for your positive response. With regards to the > > > >> > protocol requirements, > > > >> > >which ones do you think MUST be there and why? > > > >> > > > > >> > I think that the protocol requirements for those > > > >> > solutions that > > > >> > currently > > > >> > exist should be in there. I understand your point about > > > >> > reverse engineering the tools, but unfortunately the > > > >> > requirement writing effort > > > >> > started after we had some solutions working. Therefore > > > >> > protocol requirements > > > >> > do matter because they support the tools/mechanisms that work > > > >> > today. No > > > >> > need to obviate those things at this point. > > > >> > > > > >> > >In my view protocol requirements should not unnecessarily > > > >> > restrict the > > > >> > >solution, > > > >> > >unless they violate application requirements. > > > >> > > > > >> > I think that protocol requirements should be in line > > > >> > with the > > > >> > application > > > >> > requirements that have come from operational folks working at > > > >> > SPs. However, > > > >> > application requirements should fit within existing protocols > > > >> > as much as > > > >> > possible (to promote reuse of existing software/tools). > > > >We should not > > > >> > be forced to reinvent the wheel just for the sake of doing so. > > > >> > > > > >> > --Tom > > > >> > > > > >> > > > > >> > > > > >> > >-Shahram > > > >> > > > > > >> > > > -----Original Message----- > > > >> > > > From: Thomas D. Nadeau > > > >> [mailto:tnadeau@cisco.com] > > > >> > > > Sent: Monday, March 04, 2002 4:25 PM > > > >> > > > To: Shahram Davari > > > >> > > > Cc: ccamp@ops.ietf.org > > > >> > > > Subject: RE: draft-bonica-tunneltrace-02 > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > >I think instead of debating whether Y.1711 is better than > > > >> > > > LSP-ping/GTTP or > > > >> > > > >vice versa, it would be more > > > >> > > > >constructive to identify and document the applicability of > > > >> > > > each proposal > > > >> > > > >for various tunneling applications. > > > >> > > > > > > >> > > > This sounds like a move in the right direction. > > > >> > > > > > > >> > > > >For this particular draft my suggestion at this stage is > > > >> > > > that the Bonica's > > > >> > > > >requirement draft be revised to: > > > >> > > > > > > > >> > > > >1) Add text (or at least a place holder) for additional > > > >> > > > security issues > > > >> > > > >raised on the list. > > > >> > > > >2) Add backward compatibility, simplicity and > > scalability as > > > >> > > > requirements. > > > >> > > > > > > >> > > > I can go along with those. > > > >> > > > > > > >> > > > >3) Remove the protocol requirements section, since any > > > >> > > > requirement here > > > >> > > > >will be viewed as a reverse engineering of some solution. > > > >> > > > > > > >> > > > Although this might sound reasonable to some, I > > > >> > > > think that some > > > >> > > > may object to this > > > >> > > > since the protocol requirements are viewed by some as > > > >> > > > fundamental to the > > > >> > > > requirements > > > >> > > > of any particular solution. In the flurry of emails on the > > > >> > > > topic, I have > > > >> > > > not been able to > > > >> > > > keep track of what the consensus on this might be (either > > > >> > > > way). Perhaps Ron > > > >> > > > has been keeping > > > >> > > > track? > > > >> > > > > > > >> > > > >Then any offered solution should have text to show to what > > > >> > > > extent they > > > >> > > > >fulfill the > > > >> > > > >requirements, and what is their applicability and > > > >restrictions. > > > >> > > > > > > >> > > > Sounds reasonable. > > > >> > > > > > > >> > > > --Tom > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > -------------------------------------------------------------- > > > >> > > > ---------- > > > >> > > > Mathematics is the supreme nostalgia of our time. > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> > -------------------------------------------------------------- > > > >> > ---------- > > > >> > Mathematics is the supreme nostalgia of our time. > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > >--------------------------------------------------------------- > > > >--------- > > > >Mathematics is the supreme nostalgia of our time. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 11:40:26 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E242@nimbus> From: John Drake To: "'neil.2.harrison@bt.com'" , erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 11:39:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Neil, As a related question, would you please explain how your OAM proposal fits against GMPLS? Thanks, John -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Tuesday, March 05, 2002 11:32 AM To: erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Eric...can you please explain how GMPLS fits against this statement please? regards, Neil > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 05 March 2002 14:52 > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > > Shahram> What is the difference between ATM, FR, or any CO > technology and > Shahram> MPLS > > Well, for one thing, MPLS isn't a CO technology. It's got > lots of stuff > that doesn't really make sense from a CO perspective. Of > course, when the > CO guys run across these features (multipoint-to-point, > php, liberal > retention, independent mode, equal cost load balancing, > dynamic rerouting > with no signaling, ttl, lack of packet sequencing, IP > control plane, etc., > etc.) they assume that those features are there by mistake! > > This misconception that MPLS is a CO technology, shared > as it is by the > "pure IP" crowd and by the ITU/ATM crowd, is the source > of much wasted > time. > > MPLS is actually an IP-derived technology that facilitates > the application > of certain circuit-like characteristics to IP > networks. As an IP > technology, the usual IP diagnostic tools, such as ping > and traceroute, > should be applicable. That's what this whole useless > discussion is about. > One the one side are people who think that IP networks > are inherently > unmanageable (after all, they don't follow ITU standards), > and on the other > side are people who think that the IP-based paradigms are the best. > > It is true that MPLS can be used to provide something which > is very like a > CO network, but it doesn't have to be used this way, and > usually isn't. > Those of use who are not particularly interested in CO > networks just don't > want to be saddled with the legacy CO mechanisms. > Presumably, if all these > legacy CO mechanisms were so great there would not be such > a great rush to > IP. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 11:33:12 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 19:32:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Tom...I suspect Enrique is saying this because that is the only place he is aware that they are written down and, since this is from the ITU, by definition must have operator agreement. Can you please provide us with a reference to the requirements documents that you are working to? thanks & regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 05 March 2002 17:01 > To: Cuevas, Enrique G, ALASO > Cc: David Allan; Shahram Davari; ccamp > Subject: RE: draft-bonica-tunneltrace-02 > > > > Why are we still discussing Y.1710? I thought that this > was the IETF. The following seem to comply with the operational > OAM requirements I am hearing from operators. > > LSP "ping", > LSP Traceroute > MIBs > > Others may be required. > > --Tom > > > >Could you provide us with a matrix (comply/does not comply) > of the tools > >you are > >talking about vs. the requirements given in Y.1710? > > > >Enrique > >_______________ > >ecuevas@att.com > >Tel. (732)-420-3252 > > > > > > >-----Original Message----- > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > >Sent: Tuesday, March 05, 2002 9:07 AM > > >To: David Allan > > >Cc: Shahram Davari; ccamp@ops.ietf.org > > >Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > > > >>Your statement that requirements support the tools/mechanisms > > >that work > > >>today is the nib of my concern. Basically the requirments step is > > >>redundant at that point. We are now in a tight embrace where the > > >>requirements justify the solution and the solution dictates the > > >>requirements. Suggesting the requirements is a WG work item > > >would appear > > >>to be an oxymoron. > > > > > > As I mentioned, some of the tools have already been worked > > >out, so yes, the cart is before the horse in some cases. However, > > >I don't think that this is necessarily a problem. > > > > > > --Tom > > > > > > > > > > > >>Dave > > >> > > >> > -----Original Message----- > > >> > From: Thomas D. Nadeau > > >> [mailto:tnadeau@cisco.com] > > >> > Sent: Monday, March 04, 2002 5:47 PM > > >> > To: Shahram Davari > > >> > Cc: ccamp@ops.ietf.org > > >> > Subject: RE: draft-bonica-tunneltrace-02 > > >> > > > >> > > > >> > > > >> > >Thanks for your positive response. With regards to the > > >> > protocol requirements, > > >> > >which ones do you think MUST be there and why? > > >> > > > >> > I think that the protocol requirements for those > > >> > solutions that > > >> > currently > > >> > exist should be in there. I understand your point about > > >> > reverse engineering the tools, but unfortunately the > > >> > requirement writing effort > > >> > started after we had some solutions working. Therefore > > >> > protocol requirements > > >> > do matter because they support the tools/mechanisms that work > > >> > today. No > > >> > need to obviate those things at this point. > > >> > > > >> > >In my view protocol requirements should not unnecessarily > > >> > restrict the > > >> > >solution, > > >> > >unless they violate application requirements. > > >> > > > >> > I think that protocol requirements should be in line > > >> > with the > > >> > application > > >> > requirements that have come from operational folks working at > > >> > SPs. However, > > >> > application requirements should fit within existing protocols > > >> > as much as > > >> > possible (to promote reuse of existing software/tools). > > >We should not > > >> > be forced to reinvent the wheel just for the sake of doing so. > > >> > > > >> > --Tom > > >> > > > >> > > > >> > > > >> > >-Shahram > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: Thomas D. Nadeau > > >> [mailto:tnadeau@cisco.com] > > >> > > > Sent: Monday, March 04, 2002 4:25 PM > > >> > > > To: Shahram Davari > > >> > > > Cc: ccamp@ops.ietf.org > > >> > > > Subject: RE: draft-bonica-tunneltrace-02 > > >> > > > > > >> > > > > > >> > > > > > >> > > > >I think instead of debating whether Y.1711 is better than > > >> > > > LSP-ping/GTTP or > > >> > > > >vice versa, it would be more > > >> > > > >constructive to identify and document the applicability of > > >> > > > each proposal > > >> > > > >for various tunneling applications. > > >> > > > > > >> > > > This sounds like a move in the right direction. > > >> > > > > > >> > > > >For this particular draft my suggestion at this stage is > > >> > > > that the Bonica's > > >> > > > >requirement draft be revised to: > > >> > > > > > > >> > > > >1) Add text (or at least a place holder) for additional > > >> > > > security issues > > >> > > > >raised on the list. > > >> > > > >2) Add backward compatibility, simplicity and > scalability as > > >> > > > requirements. > > >> > > > > > >> > > > I can go along with those. > > >> > > > > > >> > > > >3) Remove the protocol requirements section, since any > > >> > > > requirement here > > >> > > > >will be viewed as a reverse engineering of some solution. > > >> > > > > > >> > > > Although this might sound reasonable to some, I > > >> > > > think that some > > >> > > > may object to this > > >> > > > since the protocol requirements are viewed by some as > > >> > > > fundamental to the > > >> > > > requirements > > >> > > > of any particular solution. In the flurry of emails on the > > >> > > > topic, I have > > >> > > > not been able to > > >> > > > keep track of what the consensus on this might be (either > > >> > > > way). Perhaps Ron > > >> > > > has been keeping > > >> > > > track? > > >> > > > > > >> > > > >Then any offered solution should have text to show to what > > >> > > > extent they > > >> > > > >fulfill the > > >> > > > >requirements, and what is their applicability and > > >restrictions. > > >> > > > > > >> > > > Sounds reasonable. > > >> > > > > > >> > > > --Tom > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > -------------------------------------------------------------- > > >> > > > ---------- > > >> > > > Mathematics is the supreme nostalgia of our time. > > >> > > > > > >> > > > >> > > > >> > > > >> > -------------------------------------------------------------- > > >> > ---------- > > >> > Mathematics is the supreme nostalgia of our time. > > >> > > > >> > > > >> > > > > > > > > > > > > >--------------------------------------------------------------- > > >--------- > > >Mathematics is the supreme nostalgia of our time. > > > > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 11:33:09 -0800 Message-ID: From: neil.2.harrison@bt.com To: erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 19:32:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric...can you please explain how GMPLS fits against this statement please? regards, Neil > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 05 March 2002 14:52 > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > > Shahram> What is the difference between ATM, FR, or any CO > technology and > Shahram> MPLS > > Well, for one thing, MPLS isn't a CO technology. It's got > lots of stuff > that doesn't really make sense from a CO perspective. Of > course, when the > CO guys run across these features (multipoint-to-point, > php, liberal > retention, independent mode, equal cost load balancing, > dynamic rerouting > with no signaling, ttl, lack of packet sequencing, IP > control plane, etc., > etc.) they assume that those features are there by mistake! > > This misconception that MPLS is a CO technology, shared > as it is by the > "pure IP" crowd and by the ITU/ATM crowd, is the source > of much wasted > time. > > MPLS is actually an IP-derived technology that facilitates > the application > of certain circuit-like characteristics to IP > networks. As an IP > technology, the usual IP diagnostic tools, such as ping > and traceroute, > should be applicable. That's what this whole useless > discussion is about. > One the one side are people who think that IP networks > are inherently > unmanageable (after all, they don't follow ITU standards), > and on the other > side are people who think that the IP-based paradigms are the best. > > It is true that MPLS can be used to provide something which > is very like a > CO network, but it doesn't have to be used this way, and > usually isn't. > Those of use who are not particularly interested in CO > networks just don't > want to be saddled with the legacy CO mechanisms. > Presumably, if all these > legacy CO mechanisms were so great there would not be such > a great rush to > IP. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 11:08:37 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5EE@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" Cc: "Cuevas, Enrique G, ALASO" , "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 11:07:19 -0800 MIME-Version: 1.0 Content-Type: text/plain Ping > > Again, what to do with user traffic is up to the operators. I agree >We, at best, provide some knobs to the operators. I think this was the essence of Enrique's requested function. > I am suggesting to have the flexibility to probe anything that the > operators want. That includes the applications they use > today, and the > applications that they may use in the future (yes, we update > our tools > whenever new application becomes available). Many may think this is a > moving target. So what? Our job is to make the operator's > life easier, > which in turn making their customer happy. Could you please provide an example in the context of ATM over MPLS, and how you intend to generate ATM AIS. -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 10:53:18 -0800 Message-ID: <3C8513E6.4030007@juniper.net> Date: Tue, 05 Mar 2002 10:52:22 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011222 MIME-Version: 1.0 To: Shahram Davari CC: "Cuevas, Enrique G, ALASO" , "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Shahram Davari wrote: > Ping, > >> >>Actually, this is up to the NOC operators. >> >> > > The decision to suppress the traffic or not is up to the operator. But what tool is available to them in order to suppress > the traffic when a misrouting defect is detected? > Again, what to do with user traffic is up to the operators. We, at best, provide some knobs to the operators. If the tools are available yet, they will be soon. > >>>4) To support PWE3 applications, we need a function to >>> >>generate AIS for the tunneled circuits >> >> >>>at the egress PE, when a defect is detected in the MPLS network. >>> >> >>In fact, the detection mechanism should go beyond >>protocol-level (RSVP >>and LDP) probing. All MPLS applications, such as >>L2-VPN/L3-VPN, should >>be able to check the connectivity of their circuits. >> > > If I understand correctly, you are suggesting that connectivity check > should be done at the circuit level not tunnel level. > I am suggesting to have the flexibility to probe anything that the operators want. That includes the applications they use today, and the applications that they may use in the future (yes, we update our tools whenever new application becomes available). Many may think this is a moving target. So what? Our job is to make the operator's life easier, which in turn making their customer happy. - Ping Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 10:36:54 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5ED@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ping Pan'" , "Cuevas, Enrique G, ALASO" Cc: "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 10:36:35 -0800 MIME-Version: 1.0 Content-Type: text/plain Ping, > > > 3) We need a function to immediately suppress the user > traffic at the egress PE when an LSP > > > is routed-routed. > > > Actually, this is up to the NOC operators. > The decision to suppress the traffic or not is up to the operator. But what tool is available to them in order to suppress the traffic when a misrouting defect is detected? > > > 4) To support PWE3 applications, we need a function to > generate AIS for the tunneled circuits > > > at the egress PE, when a defect is detected in the MPLS network. > > > In fact, the detection mechanism should go beyond > protocol-level (RSVP > and LDP) probing. All MPLS applications, such as > L2-VPN/L3-VPN, should > be able to check the connectivity of their circuits. If I understand correctly, you are suggesting that connectivity check should be done at the circuit level not tunnel level. Off course each tunneled circuit should have its own method of connectivity check. But if you don't translate a connectivity loss in the tunnel level to those circuits , then an alarm storm will happen at the terminating point of those circuits, which could cause mass confusion. -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 10:32:06 -0800 Message-Id: <200203051831.NAA16250@erosen-u10.cisco.com> To: "David Allan" cc: Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Mar 2002 13:31:35 -0500 From: Eric Rosen I understand that you don't think that MPLS, viewed as an IP tunneling protocol, is worthwhile. But that's not the question. The question is whether a traceroute tool that works through IP tunnels (including MPLS tunnels) is worth standardizing. This question doesn't seem to have anything to do with CO networks. Thus I don't understand why a discussion of CO networking is even relevant to the discussion of the tunneltrace requirements. Dave> I would also similarly invert the "saddled with CO mechanisms" Dave> statement as it would appear that bringing some CO properties to IP is Dave> what MPLS is all about. Certainly MPLS facilitates the bringing of some CO properties to IP. One of the ideas of MPLS was to be able to bring the (few) good properties without also bringing the (much larger number of) bad properties. Another idea was to do this while using an IP control plane. So I hope you can understand why "let's do OAM the way it is done in CO networks", and "let's do something that doesn't require IP", is an argument that does not resonate very well with many of us. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 10:06:28 -0800 Message-ID: <3C85094E.9090507@juniper.net> Date: Tue, 05 Mar 2002 10:07:10 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: "Cuevas, Enrique G, ALASO" CC: "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cuevas, Enrique G, ALASO wrote: > Ping, > Here are some functions to consider. I am sure others can add to this list. > > 1) We need a function that can detect defects automatically and trigger corrective actions. OK. > 2) We need a function to detect not only LSP breaks and miss-routing but also defects such as > LSP replication into another LSP. OK. Good thinking... > 3) We need a function to immediately suppress the user traffic at the egress PE when an LSP > is routed-routed. Actually, this is up to the NOC operators. > 4) To support PWE3 applications, we need a function to generate AIS for the tunneled circuits > at the egress PE, when a defect is detected in the MPLS network. In fact, the detection mechanism should go beyond protocol-level (RSVP and LDP) probing. All MPLS applications, such as L2-VPN/L3-VPN, should be able to check the connectivity of their circuits. > 5) We need a function to measure LSP performance accurately. OK. > 6) > And, 6) We need more useful input like you have provided. :-) Many thanks! - Ping Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 09:49:35 -0800 content-class: urn:content-classes:message Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 12:47:45 -0500 Message-ID: <28F05913385EAC43AF019413F674A017016DAE21@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-bonica-tunneltrace-02 Thread-Index: AcHEWFQ11hXx32KwR5eU+kfPGvkL8gAFWCTg From: "Cuevas, Enrique G, ALASO" To: "Ping Pan" Cc: "Thomas D. Nadeau" , Ping, Here are some functions to consider. I am sure others can add to this = list. 1) We need a function that can detect defects automatically and trigger = corrective actions This function should also support statically = configured MPLS networks. 2) We need a function to detect not only LSP breaks and miss-routing but = also defects such as LSP replication into another LSP. 3) We need a function to immediately suppress the user traffic at the = egress PE when an LSP is routed-routed.=20 4) To support PWE3 applications, we need a function to generate AIS for = the tunneled circuits at the egress PE, when a defect is detected in the = MPLS network. 5) We need a function to measure LSP performance accurately. 6) Enrique _______________ ecuevas@att.com Tel. (732)-420-3252 >-----Original Message----- >From: Ping Pan [mailto:pingpan@juniper.net] >Sent: Tuesday, March 05, 2002 10:15 AM >To: Cuevas, Enrique G, ALASO >Cc: Thomas D. Nadeau; ccamp@ops.ietf.org >Subject: Re: draft-bonica-tunneltrace-02 > > >The proposed stuff: > - a tool that can "ping" through a LSP, > - a tool that can do traceroute to a LSP > - a set of MIBs that can provide info on data traffic. > >They are not some projects dreamt by some bored developers. They are=20 >required by our customers. Now, as a person who works for a provider,=20 >would you please forget about XUZ standard from XYZ organization for a=20 >moment, :-) and tell us what other functionality that we=20 >should consider? > >Thank you! > >- Ping > >Cuevas, Enrique G, ALASO wrote: > >> Tom, >> Could you provide us with a matrix (comply/does not comply)=20 >of the tools you are talking=20 > >> about vs. the requirements given in Y.1710? >>=20 >> Enrique > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 09:01:36 -0800 Message-Id: <4.3.2.7.2.20020305115833.081abf88@161.44.167.72> Date: Tue, 05 Mar 2002 12:00:53 -0500 To: "Cuevas, Enrique G, ALASO" From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: "David Allan" , "Shahram Davari" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Why are we still discussing Y.1710? I thought that this was the IETF. The following seem to comply with the operational OAM requirements I am hearing from operators. LSP "ping", LSP Traceroute MIBs Others may be required. --Tom >Could you provide us with a matrix (comply/does not comply) of the tools >you are >talking about vs. the requirements given in Y.1710? > >Enrique >_______________ >ecuevas@att.com >Tel. (732)-420-3252 > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Tuesday, March 05, 2002 9:07 AM > >To: David Allan > >Cc: Shahram Davari; ccamp@ops.ietf.org > >Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > >>Your statement that requirements support the tools/mechanisms > >that work > >>today is the nib of my concern. Basically the requirments step is > >>redundant at that point. We are now in a tight embrace where the > >>requirements justify the solution and the solution dictates the > >>requirements. Suggesting the requirements is a WG work item > >would appear > >>to be an oxymoron. > > > > As I mentioned, some of the tools have already been worked > >out, so yes, the cart is before the horse in some cases. However, > >I don't think that this is necessarily a problem. > > > > --Tom > > > > > > > >>Dave > >> > >> > -----Original Message----- > >> > From: Thomas D. Nadeau > >> [mailto:tnadeau@cisco.com] > >> > Sent: Monday, March 04, 2002 5:47 PM > >> > To: Shahram Davari > >> > Cc: ccamp@ops.ietf.org > >> > Subject: RE: draft-bonica-tunneltrace-02 > >> > > >> > > >> > > >> > >Thanks for your positive response. With regards to the > >> > protocol requirements, > >> > >which ones do you think MUST be there and why? > >> > > >> > I think that the protocol requirements for those > >> > solutions that > >> > currently > >> > exist should be in there. I understand your point about > >> > reverse engineering the tools, but unfortunately the > >> > requirement writing effort > >> > started after we had some solutions working. Therefore > >> > protocol requirements > >> > do matter because they support the tools/mechanisms that work > >> > today. No > >> > need to obviate those things at this point. > >> > > >> > >In my view protocol requirements should not unnecessarily > >> > restrict the > >> > >solution, > >> > >unless they violate application requirements. > >> > > >> > I think that protocol requirements should be in line > >> > with the > >> > application > >> > requirements that have come from operational folks working at > >> > SPs. However, > >> > application requirements should fit within existing protocols > >> > as much as > >> > possible (to promote reuse of existing software/tools). > >We should not > >> > be forced to reinvent the wheel just for the sake of doing so. > >> > > >> > --Tom > >> > > >> > > >> > > >> > >-Shahram > >> > > > >> > > > -----Original Message----- > >> > > > From: Thomas D. Nadeau > >> [mailto:tnadeau@cisco.com] > >> > > > Sent: Monday, March 04, 2002 4:25 PM > >> > > > To: Shahram Davari > >> > > > Cc: ccamp@ops.ietf.org > >> > > > Subject: RE: draft-bonica-tunneltrace-02 > >> > > > > >> > > > > >> > > > > >> > > > >I think instead of debating whether Y.1711 is better than > >> > > > LSP-ping/GTTP or > >> > > > >vice versa, it would be more > >> > > > >constructive to identify and document the applicability of > >> > > > each proposal > >> > > > >for various tunneling applications. > >> > > > > >> > > > This sounds like a move in the right direction. > >> > > > > >> > > > >For this particular draft my suggestion at this stage is > >> > > > that the Bonica's > >> > > > >requirement draft be revised to: > >> > > > > > >> > > > >1) Add text (or at least a place holder) for additional > >> > > > security issues > >> > > > >raised on the list. > >> > > > >2) Add backward compatibility, simplicity and scalability as > >> > > > requirements. > >> > > > > >> > > > I can go along with those. > >> > > > > >> > > > >3) Remove the protocol requirements section, since any > >> > > > requirement here > >> > > > >will be viewed as a reverse engineering of some solution. > >> > > > > >> > > > Although this might sound reasonable to some, I > >> > > > think that some > >> > > > may object to this > >> > > > since the protocol requirements are viewed by some as > >> > > > fundamental to the > >> > > > requirements > >> > > > of any particular solution. In the flurry of emails on the > >> > > > topic, I have > >> > > > not been able to > >> > > > keep track of what the consensus on this might be (either > >> > > > way). Perhaps Ron > >> > > > has been keeping > >> > > > track? > >> > > > > >> > > > >Then any offered solution should have text to show to what > >> > > > extent they > >> > > > >fulfill the > >> > > > >requirements, and what is their applicability and > >restrictions. > >> > > > > >> > > > Sounds reasonable. > >> > > > > >> > > > --Tom > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > -------------------------------------------------------------- > >> > > > ---------- > >> > > > Mathematics is the supreme nostalgia of our time. > >> > > > > >> > > >> > > >> > > >> > -------------------------------------------------------------- > >> > ---------- > >> > Mathematics is the supreme nostalgia of our time. > >> > > >> > > >> > > > > > > > > >--------------------------------------------------------------- > >--------- > >Mathematics is the supreme nostalgia of our time. > > > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 09:00:11 -0800 From: ananth.nagarajan@mail.sprint.com Date: Tue, 5 Mar 2002 10:57:12 -0600 Message-Id: Subject: RE: Re: WG document status MIME-Version: 1.0 TO: ccamp@ops.ietf.org, sob@harvard.edu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 5 Mar 2002 10:57:12 -0600" Content-Transfer-Encoding: 7bit > > but in any case, if there are multiple interoperational > implementations, > then documenting that fact does not seem like a bad idea > So does the lack of interoperable implementations hinder the process to progress this specific document (or other documents in CCAMP) as proposed standard? or will that be a requirement only when progressing it beyond proposed standard to draft standard and further? Ananth > Scott > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:44:18 -0800 Date: Tue, 5 Mar 2002 11:43:22 -0500 (EST) From: Scott Bradner Message-Id: <200203051643.g25GhMC01693@newdev.harvard.edu> To: ccamp@ops.ietf.org Subject: Re: WG document status > I think it would be good if our current ADs could give their > view on this. Also whether the routing area requirements are > applicable for the Sub-IP area. there is not a general requirement to meet the extra routing area requirements in the sub-ip area - but the last time there was a discussion in the sub-ip directorate about the want to hold GMPLS to the routing area requirements (even though the work is no longer in the routing area) the feeling was that it would be good to do so but in any case, if there are multiple interoperational implementations, then documenting that fact does not seem like a bad idea Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:24:01 -0800 Date: Tue, 5 Mar 2002 11:23:20 -0500 (EST) From: Scott Bradner Message-Id: <200203051623.g25GNK201556@newdev.harvard.edu> To: loa.andersson@utfors.se, mlazer@att.com, Sasha@AXERRA.com Subject: RE: WG document status Cc: afferton@att.com, bwijnen@lucent.com, ccamp@ops.ietf.org, dbrungard@att.com, gash@att.com, yakov@juniper.net > Does not RFC 2026 overrule the previous requirements, the pp in 2026 you note gives the IESG (backing up a AD for example) flexibility to support the type of thing that the routing AD did from 2026 sec 4.1.1 The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:15:26 -0800 Date: Tue, 5 Mar 2002 11:14:57 -0500 (EST) From: Scott Bradner Message-Id: <200203051614.g25GEv901503@newdev.harvard.edu> To: mlazer@att.com, yakov@juniper.net Subject: Re: WG document status Cc: afferton@att.com, bwijnen@lucent.com, ccamp@ops.ietf.org, dbrungard@att.com, gash@att.com > According to the IETF Standard Process for routing "two or more > interoperable implementations must exist" when a protocol is advanced > from a Proposed Standard to a Draft Standard, but this is *not* required > when a protocol goes into a Proposed Standard. that is correct as far as the Internet Standards Process goes but Bob Hinden, as the routing AD in 1991, wanted to impose a harder barrier for protocols in the routing area - I was not on the IESG at the time but it is my understanding that this change was supported by the IESG for the routing area, as far as I know, no other area directors have put forth similar ideas RFC 1264 was published to document this decision Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:14:07 -0800 Message-ID: <3C84EEB9.3040803@utfors.se> Date: Tue, 05 Mar 2002 17:13:45 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Sasha Vainshtein CC: "Lazer, Monica A, ALCNS" , Yakov Rekhter , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Ash, Gerald R (Jerry), ALASO" Subject: Re: WG document status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sasha, given that I haven't researched the process enough, this may be just my own opinions. But I think that 1264 is still valid, it came out of the concern of the routing AD at the time that errors in routing protocls might have much more drastic implications than an error in an application. I think it would be good if our current ADs could give their view on this. Also whether the routing area requirements are applicable for the Sub-IP area. /Loa Sasha Vainshtein wrote: > Loa and all, > Does not RFC 2026 overrule the previous requirements, > like RFC 1264? And it does not require (Section 4.1.1) > even a SINGLE implementation for a Proposed Standard > even if it states that "the IESG may require one and if > existence of implementation and operational experience > are both declared "highly desirable" and would "represent > a strong argument in favor of a Proposed Standard designation". > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > >>-----Original Message----- >>From: Loa Andersson [mailto:loa.andersson@utfors.se] >>Sent: Tuesday, March 05, 2002 5:26 PM >>To: Lazer, Monica A, ALCNS >>Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp@ops.ietf.org; >>Brungard, Deborah A, ALASO; Afferton, Thomas S (Tom), ALCNS; >>Ash, Gerald R (Jerry), ALASO >>Subject: Re: WG document status >> >> >>All, >> >>hopefully someone can shed light on this, there seems to be a >>contradiction somewhere, if "general" is intended to be understood >>as applicable to Proposed, Draft and Standard equally, what is >>the reason to have lesser requirements for Proposed and Draft. >> >>Or is that "general" is something that the end result and the "steps" >>in 1264 is what we have to achieve on our way there? >> >> >>For PS there is a requirement of at least two independently written >>implementations, but not on interoperability? Is that it? >> >>/Loa >> >>Lazer, Monica A, ALCNS wrote: >> >> >>>Yakov, >>>Bert, >>> >>> >>> >>>>>Please note that in the RTG area (rfc1264) there is no requirement >>>>>for a Proposed Standard to have (a) more than one >>>>> >>implementation, and >> >>>>>(b) for these implementations to be interoperable. >>>>> >>>>> >>>>Nowhere in the above there is a requirement for multiple >>>> >>interoperable >> >>>>implementations. With this in mind, please take out the part about >>>>"interoperability test results". >>>> >>>> >>>RFC 1264 also says: >>> >>>"3.0 General Requirements >>> >>> 4) Generally, a number of interoperable implementations must >>> exist. At least two must be written independently. >>> >>>5.0 Requirements for Draft Standard >>> >>> 3) Two or more interoperable implementations must exist. >>> >> At least >> >>> two must be written independently. >>> >>>6.0 Requirements for Standard >>> >>> 3) Three or more interoperable implementations must >>> >>exist. At least >> >>> two must be written independently." >>> >>>We would like to insist on 2 or more interoperable >>> >>implementations being a requirement. Without >>interoperability, any proprietary protocol does just the >>same, so we don't need an RFC for that. >> >>> >>>Monica A. Lazer >>>Advanced Transport Technology and Architecture Planning >>> >>>(908) 234 8462 >>>mlazer@att.com >>> >>> >>> >>> >>> >> >>-- >>Loa Andersson >>Chief Architect, >>Utfors Research, Architecture and Future Lab (URAX) >>Utfors AB >>Råsundavägen 12 >>Box 525, 169 29 Solna >>Office +46 8 5270 2000 >>Office direct +46 8 5270 5038 >>Mobile +46 70 848 5038 >>Email loa.andersson@utfors.se >>WWW www.utfors.se >> >> > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:07:32 -0800 Message-ID: From: Sasha Vainshtein To: 'Loa Andersson' , "Lazer, Monica A, ALCNS" Cc: Yakov Rekhter , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Ash, Gerald R (Jerry), ALASO" Subject: RE: WG document status Date: Tue, 5 Mar 2002 17:59:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Loa and all, Does not RFC 2026 overrule the previous requirements,=20 like RFC 1264? And it does not require (Section 4.1.1)=20 even a SINGLE implementation for a Proposed Standard=20 even if it states that "the IESG may require one and if=20 existence of implementation and operational experience=20 are both declared "highly desirable" and would "represent=20 a strong argument in favor of a Proposed Standard designation". With best regards, Sasha Vainshtein email: sasha@axerra.com =20 tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) =20 > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Tuesday, March 05, 2002 5:26 PM > To: Lazer, Monica A, ALCNS > Cc: Yakov Rekhter; Wijnen, Bert (Bert); ccamp@ops.ietf.org;=20 > Brungard, Deborah A, ALASO; Afferton, Thomas S (Tom), ALCNS;=20 > Ash, Gerald R (Jerry), ALASO > Subject: Re: WG document status >=20 >=20 > All, >=20 > hopefully someone can shed light on this, there seems to be a > contradiction somewhere, if "general" is intended to be understood > as applicable to Proposed, Draft and Standard equally, what is > the reason to have lesser requirements for Proposed and Draft. >=20 > Or is that "general" is something that the end result and the "steps" > in 1264 is what we have to achieve on our way there? >=20 >=20 > For PS there is a requirement of at least two independently written > implementations, but not on interoperability? Is that it? >=20 > /Loa >=20 > Lazer, Monica A, ALCNS wrote: >=20 > > Yakov, > > Bert, > >=20 > >=20 > >>>Please note that in the RTG area (rfc1264) there is no requirement > >>>for a Proposed Standard to have (a) more than one=20 > implementation, and > >>>(b) for these implementations to be interoperable. > >>> > >=20 > >>Nowhere in the above there is a requirement for multiple=20 > interoperable > >>implementations. With this in mind, please take out the part about > >>"interoperability test results". > >> > >=20 > > RFC 1264 also says: > >=20 > > "3.0 General Requirements > >=20 > > 4) Generally, a number of interoperable implementations must > > exist. At least two must be written independently. > >=20 > > 5.0 Requirements for Draft Standard > >=20 > > 3) Two or more interoperable implementations must exist.=20 > At least > > two must be written independently. > >=20 > > 6.0 Requirements for Standard > >=20 > > 3) Three or more interoperable implementations must=20 > exist. At least > > two must be written independently." > >=20 > > We would like to insist on 2 or more interoperable=20 > implementations being a requirement. Without=20 > interoperability, any proprietary protocol does just the=20 > same, so we don't need an RFC for that. > >=20 > >=20 > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > >=20 > > (908) 234 8462 > > mlazer@att.com > >=20 > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > R=E5sundav=E4gen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:03:48 -0800 Message-ID: <3C84ECA0.3070604@packetexchange.net> Date: Tue, 05 Mar 2002 16:04:48 +0000 From: Giles Heron Organization: PacketExchange Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Shahram Davari , "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Allan wrote: > Eric: > > I would phrase it differently. MPLS has a dual nature which tends to be > a function of the control plane used. > > Most of what you describe as non-CO stuff permits LSPs to mimic the > topology generated by IP routing with as ruthlessly simple an > implementation as possible, and that's OK, that was a design goal. > > However if that were the only application of MPLS, I would delegate it > to being a useless appendage on the IP forwarding plane. It only adds > baggage and complexity to no net value. I require things like liberal > label retention, supporting additional protocols (LDP), and lots of > extra logic on the node to approach the reliability that IP routing by > itself would be capable of without MPLS. This is because it adds steps > after routing convergence so that MPLS can configure the forwarding > table to mimic what the routing protocols have told it and that may > include having to solicit new labels from neighbors, or remebering a lot > of extra labels it would not otherwise need "just in case". Actually there are other things you can do with "just" LDP that you can't do with IP. 1) draft-martini etc. Sure, IP equivalents of this are now being defined (UTI^H^H^H L2TPv3 et al) but they aren't as widely available, and are much less efficient encapsulation-wise (as they require an IP header plus a tunnel header instead of a couple of labels). 2) MPLS VPN (RFC2547). I won't go into the pros and cons of this right now ;-) 3) BGP free network core. This may improve stability (though there's certainly a strong argument that BGP is less destabilising than LDP right now) and security (the core doesn't need to know how to get to the Internet.) Also this allows you to layer multiple distinct IP backbones over one MPLS core. > It is when I get into topology manipulation independent of dynamic IP > routing that MPLS starts to add value and to claim this is not > connection oriented use of MPLS forwarding IMHO smacks of the same > "tunnel"/"layer" semantic debate that can also be said to waste much time. this is your view. And it is certainly one view. But it isn't necessarily the only valid view ;-) > I would also similarly invert the "saddled with CO mechanisms" statement > as it would appear that bringing some CO properties to IP is what MPLS > is all about. Otherwise IP without MPLS would be just fine.... again, some may differ on this. Giles > cheers > Dave > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Tuesday, March 05, 2002 9:52 AM > > To: Shahram Davari > > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > > Subject: Re: draft-bonica-tunneltrace-02 > > > > > > > > Shahram> What is the difference between ATM, FR, or any CO > > technology and > > Shahram> MPLS > > > > Well, for one thing, MPLS isn't a CO technology. It's got > > lots of stuff > > that doesn't really make sense from a CO perspective. Of > > course, when the > > CO guys run across these features (multipoint-to-point, > > php, liberal > > retention, independent mode, equal cost load balancing, > > dynamic rerouting > > with no signaling, ttl, lack of packet sequencing, IP > > control plane, etc., > > etc.) they assume that those features are there by mistake! > > > > This misconception that MPLS is a CO technology, shared > > as it is by the > > "pure IP" crowd and by the ITU/ATM crowd, is the source > > of much wasted > > time. > > > > MPLS is actually an IP-derived technology that facilitates > > the application > > of certain circuit-like characteristics to IP > > networks. As an IP > > technology, the usual IP diagnostic tools, such as ping > > and traceroute, > > should be applicable. That's what this whole useless > > discussion is about. > > One the one side are people who think that IP networks > > are inherently > > unmanageable (after all, they don't follow ITU standards), > > and on the other > > side are people who think that the IP-based paradigms are the best. > > > > It is true that MPLS can be used to provide something which > > is very like a > > CO network, but it doesn't have to be used this way, and > > usually isn't. > > Those of use who are not particularly interested in CO > > networks just don't > > want to be saddled with the legacy CO mechanisms. > > Presumably, if all these > > legacy CO mechanisms were so great there would not be such > > a great rush to > > IP. > > > > > > > > > > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 08:03:46 -0800 Message-Id: <200203051603.g25G3GT04610@merlot.juniper.net> To: Loa Andersson cc: "Lazer, Monica A, ALCNS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Ash, Gerald R (Jerry), ALASO" Subject: Re: WG document status MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36131.1015344196.1@juniper.net> Date: Tue, 05 Mar 2002 08:03:16 -0800 From: Yakov Rekhter Loa, > hopefully someone can shed light on this, there seems to be a > contradiction somewhere, if "general" is intended to be understood > as applicable to Proposed, Draft and Standard equally, what is > the reason to have lesser requirements for Proposed and Draft. > > Or is that "general" is something that the end result and the "steps" > in 1264 is what we have to achieve on our way there? the latter. > For PS there is a requirement of at least two independently written > implementations, but not on interoperability? Is that it? Quoting from rfc1264: 4.0 Requirements for Proposed Standard ..... 4) One or more implementations must exist. It said quite clear that *one*, not "at least two" implementations is sufficient for a Proposed Standard. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:58:36 -0800 Message-Id: <200203051557.g25FvbT04345@merlot.juniper.net> To: "Lazer, Monica A, ALCNS" cc: "Yakov Rekhter" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Ash, Gerald R (Jerry), ALASO" Subject: Re: WG document status MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <34663.1015343857.1@juniper.net> Date: Tue, 05 Mar 2002 07:57:37 -0800 From: Yakov Rekhter Monica, > Yakov, > Bert, > > > > Please note that in the RTG area (rfc1264) there is no requirement > > > for a Proposed Standard to have (a) more than one implementation, and > > > (b) for these implementations to be interoperable. > > > Nowhere in the above there is a requirement for multiple interoperable > > implementations. With this in mind, please take out the part about > > "interoperability test results". > > RFC 1264 also says: > > "3.0 General Requirements > > 4) Generally, a number of interoperable implementations must > exist. At least two must be written independently. > > 5.0 Requirements for Draft Standard > > 3) Two or more interoperable implementations must exist. At least > two must be written independently. > > 6.0 Requirements for Standard > > 3) Three or more interoperable implementations must exist. At least > two must be written independently." > > We would like to insist on 2 or more interoperable implementations being > a requirement. Without interoperability, any proprietary protocol does > just the same, so we don't need an RFC for that. According to the IETF Standard Process for routing "two or more interoperable implementations must exist" when a protocol is advanced from a Proposed Standard to a Draft Standard, but this is *not* required when a protocol goes into a Proposed Standard. If the "we" that you referring to in the above don't like this, then the "we" need to work on changing the rules of the IETF Standard Process. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:47:42 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5EA@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 07:46:48 -0800 MIME-Version: 1.0 Content-Type: text/plain Eric, > I don't agree that "backward compatibility" is a > requirement. There's > nothing inherently wrong with a tool that requires support > in the backbone > for it to achieve its full effect. By backward compatibility I mean: "No wrong action (or mis-interpretation) would take place if a node does not support the trace-route." Therefore requiring support in the entire backbone is fine, and has nothing to do with backward compatibility, as long as the application is designed properly. > > The problem with "simplicity" as a requirement is that it is > not objective. > I've never seen a dispute in which the proponents of a > particular proposal > didn't claim that their proposal is simple and all other > proposals are > nightmarishly complicated. I agree with you that simplicity is subjective. But my point was more of the following nature: "A simpler protocol is preferred against a complex protocol". Off course if there is only one proposal, then this requirement won't be applied. -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:26:36 -0800 Message-ID: <3C84E38B.9040106@utfors.se> Date: Tue, 05 Mar 2002 16:26:03 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: "Lazer, Monica A, ALCNS" CC: Yakov Rekhter , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Ash, Gerald R (Jerry), ALASO" Subject: Re: WG document status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit All, hopefully someone can shed light on this, there seems to be a contradiction somewhere, if "general" is intended to be understood as applicable to Proposed, Draft and Standard equally, what is the reason to have lesser requirements for Proposed and Draft. Or is that "general" is something that the end result and the "steps" in 1264 is what we have to achieve on our way there? For PS there is a requirement of at least two independently written implementations, but not on interoperability? Is that it? /Loa Lazer, Monica A, ALCNS wrote: > Yakov, > Bert, > > >>>Please note that in the RTG area (rfc1264) there is no requirement >>>for a Proposed Standard to have (a) more than one implementation, and >>>(b) for these implementations to be interoperable. >>> > >>Nowhere in the above there is a requirement for multiple interoperable >>implementations. With this in mind, please take out the part about >>"interoperability test results". >> > > RFC 1264 also says: > > "3.0 General Requirements > > 4) Generally, a number of interoperable implementations must > exist. At least two must be written independently. > > 5.0 Requirements for Draft Standard > > 3) Two or more interoperable implementations must exist. At least > two must be written independently. > > 6.0 Requirements for Standard > > 3) Three or more interoperable implementations must exist. At least > two must be written independently." > > We would like to insist on 2 or more interoperable implementations being a requirement. Without interoperability, any proprietary protocol does just the same, so we don't need an RFC for that. > > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > (908) 234 8462 > mlazer@att.com > > > > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:18:07 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD340215C0A9@zcard0ka.ca.nortel.com> From: "David Allan" To: erosen@cisco.com, Shahram Davari Cc: "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 10:17:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C458.E90157B0" 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_01C1C458.E90157B0 Content-Type: text/plain; charset="iso-8859-1" Eric: I would phrase it differently. MPLS has a dual nature which tends to be a function of the control plane used. Most of what you describe as non-CO stuff permits LSPs to mimic the topology generated by IP routing with as ruthlessly simple an implementation as possible, and that's OK, that was a design goal. However if that were the only application of MPLS, I would delegate it to being a useless appendage on the IP forwarding plane. It only adds baggage and complexity to no net value. I require things like liberal label retention, supporting additional protocols (LDP), and lots of extra logic on the node to approach the reliability that IP routing by itself would be capable of without MPLS. This is because it adds steps after routing convergence so that MPLS can configure the forwarding table to mimic what the routing protocols have told it and that may include having to solicit new labels from neighbors, or remebering a lot of extra labels it would not otherwise need "just in case". It is when I get into topology manipulation independent of dynamic IP routing that MPLS starts to add value and to claim this is not connection oriented use of MPLS forwarding IMHO smacks of the same "tunnel"/"layer" semantic debate that can also be said to waste much time. I would also similarly invert the "saddled with CO mechanisms" statement as it would appear that bringing some CO properties to IP is what MPLS is all about. Otherwise IP without MPLS would be just fine.... cheers Dave > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, March 05, 2002 9:52 AM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; ccamp@ops.ietf.org > Subject: Re: draft-bonica-tunneltrace-02 > > > > Shahram> What is the difference between ATM, FR, or any CO > technology and > Shahram> MPLS > > Well, for one thing, MPLS isn't a CO technology. It's got > lots of stuff > that doesn't really make sense from a CO perspective. Of > course, when the > CO guys run across these features (multipoint-to-point, > php, liberal > retention, independent mode, equal cost load balancing, > dynamic rerouting > with no signaling, ttl, lack of packet sequencing, IP > control plane, etc., > etc.) they assume that those features are there by mistake! > > This misconception that MPLS is a CO technology, shared > as it is by the > "pure IP" crowd and by the ITU/ATM crowd, is the source > of much wasted > time. > > MPLS is actually an IP-derived technology that facilitates > the application > of certain circuit-like characteristics to IP > networks. As an IP > technology, the usual IP diagnostic tools, such as ping > and traceroute, > should be applicable. That's what this whole useless > discussion is about. > One the one side are people who think that IP networks > are inherently > unmanageable (after all, they don't follow ITU standards), > and on the other > side are people who think that the IP-based paradigms are the best. > > It is true that MPLS can be used to provide something which > is very like a > CO network, but it doesn't have to be used this way, and > usually isn't. > Those of use who are not particularly interested in CO > networks just don't > want to be saddled with the legacy CO mechanisms. > Presumably, if all these > legacy CO mechanisms were so great there would not be such > a great rush to > IP. > > > > > > ------_=_NextPart_001_01C1C458.E90157B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

Eric:

I would phrase it differently. MPLS has a dual nature = which tends to be a function of the control plane used.

Most of what you describe as non-CO stuff permits = LSPs to mimic the topology generated by IP routing with as ruthlessly = simple an implementation as possible, and that's OK, that was a design = goal.

However if that were the only application of MPLS, I = would delegate it to being a useless appendage on the IP forwarding = plane. It only adds baggage and complexity to no net value. I require = things like liberal label retention, supporting additional protocols = (LDP), and lots of extra logic on the node to approach the reliability = that IP routing by itself would be capable of without MPLS. This is = because it adds steps after routing convergence so that MPLS can = configure the forwarding table to mimic what the routing protocols have = told it and that may include having to solicit new labels from = neighbors, or remebering a lot of extra labels it would not otherwise = need "just in case".

It is when I get into topology manipulation = independent of dynamic IP routing that MPLS starts to add value and to = claim this is not connection oriented use of MPLS forwarding IMHO = smacks of the same "tunnel"/"layer" semantic debate = that can also be said to waste much time.

I would also similarly invert the "saddled with = CO mechanisms" statement as it would appear that bringing some CO = properties to IP is what MPLS is all about. Otherwise IP without MPLS = would be just fine....

cheers
Dave

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Tuesday, March 05, 2002 9:52 AM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; = ccamp@ops.ietf.org
> Subject: Re: draft-bonica-tunneltrace-02 =
>
>
>
> Shahram> What is  the difference = between ATM,  FR, or any  CO
> technology and
> Shahram> MPLS
>
> Well, for  one thing, MPLS  isn't a = CO  technology.  It's got
> lots  of stuff
> that doesn't really  make sense from a CO = perspective.   Of
> course, when the
> CO  guys  run  across  = these  features  (multipoint-to-point,
>  php,  liberal
> retention, independent  mode, equal  = cost load balancing, 
> dynamic rerouting
> with no signaling,  ttl, lack of packet = sequencing,  IP
> control plane, etc.,
> etc.) they assume that those features are there = by mistake!
>
> This misconception  that MPLS  is a = CO  technology, shared 
> as it is  by the
> "pure  IP" crowd and  by = the  ITU/ATM crowd,  is the  source
> of  much wasted
> time. 
>
> MPLS is  actually an IP-derived technology = that  facilitates
> the application
> of  certain   circuit-like  = characteristics  to  IP 
> networks.    As  an  = IP
> technology,  the usual  IP = diagnostic  tools, such  as ping 
> and traceroute,
> should be applicable.   That's what = this whole useless 
> discussion is about.
> One  the one  side are  = people  who think  that IP  networks
> are  inherently
> unmanageable (after all, they don't  = follow ITU standards),
> and on the other
> side are people who think that the IP-based = paradigms are the best.
>
> It is true that  MPLS can be used to = provide something  which
> is very like a
> CO network,  but it  doesn't have = to  be used  this way, and 
> usually isn't.
> Those of use  who are not particularly = interested in  CO
> networks just don't
> want to be saddled with the  legacy CO = mechanisms. 
> Presumably, if all these
> legacy CO mechanisms were  so great there = would not be such 
> a great rush to
> IP.
>
>
>
>
>
>

------_=_NextPart_001_01C1C458.E90157B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:15:36 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 07:15:05 -0800 MIME-Version: 1.0 Content-Type: text/plain Eric, > Shahram> 2) TTL expired user packets will now be forwarded to > UDP module > Shahram> instead of being dropped. Which could overload > the UDP module in > Shahram> certain situations. > > TTL-expired user packets are not simply dropped today; they > are forwarded to > the ICMP module to cause the generation of an ICMP message. > Usually there > is some sort of limit placed on the number of packets that > can be queued for > ICMP processing, or the number of such packets that can be > seen in a given > amount of time, etc. The marginal overhead to see whether > a packet that > makes it through to ICMP processing is a GTTP packet doesn't > seem like that > big a deal. > What about the TTL expired MPLS packets? Should it be forwarded to the ICMP module too? How does the system find that this is a GTTP packet or a user packet (consider non-IP user payload)? -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:14:29 -0800 Message-ID: <3C84E108.8090503@juniper.net> Date: Tue, 05 Mar 2002 07:15:20 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: "Cuevas, Enrique G, ALASO" CC: "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The proposed stuff: - a tool that can "ping" through a LSP, - a tool that can do traceroute to a LSP - a set of MIBs that can provide info on data traffic. They are not some projects dreamt by some bored developers. They are required by our customers. Now, as a person who works for a provider, would you please forget about XUZ standard from XYZ organization for a moment, :-) and tell us what other functionality that we should consider? Thank you! - Ping Cuevas, Enrique G, ALASO wrote: > Tom, > Could you provide us with a matrix (comply/does not comply) of the tools you are talking > about vs. the requirements given in Y.1710? > > Enrique Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:04:13 -0800 content-class: urn:content-classes:message Subject: RE: WG document status Date: Tue, 5 Mar 2002 10:03:11 -0500 Message-ID: <35BD167AAD17F34F84B265D795185567E886C6@OCCLUST03EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RE: WG document status Thread-Index: AcHEVt3e1tRuJY2vR/eXUqyaLXb2FA== From: "Lazer, Monica A, ALCNS" To: "Yakov Rekhter" , "Wijnen, Bert (Bert)" Cc: , "Lazer, Monica A, ALCNS" , "Brungard, Deborah A, ALASO" , "Afferton, Thomas S (Tom), ALCNS" , "Brungard, Deborah A, ALASO" , "Ash, Gerald R (Jerry), ALASO" Yakov, Bert, > > Please note that in the RTG area (rfc1264) there is no requirement > > for a Proposed Standard to have (a) more than one implementation, = and > > (b) for these implementations to be interoperable. > Nowhere in the above there is a requirement for multiple interoperable > implementations. With this in mind, please take out the part about > "interoperability test results". RFC 1264 also says: "3.0 General Requirements 4) Generally, a number of interoperable implementations must exist. At least two must be written independently. 5.0 Requirements for Draft Standard 3) Two or more interoperable implementations must exist. At least two must be written independently. 6.0 Requirements for Standard 3) Three or more interoperable implementations must exist. At least two must be written independently." We would like to insist on 2 or more interoperable implementations being = a requirement. Without interoperability, any proprietary protocol does = just the same, so we don't need an RFC for that. Monica A. Lazer Advanced Transport Technology and Architecture Planning (908) 234 8462 mlazer@att.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 07:03:02 -0800 Message-Id: <200203051502.KAA05406@erosen-u10.cisco.com> To: Shahram Davari cc: "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Mar 2002 10:02:41 -0500 From: Eric Rosen SHahram> 2) Add backward compatibility, simplicity and scalability as SHahram> requirements. I don't agree that "backward compatibility" is a requirement. There's nothing inherently wrong with a tool that requires support in the backbone for it to achieve its full effect. The problem with "simplicity" as a requirement is that it is not objective. I've never seen a dispute in which the proponents of a particular proposal didn't claim that their proposal is simple and all other proposals are nightmarishly complicated. Scalability is also useless as a requirement unless we specify the particular set of dimensions that we think should be able to increase without impacting the usefulness of the scheme. Different opinions as to what these dimensions are often lead to endless disputes about whether a particular scheme is scalable or not. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 06:52:15 -0800 Message-Id: <200203051451.JAA04920@erosen-u10.cisco.com> To: Shahram Davari cc: "'Thomas D. Nadeau'" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Mar 2002 09:51:57 -0500 From: Eric Rosen Shahram> What is the difference between ATM, FR, or any CO technology and Shahram> MPLS Well, for one thing, MPLS isn't a CO technology. It's got lots of stuff that doesn't really make sense from a CO perspective. Of course, when the CO guys run across these features (multipoint-to-point, php, liberal retention, independent mode, equal cost load balancing, dynamic rerouting with no signaling, ttl, lack of packet sequencing, IP control plane, etc., etc.) they assume that those features are there by mistake! This misconception that MPLS is a CO technology, shared as it is by the "pure IP" crowd and by the ITU/ATM crowd, is the source of much wasted time. MPLS is actually an IP-derived technology that facilitates the application of certain circuit-like characteristics to IP networks. As an IP technology, the usual IP diagnostic tools, such as ping and traceroute, should be applicable. That's what this whole useless discussion is about. One the one side are people who think that IP networks are inherently unmanageable (after all, they don't follow ITU standards), and on the other side are people who think that the IP-based paradigms are the best. It is true that MPLS can be used to provide something which is very like a CO network, but it doesn't have to be used this way, and usually isn't. Those of use who are not particularly interested in CO networks just don't want to be saddled with the legacy CO mechanisms. Presumably, if all these legacy CO mechanisms were so great there would not be such a great rush to IP. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 06:49:37 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 06:48:15 -0800 MIME-Version: 1.0 Content-Type: text/plain Tom, Let's stick to the principles. A requirement draft, should set the stage for multiple competing proposals, so that the WG could choose from. Adding protocol requirements that are reverse engineered from a single solution, violates this basic principle. I understand your point, that a solution that presumably works has been developed, and it would be costly for you to replace it. But such a cost should be expected when one develops a proprietary or pre-standard solution. Besides removing the protocol requirements, will not disqualify your solution. Yours, -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, March 04, 2002 5:47 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > >Thanks for your positive response. With regards to the > protocol requirements, > >which ones do you think MUST be there and why? > > I think that the protocol requirements for those > solutions that > currently > exist should be in there. I understand your point about > reverse engineering the tools, but unfortunately the > requirement writing effort > started after we had some solutions working. Therefore > protocol requirements > do matter because they support the tools/mechanisms that work > today. No > need to obviate those things at this point. > > >In my view protocol requirements should not unnecessarily > restrict the > >solution, > >unless they violate application requirements. > > I think that protocol requirements should be in line > with the > application > requirements that have come from operational folks working at > SPs. However, > application requirements should fit within existing protocols > as much as > possible (to promote reuse of existing software/tools). We should not > be forced to reinvent the wheel just for the sake of doing so. > > --Tom > > > > >-Shahram > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Monday, March 04, 2002 4:25 PM > > > To: Shahram Davari > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > >I think instead of debating whether Y.1711 is better than > > > LSP-ping/GTTP or > > > >vice versa, it would be more > > > >constructive to identify and document the applicability of > > > each proposal > > > >for various tunneling applications. > > > > > > This sounds like a move in the right direction. > > > > > > >For this particular draft my suggestion at this stage is > > > that the Bonica's > > > >requirement draft be revised to: > > > > > > > >1) Add text (or at least a place holder) for additional > > > security issues > > > >raised on the list. > > > >2) Add backward compatibility, simplicity and scalability as > > > requirements. > > > > > > I can go along with those. > > > > > > >3) Remove the protocol requirements section, since any > > > requirement here > > > >will be viewed as a reverse engineering of some solution. > > > > > > Although this might sound reasonable to some, I > > > think that some > > > may object to this > > > since the protocol requirements are viewed by some as > > > fundamental to the > > > requirements > > > of any particular solution. In the flurry of emails on the > > > topic, I have > > > not been able to > > > keep track of what the consensus on this might be (either > > > way). Perhaps Ron > > > has been keeping > > > track? > > > > > > >Then any offered solution should have text to show to what > > > extent they > > > >fulfill the > > > >requirements, and what is their applicability and restrictions. > > > > > > Sounds reasonable. > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > Mathematics is the supreme nostalgia of our time. > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 06:36:57 -0800 content-class: urn:content-classes:message Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 09:35:17 -0500 Message-ID: <28F05913385EAC43AF019413F674A017016DAB64@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-bonica-tunneltrace-02 Thread-Index: AcHET2Zj//ujFPkERgWJzyN80MtRGwAAwLKA From: "Cuevas, Enrique G, ALASO" To: "Thomas D. Nadeau" , "David Allan" Cc: "Shahram Davari" , Tom, Could you provide us with a matrix (comply/does not comply) of the tools = you are talking about vs. the requirements given in Y.1710? Enrique _______________ ecuevas@att.com Tel. (732)-420-3252 >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Tuesday, March 05, 2002 9:07 AM >To: David Allan >Cc: Shahram Davari; ccamp@ops.ietf.org >Subject: RE: draft-bonica-tunneltrace-02=20 > > > > >>Your statement that requirements support the tools/mechanisms=20 >that work=20 >>today is the nib of my concern. Basically the requirments step is=20 >>redundant at that point. We are now in a tight embrace where the=20 >>requirements justify the solution and the solution dictates the=20 >>requirements. Suggesting the requirements is a WG work item=20 >would appear=20 >>to be an oxymoron. > > As I mentioned, some of the tools have already been worked >out, so yes, the cart is before the horse in some cases. However, >I don't think that this is necessarily a problem. > > --Tom > > > >>Dave >> >> > -----Original Message----- >> > From: Thomas D. Nadeau=20 >> [mailto:tnadeau@cisco.com] >> > Sent: Monday, March 04, 2002 5:47 PM >> > To: Shahram Davari >> > Cc: ccamp@ops.ietf.org >> > Subject: RE: draft-bonica-tunneltrace-02 >> > >> > >> > >> > >Thanks for your positive response. With regards to the >> > protocol requirements, >> > >which ones do you think MUST be there and why? >> > >> > I think that the protocol requirements for those >> > solutions that >> > currently >> > exist should be in there. I understand your point about >> > reverse engineering the tools, but unfortunately the >> > requirement writing effort >> > started after we had some solutions working. Therefore >> > protocol requirements >> > do matter because they support the tools/mechanisms that work >> > today. No >> > need to obviate those things at this point. >> > >> > >In my view protocol requirements should not unnecessarily >> > restrict the >> > >solution, >> > >unless they violate application requirements. >> > >> > I think that protocol requirements should be in line >> > with the >> > application >> > requirements that have come from operational folks working at >> > SPs. However, >> > application requirements should fit within existing protocols >> > as much as >> > possible (to promote reuse of existing software/tools). =20 >We should not >> > be forced to reinvent the wheel just for the sake of doing so. >> > >> > --Tom >> > >> > >> > >> > >-Shahram >> > > >> > > > -----Original Message----- >> > > > From: Thomas D. Nadeau=20 >> [mailto:tnadeau@cisco.com] >> > > > Sent: Monday, March 04, 2002 4:25 PM >> > > > To: Shahram Davari >> > > > Cc: ccamp@ops.ietf.org >> > > > Subject: RE: draft-bonica-tunneltrace-02 >> > > > >> > > > >> > > > >> > > > >I think instead of debating whether Y.1711 is better than >> > > > LSP-ping/GTTP or >> > > > >vice versa, it would be more >> > > > >constructive to identify and document the applicability of >> > > > each proposal >> > > > >for various tunneling applications. >> > > > >> > > > This sounds like a move in the right direction. >> > > > >> > > > >For this particular draft my suggestion at this stage is >> > > > that the Bonica's >> > > > >requirement draft be revised to: >> > > > > >> > > > >1) Add text (or at least a place holder) for additional >> > > > security issues >> > > > >raised on the list. >> > > > >2) Add backward compatibility, simplicity and scalability as >> > > > requirements. >> > > > >> > > > I can go along with those. >> > > > >> > > > >3) Remove the protocol requirements section, since any >> > > > requirement here >> > > > >will be viewed as a reverse engineering of some solution. >> > > > >> > > > Although this might sound reasonable to some, I >> > > > think that some >> > > > may object to this >> > > > since the protocol requirements are viewed by some as >> > > > fundamental to the >> > > > requirements >> > > > of any particular solution. In the flurry of emails on the >> > > > topic, I have >> > > > not been able to >> > > > keep track of what the consensus on this might be (either >> > > > way). Perhaps Ron >> > > > has been keeping >> > > > track? >> > > > >> > > > >Then any offered solution should have text to show to what >> > > > extent they >> > > > >fulfill the >> > > > >requirements, and what is their applicability and=20 >restrictions. >> > > > >> > > > Sounds reasonable. >> > > > >> > > > --Tom >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > -------------------------------------------------------------- >> > > > ---------- >> > > > Mathematics is the supreme nostalgia of our time. >> > > > >> > >> > >> > >> > -------------------------------------------------------------- >> > ---------- >> > Mathematics is the supreme nostalgia of our time. >> > >> > >> > > > > >--------------------------------------------------------------- >--------- >Mathematics is the supreme nostalgia of our time.=20 > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 06:11:26 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34020EC7D5@zcard0ka.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" Cc: Shahram Davari , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 09:11:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C44F.98A0A590" 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_01C1C44F.98A0A590 Content-Type: text/plain; charset="iso-8859-1" But the requirements still need to be independent of the solution if they are to be requirements. If the whole goal of this exercise is simply to document a-prioi solutions, then isn't that what informational RFCs are for. Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, March 05, 2002 9:07 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: Shahram Davari; ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > > >Your statement that requirements support the > tools/mechanisms that work > >today is the nib of my concern. Basically the requirments step is > >redundant at that point. We are now in a tight embrace where the > >requirements justify the solution and the solution dictates the > >requirements. Suggesting the requirements is a WG work item > would appear > >to be an oxymoron. > > As I mentioned, some of the tools have already been worked > out, so yes, the cart is before the horse in some cases. However, > I don't think that this is necessarily a problem. > > --Tom > > > > >Dave > > > > > -----Original Message----- > > > From: Thomas D. Nadeau > > [mailto:tnadeau@cisco.com] > > > Sent: Monday, March 04, 2002 5:47 PM > > > To: Shahram Davari > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > >Thanks for your positive response. With regards to the > > > protocol requirements, > > > >which ones do you think MUST be there and why? > > > > > > I think that the protocol requirements for those > > > solutions that > > > currently > > > exist should be in there. I understand your point about > > > reverse engineering the tools, but unfortunately the > > > requirement writing effort > > > started after we had some solutions working. Therefore > > > protocol requirements > > > do matter because they support the tools/mechanisms that work > > > today. No > > > need to obviate those things at this point. > > > > > > >In my view protocol requirements should not unnecessarily > > > restrict the > > > >solution, > > > >unless they violate application requirements. > > > > > > I think that protocol requirements should be in line > > > with the > > > application > > > requirements that have come from operational folks working at > > > SPs. However, > > > application requirements should fit within existing protocols > > > as much as > > > possible (to promote reuse of existing software/tools). > We should not > > > be forced to reinvent the wheel just for the sake of doing so. > > > > > > --Tom > > > > > > > > > > > > >-Shahram > > > > > > > > > -----Original Message----- > > > > > From: Thomas D. Nadeau > > [mailto:tnadeau@cisco.com] > > > > > Sent: Monday, March 04, 2002 4:25 PM > > > > > To: Shahram Davari > > > > > Cc: ccamp@ops.ietf.org > > > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > > > > > > > > > >I think instead of debating whether Y.1711 is better than > > > > > LSP-ping/GTTP or > > > > > >vice versa, it would be more > > > > > >constructive to identify and document the applicability of > > > > > each proposal > > > > > >for various tunneling applications. > > > > > > > > > > This sounds like a move in the right direction. > > > > > > > > > > >For this particular draft my suggestion at this stage is > > > > > that the Bonica's > > > > > >requirement draft be revised to: > > > > > > > > > > > >1) Add text (or at least a place holder) for additional > > > > > security issues > > > > > >raised on the list. > > > > > >2) Add backward compatibility, simplicity and scalability as > > > > > requirements. > > > > > > > > > > I can go along with those. > > > > > > > > > > >3) Remove the protocol requirements section, since any > > > > > requirement here > > > > > >will be viewed as a reverse engineering of some solution. > > > > > > > > > > Although this might sound reasonable to some, I > > > > > think that some > > > > > may object to this > > > > > since the protocol requirements are viewed by some as > > > > > fundamental to the > > > > > requirements > > > > > of any particular solution. In the flurry of emails on the > > > > > topic, I have > > > > > not been able to > > > > > keep track of what the consensus on this might be (either > > > > > way). Perhaps Ron > > > > > has been keeping > > > > > track? > > > > > > > > > > >Then any offered solution should have text to show to what > > > > > extent they > > > > > >fulfill the > > > > > >requirements, and what is their applicability and > restrictions. > > > > > > > > > > Sounds reasonable. > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > Mathematics is the supreme nostalgia of our time. > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > Mathematics is the supreme nostalgia of our time. > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > ------_=_NextPart_001_01C1C44F.98A0A590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

But the requirements still need to be independent of = the solution if they are to be requirements. If the whole goal of this = exercise is simply to document a-prioi solutions, then isn't that what = informational RFCs are for.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, March 05, 2002 9:07 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Shahram Davari; ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 =
>
>
>
>
> >Your statement that requirements support = the
> tools/mechanisms that work
> >today is the nib of my concern. Basically = the requirments step is
> >redundant at that point. We are now in a = tight embrace where the
> >requirements justify the solution and the = solution dictates the
> >requirements. Suggesting the requirements = is a WG work item
> would appear
> >to be an oxymoron.
>
>          As = I mentioned, some of the tools have already been worked
> out, so yes, the cart is before the horse in = some cases. However,
> I don't think that this is necessarily a = problem.
>
>          = --Tom
>
>
>
> >Dave
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau
> > [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> > > Sent: Monday, March 04, 2002 5:47 = PM
> > > To: Shahram Davari
> > > Cc: ccamp@ops.ietf.org
> > > Subject: RE: = draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > >Thanks for your positive = response. With regards to the
> > > protocol requirements,
> > > >which ones do you think MUST be = there and why?
> > >
> > = >          I think that = the protocol requirements for those
> > > solutions that
> > > currently
> > > exist should be in there.  I = understand your point about
> > > reverse engineering the tools, but = unfortunately the
> > > requirement writing effort
> > > started after we had some solutions = working. Therefore
> > > protocol requirements
> > > do matter because they support the = tools/mechanisms that work
> > > today. No
> > > need to obviate those things at this = point.
> > >
> > > >In my view protocol requirements = should not unnecessarily
> > > restrict the
> > > >solution,
> > > >unless they violate application = requirements.
> > >
> > = >          I think that = protocol requirements should be in line
> > > with the
> > > application
> > > requirements that have come from = operational folks working at
> > > SPs.  However,
> > > application requirements should fit = within existing protocols
> > > as much as
> > > possible (to promote reuse of = existing software/tools). 
> We should not
> > > be forced to reinvent the wheel just = for the sake of doing so.
> > >
> > = >          --Tom
> > >
> > >
> > >
> > > >-Shahram
> > > >
> > > > > -----Original = Message-----
> > > > > From: Thomas D. Nadeau =
> > [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> > > > > Sent: Monday, March 04, = 2002 4:25 PM
> > > > > To: Shahram Davari
> > > > > Cc: = ccamp@ops.ietf.org
> > > > > Subject: RE: = draft-bonica-tunneltrace-02
> > > > >
> > > > >
> > > > >
> > > > > >I think instead of = debating whether Y.1711 is better than
> > > > > LSP-ping/GTTP or
> > > > > >vice versa, it would be = more
> > > > > >constructive to = identify and document the applicability of
> > > > > each proposal
> > > > > >for various tunneling = applications.
> > > > >
> > > > = >          This sounds = like a move in the right direction.
> > > > >
> > > > > >For this particular = draft my suggestion at this stage is
> > > > > that the Bonica's
> > > > > >requirement draft be = revised to:
> > > > > >
> > > > > >1) Add text (or at = least a place holder) for additional
> > > > > security issues
> > > > > >raised on the = list.
> > > > > >2) Add backward = compatibility, simplicity and scalability as
> > > > > requirements.
> > > > >
> > > > = >          I can go = along with those.
> > > > >
> > > > > >3) Remove the protocol = requirements section, since any
> > > > > requirement here
> > > > > >will be viewed as a = reverse engineering of some solution.
> > > > >
> > > > = >          Although = this might sound reasonable to some, I
> > > > > think that some
> > > > > may object to this
> > > > > since the protocol = requirements are viewed by some as
> > > > > fundamental to the
> > > > > requirements
> > > > > of any particular = solution.  In the flurry of emails on the
> > > > > topic, I have
> > > > > not been able to
> > > > > keep track of what the = consensus on this might be (either
> > > > > way). Perhaps Ron
> > > > > has been keeping
> > > > > track?
> > > > >
> > > > > >Then any offered = solution should have text to show to what
> > > > > extent they
> > > > > >fulfill the
> > > > > >requirements, and what = is their applicability and
> restrictions.
> > > > >
> > > > = >          Sounds = reasonable.
> > > > >
> > > > = >          --Tom
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > = --------------------------------------------------------------
> > > > > ----------
> > > > > Mathematics is the supreme = nostalgia of our time.
> > > > >
> > >
> > >
> > >
> > > = --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia = of our time.
> > >
> > >
> > >
>
>
>
> = --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our = time.
>
>

------_=_NextPart_001_01C1C44F.98A0A590-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 06:08:09 -0800 Message-Id: <4.3.2.7.2.20020305090557.01d2d140@161.44.167.72> Date: Tue, 05 Mar 2002 09:06:58 -0500 To: "David Allan" From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: Shahram Davari , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Your statement that requirements support the tools/mechanisms that work >today is the nib of my concern. Basically the requirments step is >redundant at that point. We are now in a tight embrace where the >requirements justify the solution and the solution dictates the >requirements. Suggesting the requirements is a WG work item would appear >to be an oxymoron. As I mentioned, some of the tools have already been worked out, so yes, the cart is before the horse in some cases. However, I don't think that this is necessarily a problem. --Tom >Dave > > > -----Original Message----- > > From: Thomas D. Nadeau > [mailto:tnadeau@cisco.com] > > Sent: Monday, March 04, 2002 5:47 PM > > To: Shahram Davari > > Cc: ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > >Thanks for your positive response. With regards to the > > protocol requirements, > > >which ones do you think MUST be there and why? > > > > I think that the protocol requirements for those > > solutions that > > currently > > exist should be in there. I understand your point about > > reverse engineering the tools, but unfortunately the > > requirement writing effort > > started after we had some solutions working. Therefore > > protocol requirements > > do matter because they support the tools/mechanisms that work > > today. No > > need to obviate those things at this point. > > > > >In my view protocol requirements should not unnecessarily > > restrict the > > >solution, > > >unless they violate application requirements. > > > > I think that protocol requirements should be in line > > with the > > application > > requirements that have come from operational folks working at > > SPs. However, > > application requirements should fit within existing protocols > > as much as > > possible (to promote reuse of existing software/tools). We should not > > be forced to reinvent the wheel just for the sake of doing so. > > > > --Tom > > > > > > > > >-Shahram > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau > [mailto:tnadeau@cisco.com] > > > > Sent: Monday, March 04, 2002 4:25 PM > > > > To: Shahram Davari > > > > Cc: ccamp@ops.ietf.org > > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > > > > > >I think instead of debating whether Y.1711 is better than > > > > LSP-ping/GTTP or > > > > >vice versa, it would be more > > > > >constructive to identify and document the applicability of > > > > each proposal > > > > >for various tunneling applications. > > > > > > > > This sounds like a move in the right direction. > > > > > > > > >For this particular draft my suggestion at this stage is > > > > that the Bonica's > > > > >requirement draft be revised to: > > > > > > > > > >1) Add text (or at least a place holder) for additional > > > > security issues > > > > >raised on the list. > > > > >2) Add backward compatibility, simplicity and scalability as > > > > requirements. > > > > > > > > I can go along with those. > > > > > > > > >3) Remove the protocol requirements section, since any > > > > requirement here > > > > >will be viewed as a reverse engineering of some solution. > > > > > > > > Although this might sound reasonable to some, I > > > > think that some > > > > may object to this > > > > since the protocol requirements are viewed by some as > > > > fundamental to the > > > > requirements > > > > of any particular solution. In the flurry of emails on the > > > > topic, I have > > > > not been able to > > > > keep track of what the consensus on this might be (either > > > > way). Perhaps Ron > > > > has been keeping > > > > track? > > > > > > > > >Then any offered solution should have text to show to what > > > > extent they > > > > >fulfill the > > > > >requirements, and what is their applicability and restrictions. > > > > > > > > Sounds reasonable. > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > Mathematics is the supreme nostalgia of our time. > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > > > > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Mar 2002 05:42:12 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34020EC710@zcard0ka.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" , Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 5 Mar 2002 08:36:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C44A.CFA8BA50" 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_01C1C44A.CFA8BA50 Content-Type: text/plain; charset="iso-8859-1" Tom: Your statement that requirements support the tools/mechanisms that work today is the nib of my concern. Basically the requirments step is redundant at that point. We are now in a tight embrace where the requirements justify the solution and the solution dictates the requirements. Suggesting the requirements is a WG work item would appear to be an oxymoron. Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, March 04, 2002 5:47 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > >Thanks for your positive response. With regards to the > protocol requirements, > >which ones do you think MUST be there and why? > > I think that the protocol requirements for those > solutions that > currently > exist should be in there. I understand your point about > reverse engineering the tools, but unfortunately the > requirement writing effort > started after we had some solutions working. Therefore > protocol requirements > do matter because they support the tools/mechanisms that work > today. No > need to obviate those things at this point. > > >In my view protocol requirements should not unnecessarily > restrict the > >solution, > >unless they violate application requirements. > > I think that protocol requirements should be in line > with the > application > requirements that have come from operational folks working at > SPs. However, > application requirements should fit within existing protocols > as much as > possible (to promote reuse of existing software/tools). We should not > be forced to reinvent the wheel just for the sake of doing so. > > --Tom > > > > >-Shahram > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Monday, March 04, 2002 4:25 PM > > > To: Shahram Davari > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > >I think instead of debating whether Y.1711 is better than > > > LSP-ping/GTTP or > > > >vice versa, it would be more > > > >constructive to identify and document the applicability of > > > each proposal > > > >for various tunneling applications. > > > > > > This sounds like a move in the right direction. > > > > > > >For this particular draft my suggestion at this stage is > > > that the Bonica's > > > >requirement draft be revised to: > > > > > > > >1) Add text (or at least a place holder) for additional > > > security issues > > > >raised on the list. > > > >2) Add backward compatibility, simplicity and scalability as > > > requirements. > > > > > > I can go along with those. > > > > > > >3) Remove the protocol requirements section, since any > > > requirement here > > > >will be viewed as a reverse engineering of some solution. > > > > > > Although this might sound reasonable to some, I > > > think that some > > > may object to this > > > since the protocol requirements are viewed by some as > > > fundamental to the > > > requirements > > > of any particular solution. In the flurry of emails on the > > > topic, I have > > > not been able to > > > keep track of what the consensus on this might be (either > > > way). Perhaps Ron > > > has been keeping > > > track? > > > > > > >Then any offered solution should have text to show to what > > > extent they > > > >fulfill the > > > >requirements, and what is their applicability and restrictions. > > > > > > Sounds reasonable. > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > Mathematics is the supreme nostalgia of our time. > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > > ------_=_NextPart_001_01C1C44A.CFA8BA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

Tom:

Your statement that requirements support the = tools/mechanisms that work today is the nib of my concern. Basically = the requirments step is redundant at that point. We are now in a tight = embrace where the requirements justify the solution and the solution = dictates the requirements. Suggesting the requirements is a WG work = item would appear to be an oxymoron.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Monday, March 04, 2002 5:47 PM
> To: Shahram Davari
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 =
>
>
>
> >Thanks for your positive response. With = regards to the
> protocol requirements,
> >which ones do you think MUST be there and = why?
>
>          I = think that the protocol requirements for those
> solutions that
> currently
> exist should be in there.  I understand = your point about
> reverse engineering the tools, but = unfortunately the
> requirement writing effort
> started after we had some solutions working. = Therefore
> protocol requirements
> do matter because they support the = tools/mechanisms that work
> today. No
> need to obviate those things at this = point.
>
> >In my view protocol requirements should not = unnecessarily
> restrict the
> >solution,
> >unless they violate application = requirements.
>
>          I = think that protocol requirements should be in line
> with the
> application
> requirements that have come from operational = folks working at
> SPs.  However,
> application requirements should fit within = existing protocols
> as much as
> possible (to promote reuse of existing = software/tools).  We should not
> be forced to reinvent the wheel just for the = sake of doing so.
>
>          = --Tom
>
>
>
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > Sent: Monday, March 04, 2002 4:25 = PM
> > > To: Shahram Davari
> > > Cc: ccamp@ops.ietf.org
> > > Subject: RE: = draft-bonica-tunneltrace-02
> > >
> > >
> > >
> > > >I think instead of debating = whether Y.1711 is better than
> > > LSP-ping/GTTP or
> > > >vice versa, it would be = more
> > > >constructive to identify and = document the applicability of
> > > each proposal
> > > >for various tunneling = applications.
> > >
> > = >          This sounds = like a move in the right direction.
> > >
> > > >For this particular draft my = suggestion at this stage is
> > > that the Bonica's
> > > >requirement draft be revised = to:
> > > >
> > > >1) Add text (or at least a place = holder) for additional
> > > security issues
> > > >raised on the list.
> > > >2) Add backward compatibility, = simplicity and scalability as
> > > requirements.
> > >
> > = >          I can go = along with those.
> > >
> > > >3) Remove the protocol = requirements section, since any
> > > requirement here
> > > >will be viewed as a reverse = engineering of some solution.
> > >
> > = >          Although = this might sound reasonable to some, I
> > > think that some
> > > may object to this
> > > since the protocol requirements are = viewed by some as
> > > fundamental to the
> > > requirements
> > > of any particular solution.  In = the flurry of emails on the
> > > topic, I have
> > > not been able to
> > > keep track of what the consensus on = this might be (either
> > > way). Perhaps Ron
> > > has been keeping
> > > track?
> > >
> > > >Then any offered solution should = have text to show to what
> > > extent they
> > > >fulfill the
> > > >requirements, and what is their = applicability and restrictions.
> > >
> > = >          Sounds = reasonable.
> > >
> > = >          --Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > > = --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia = of our time.
> > >
>
>
>
> = --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our = time.
>
>
>

------_=_NextPart_001_01C1C44A.CFA8BA50-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 15:04:32 -0800 Message-Id: <4.3.2.7.2.20020304172839.01d2a4f0@161.44.167.72> Date: Mon, 04 Mar 2002 17:47:15 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Thanks for your positive response. With regards to the protocol requirements, >which ones do you think MUST be there and why? I think that the protocol requirements for those solutions that currently exist should be in there. I understand your point about reverse engineering the tools, but unfortunately the requirement writing effort started after we had some solutions working. Therefore protocol requirements do matter because they support the tools/mechanisms that work today. No need to obviate those things at this point. >In my view protocol requirements should not unnecessarily restrict the >solution, >unless they violate application requirements. I think that protocol requirements should be in line with the application requirements that have come from operational folks working at SPs. However, application requirements should fit within existing protocols as much as possible (to promote reuse of existing software/tools). We should not be forced to reinvent the wheel just for the sake of doing so. --Tom >-Shahram > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Monday, March 04, 2002 4:25 PM > > To: Shahram Davari > > Cc: ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > >I think instead of debating whether Y.1711 is better than > > LSP-ping/GTTP or > > >vice versa, it would be more > > >constructive to identify and document the applicability of > > each proposal > > >for various tunneling applications. > > > > This sounds like a move in the right direction. > > > > >For this particular draft my suggestion at this stage is > > that the Bonica's > > >requirement draft be revised to: > > > > > >1) Add text (or at least a place holder) for additional > > security issues > > >raised on the list. > > >2) Add backward compatibility, simplicity and scalability as > > requirements. > > > > I can go along with those. > > > > >3) Remove the protocol requirements section, since any > > requirement here > > >will be viewed as a reverse engineering of some solution. > > > > Although this might sound reasonable to some, I > > think that some > > may object to this > > since the protocol requirements are viewed by some as > > fundamental to the > > requirements > > of any particular solution. In the flurry of emails on the > > topic, I have > > not been able to > > keep track of what the consensus on this might be (either > > way). Perhaps Ron > > has been keeping > > track? > > > > >Then any offered solution should have text to show to what > > extent they > > >fulfill the > > >requirements, and what is their applicability and restrictions. > > > > Sounds reasonable. > > > > --Tom > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 14:25:07 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34020EC439@zcard0ka.ca.nortel.com> From: "David Allan" To: George Swallow Cc: ccamp@ops.ietf.org Subject: RE: Y1711 applicability...was draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 17:23:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C3CB.3BEFC030" 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_01C1C3CB.3BEFC030 Content-Type: text/plain; charset="iso-8859-1" Hi George: > Since the overwhelming majority of MPLS deployed today does not use > explicit routing, this does seriously limit the applicability. Limited applicability does not seem to manifest itself in a corresponding lack of interest. The recovery framework and many drafts have proposed various protection and reliability schemes that presupposed similar functionality. There has been lots of focus on local protection schemes (e.g. bypass tunnels in draft-swallow) that have similar limited applicability. > Further for the explicitly routed p2p case we have a solution that > leverages IP OAM. > Yup, and we've discussed the technical merits endlessly.... rgds Dave ------_=_NextPart_001_01C1C3CB.3BEFC030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Y1711 applicability...was draft-bonica-tunneltrace-02 =

Hi George:

> Since the overwhelming majority of MPLS deployed = today does not use
> explicit routing, this does seriously limit the = applicability.

Limited applicability does not seem to manifest = itself in a corresponding lack of interest. The recovery framework and = many drafts have proposed various protection and reliability schemes = that presupposed similar functionality. There has been lots of focus on = local protection schemes (e.g. bypass tunnels in draft-swallow) that = have similar limited applicability.

> Further for the explicitly routed p2p case we = have a solution that
> leverages IP OAM. 
>
Yup, and we've discussed the technical merits = endlessly....

rgds
Dave

------_=_NextPart_001_01C1C3CB.3BEFC030-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 14:09:09 -0800 Message-Id: <200203042208.RAA06851@telescope.cisco.com> To: "David Allan" cc: ccamp@ops.ietf.org Subject: Re: Y1711 applicability...was draft-bonica-tunneltrace-02 Date: Mon, 04 Mar 2002 17:08:55 -0500 From: George Swallow > Y.1711 simply provides some defect detection/handling tools that can be > implemented on LERs for explicitly routed p2p LSPs regardless of payload, Since the overwhelming majority of MPLS deployed today does not use explicit routing, this does seriously limit the applicability. Further for the explicitly routed p2p case we have a solution that leverages IP OAM. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 14:08:36 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 14:07:52 -0800 MIME-Version: 1.0 Content-Type: text/plain Tom, Thanks for your positive response. With regards to the protocol requirements, which ones do you think MUST be there and why? In my view protocol requirements should not unnecessarily restrict the solution, unless they violate application requirements. -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, March 04, 2002 4:25 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > >I think instead of debating whether Y.1711 is better than > LSP-ping/GTTP or > >vice versa, it would be more > >constructive to identify and document the applicability of > each proposal > >for various tunneling applications. > > This sounds like a move in the right direction. > > >For this particular draft my suggestion at this stage is > that the Bonica's > >requirement draft be revised to: > > > >1) Add text (or at least a place holder) for additional > security issues > >raised on the list. > >2) Add backward compatibility, simplicity and scalability as > requirements. > > I can go along with those. > > >3) Remove the protocol requirements section, since any > requirement here > >will be viewed as a reverse engineering of some solution. > > Although this might sound reasonable to some, I > think that some > may object to this > since the protocol requirements are viewed by some as > fundamental to the > requirements > of any particular solution. In the flurry of emails on the > topic, I have > not been able to > keep track of what the consensus on this might be (either > way). Perhaps Ron > has been keeping > track? > > >Then any offered solution should have text to show to what > extent they > >fulfill the > >requirements, and what is their applicability and restrictions. > > Sounds reasonable. > > --Tom > > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 13:33:38 -0800 Message-Id: <4.3.2.7.2.20020304162133.01f3fa78@161.44.167.72> Date: Mon, 04 Mar 2002 16:25:24 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >I think instead of debating whether Y.1711 is better than LSP-ping/GTTP or >vice versa, it would be more >constructive to identify and document the applicability of each proposal >for various tunneling applications. This sounds like a move in the right direction. >For this particular draft my suggestion at this stage is that the Bonica's >requirement draft be revised to: > >1) Add text (or at least a place holder) for additional security issues >raised on the list. >2) Add backward compatibility, simplicity and scalability as requirements. I can go along with those. >3) Remove the protocol requirements section, since any requirement here >will be viewed as a reverse engineering of some solution. Although this might sound reasonable to some, I think that some may object to this since the protocol requirements are viewed by some as fundamental to the requirements of any particular solution. In the flurry of emails on the topic, I have not been able to keep track of what the consensus on this might be (either way). Perhaps Ron has been keeping track? >Then any offered solution should have text to show to what extent they >fulfill the >requirements, and what is their applicability and restrictions. Sounds reasonable. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 13:22:21 -0800 Message-Id: <4.3.2.7.2.20020304155909.02a23110@mo-ex1> Date: Mon, 04 Mar 2002 16:09:48 -0500 To: "CCAMP" From: Lou Berger Subject: Re: GMPLS Signaling Implementation Survey Form Cc: "Yakov Rekhter" , sob@harvard.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed All, If you'd like to answer this anonymously, please send your results to Scott Bradner (sob@harvard.edu). He'll remove your identify / contact info and forward it along to be included in the survey. Thanks, Lou PS To be included in the first draft of the survey, please have your forms in by COB March 13. At 03:18 PM 3/1/2002, Berger, Lou wrote: >All, > >If you'd like to participate in a GMPLS signaling implementation survey, >please complete (as much as you can/want) and return the enclosed. We will >consolidate all answers and publish the results (to the list and as a draft.) > >Thank you, >Lou (and Yakov) > >---------------------------------- >GMPLS Signaling Implementation Survey Form [V 1.0] > > This is form is derived from V2.2 of the "RSVP and QoS Implementation > Survey Information Form" authored by Gene Gaines > > and Marco Festa . See > >http://www.iit.nrc.ca/IETF/RSVP_survey/rsvp-qos_quest_980210.txt. > > > This form is also available from > >http://www.labn.net/gmpls/sig-survey.txt > >======================================================================= > >1. Organization: > >1.1 Organization url(s): > >2. Product title(s): > >2.1 Brief description(s): > >---------------------------------------------------------------- > >3. Contact for GMPLS information >3.1 Name: > >3.2 Title: > >3.3 E-mail: > >3.4 Organization/department: > >3.5 Postal address: > >3.6 Phone: > >3.7 Fax: >---------------------------------------------------------------- > >4. Status: >4.1 [ ] Development >4.2 [ ] Alpha >4.3 [ ] Beta >4.4 [ ] Product >4.5 [ ] Other (describe): > >5. Switching capabilities >5.1 [ ] PSC >5.2 [ ] TDM >5.3 [ ] LSC >5.4 [ ] FSC > >6. Reference Drafts (please list, include version numbers) >6.1 [ ] >6.2 [ ] >6.3 [ ] >6.4 [ ] >6.5 [ ] >6.6 [ ] > >7. Interface technologies >7.1 [ ] Frame Relay >7.2 [ ] ATM >7.3 [ ] Ethernet V2/DIX >7.4 [ ] Ethernet 802.3 >7.5 [ ] SDH >7.6 [ ] SONET >7.7 [ ] Lambda (photonic) >7.8 [ ] Fiber >7.9 [ ] FiberChannel >7.10 [ ] Other (describe): > >8. Availability >8.1 [ ] Public and free >8.2 [ ] Only to selected organizations/companies but free >8.3 [ ] On sale. >8.4 [ ] For internal company use only >8.5 [ ] Other: > >9. Implementation based on: (check all that apply) >9.1 [ ] Purchased code (please list source if possible) >9.2 [ ] Free code (please list source if possible) >9.3 [ ] Internal implementation (no outside code, just from specs) >9.4 [ ] Internal implementation on top of purchased or free code >9.4.1 [ ] List portions from external source >9.4.2 [ ] List portions developed internally > >10. Supported Label Types >10.1 [ ] MPLS Label >10.2 [ ] Generalized Label >10.3 [ ] Waveband Label >10.4 [ ] SONET/SDH Label > >11. Label Related >11.1 [ ] Suggested Label >11.2 [ ] Label Set > >12. Traffic Parameters >12.1 [ ] Intserv (Please list which) >12.2 [ ] CR-LDP >12.3 [ ] GMPLS Bandwidth Encoding >12.4 [ ] SONET/SDH > >13. [ ] Bidirectional LSPs > >14. Notification >14.1 [ ] Acceptable Label Set >14.2 [ ] Notify Request Objects (GMPLS-RSVP) >14.3 [ ] Notify Message (GMPLS-RSVP) >14.4 [ ] Removing State with a PathErr message (GMPLS-RSVP) > >15 Other features >15.1 [ ] Explicit Label Control >15.2 [ ] Protection Information >15.3 [ ] Administrative Status Information >15.4 [ ] Interface Identification >15.5 [ ] Errored Interface Identification >15.6 [ ] Link Fault Handling >15.7 [ ] Nodal Fault Handling > >16. Other specification(s) which apply: > >17. Other features supported: > >18. Currently-defined GMPLS signaling features not supported: > >19. Notes (please describe purpose of project, give any information that > might be useful to those interested in developing or using GMPLS) > >20. If you feel the above categories are not complete, add others which > will better describe your project: > >======================================================================= > >Person filling out this form: > > Name: > > E-mail: > > Tel.: > > Title: > > Company: > > Date prepared: > >---------------------------------------------------------------- > >Return your information to the authors: > > Lou Berger or and > Yakov Rekhter > > all returned information will be consolidated and reported > to the CCAMP WG mailing list. > >Thank you! > >Updated 03/01/02 > >--end-- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 13:20:25 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 13:18:03 -0800 MIME-Version: 1.0 Content-Type: text/plain Tom, I think instead of debating whether Y.1711 is better than LSP-ping/GTTP or vice versa, it would be more constructive to identify and document the applicability of each proposal for various tunneling applications. For this particular draft my suggestion at this stage is that the Bonica's requirement draft be revised to: 1) Add text (or at least a place holder) for additional security issues raised on the list. 2) Add backward compatibility, simplicity and scalability as requirements. 3) Remove the protocol requirements section, since any requirement here will be viewed as a reverse engineering of some solution. Then any offered solution should have text to show to what extent they fulfill the requirements, and what is their applicability and restrictions. -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Monday, March 04, 2002 1:23 PM > To: 'Thomas D. Nadeau' > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Tom, > > I see that you haven't answered all my questions, but I trust > that you will. > Please see my comments in-line. > > -Shahram > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Monday, March 04, 2002 12:57 PM > > To: Shahram Davari > > Cc: ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > I am hearing that people want to > > > > use simpler approaches, even if they are not > > architecturally pure. Some > > > of these > > > > approaches that are available today and won't double the cost > > > >of a device because the OAM > > > > functions are built on top of existing software, and > > > > thus don't require an army of software and hardware > > developers to realize. > > > > > >Interesting. So you actually beleive that MPLS OAM doubles > > the cost of > > >device!!! > > > > No. Don't misinterpret what I am saying. I think > > that YOUR approach > > will significantly increase the cost of a device. > > Ignoring your 2X price increase comment, why do you think there will > be a significant increase in the cost of a device? > implementing a simple CV flow > shouldn't be that expensive. > > There are > > other approaches > > that leverage existing technologies that are already > > implemented. I think > > the cost increase for these approaches is marginal in comparison. > > > > > > I do not think that Y.1711 presents good solutions > > > > to the problem of > > > > OAM. > > > > > >Why? The approach taken in Y.1711 is not new, it has been > around for > > >many many years in other technologies and has proven to work fine. > > > > You are basically trying to meld ATM OAM technology > > onto MPLS, which isn't an easy thing to do nor is it a good > fit, IMHO. > > I think Y.1711 shows that it is easy to do, and actually fits well. > What is the difference between ATM, FR, or any CO technology > and MPLS, and what > makes the basic OAM technique used by those technologies a > bad fit for MPLS? > > > > > > > I don't think I am out in left field on this one either. > > > > So again, I propose that we work on practical solutions > > to the problem > > > of OAM > > > > for MPLS. > > > > > >What do you mean by practical solution? > > > > A solution to that can be implemented in one's > > lifetime > > Again interesting comments. I read this as " Y.1711 is not > implementable in > one's life time".!!!!!!!! > > >and will not > > significantly increase the cost of the device on which it is > > implemented. > > You keep pointing to the significant cost. Could you please > clearly identify which parts of the MPLS OAM has significant > cost to implement compared to other approaches that you mentioned? > > > Such solutions generally do not require a complete re-design > > of all hardware that is deployed in the world and that > generally seem > > to work pretty well at this point. > > 1) MPLS OAM could be easily implemented in software. > 2) If one chooses to implement some part of it in hardware, > then off course new hardware is needed. > > > > > > --Tom > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 10:24:05 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 10:22:43 -0800 MIME-Version: 1.0 Content-Type: text/plain Tom, I see that you haven't answered all my questions, but I trust that you will. Please see my comments in-line. -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, March 04, 2002 12:57 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > I am hearing that people want to > > > use simpler approaches, even if they are not > architecturally pure. Some > > of these > > > approaches that are available today and won't double the cost > > >of a device because the OAM > > > functions are built on top of existing software, and > > > thus don't require an army of software and hardware > developers to realize. > > > >Interesting. So you actually beleive that MPLS OAM doubles > the cost of > >device!!! > > No. Don't misinterpret what I am saying. I think > that YOUR approach > will significantly increase the cost of a device. Ignoring your 2X price increase comment, why do you think there will be a significant increase in the cost of a device? implementing a simple CV flow shouldn't be that expensive. There are > other approaches > that leverage existing technologies that are already > implemented. I think > the cost increase for these approaches is marginal in comparison. > > > > I do not think that Y.1711 presents good solutions > > > to the problem of > > > OAM. > > > >Why? The approach taken in Y.1711 is not new, it has been around for > >many many years in other technologies and has proven to work fine. > > You are basically trying to meld ATM OAM technology > onto MPLS, which isn't an easy thing to do nor is it a good fit, IMHO. I think Y.1711 shows that it is easy to do, and actually fits well. What is the difference between ATM, FR, or any CO technology and MPLS, and what makes the basic OAM technique used by those technologies a bad fit for MPLS? > > > > I don't think I am out in left field on this one either. > > > So again, I propose that we work on practical solutions > to the problem > > of OAM > > > for MPLS. > > > >What do you mean by practical solution? > > A solution to that can be implemented in one's > lifetime Again interesting comments. I read this as " Y.1711 is not implementable in one's life time".!!!!!!!! >and will not > significantly increase the cost of the device on which it is > implemented. You keep pointing to the significant cost. Could you please clearly identify which parts of the MPLS OAM has significant cost to implement compared to other approaches that you mentioned? > Such solutions generally do not require a complete re-design > of all hardware that is deployed in the world and that generally seem > to work pretty well at this point. 1) MPLS OAM could be easily implemented in software. 2) If one chooses to implement some part of it in hardware, then off course new hardware is needed. > > --Tom > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 09:58:07 -0800 Message-Id: <4.3.2.7.2.20020304124515.01ee0528@161.44.167.72> Date: Mon, 04 Mar 2002 12:56:33 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed > > I am hearing that people want to > > use simpler approaches, even if they are not architecturally pure. Some > of these > > approaches that are available today and won't double the cost > >of a device because the OAM > > functions are built on top of existing software, and > > thus don't require an army of software and hardware developers to realize. > >Interesting. So you actually beleive that MPLS OAM doubles the cost of >device!!! No. Don't misinterpret what I am saying. I think that YOUR approach will significantly increase the cost of a device. There are other approaches that leverage existing technologies that are already implemented. I think the cost increase for these approaches is marginal in comparison. > > I do not think that Y.1711 presents good solutions > > to the problem of > > OAM. > >Why? The approach taken in Y.1711 is not new, it has been around for >many many years in other technologies and has proven to work fine. You are basically trying to meld ATM OAM technology onto MPLS, which isn't an easy thing to do nor is it a good fit, IMHO. > > I don't think I am out in left field on this one either. > > So again, I propose that we work on practical solutions to the problem > of OAM > > for MPLS. > >What do you mean by practical solution? A solution to that can be implemented in one's lifetime and will not significantly increase the cost of the device on which it is implemented. Such solutions generally do not require a complete re-design of all hardware that is deployed in the world and that generally seem to work pretty well at this point. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 09:14:38 -0800 Message-Id: <4.3.2.7.2.20020304181219.065fce40@paris.cisco.com> Date: Mon, 04 Mar 2002 18:13:54 +0100 To: Kireeti Kompella From: Jean Philippe Vasseur Subject: Re: CCAMP Protection/Restoration Design Team Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Kireeti, At 18:25 24/02/2002 -0800, Kireeti Kompella wrote: >Hi Folks, > >I'd like to thank all of you who volunteered for this work. To keep >the team small and effective, not everyone who volunteered could >participate directly. Note that you can (and should) participate >through the CCAMP WG, by giving suggestions/feedback to the DT, and, >if deemed necessary, by proposing alternate documents. > >Finally, note that the design team is _just another set of authors_. >The document(s) they produce are subject to WG consensus to progress >to WG documents and beyond. > >Here's the Protection/Restoration Design Team. They have been on >the job for a little over a month now. > >Deborah Brungard >Sudheer Dharanikota >Jonathan Lang >Guangzhi Li >Eric Mannie >Dimitri Papadimitriou >Bala Rajagopalan >Yakov Rekhter > >Sudheer is the team lead. > >Their charter ("you" in what follows refers to the DT): > >a) read drafts re protection/restoration in CCAMP, IPO and MPLS. > These include (but are not limited to :-)): > >******* draft-ietf-tewg-restore-hierarchy-00.txt ******* + draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. Thanks. JP. > draft-bala-protection-restoration-signaling-00.txt > draft-bala-restoration-signaling-01.txt > draft-ietf-ipo-carrier-requirements-00.txt (Section 10) > draft-kini-restoration-shared-backup-01.txt > draft-li-shared-mesh-restoration-01.txt > draft-many-optical-restoration-01.txt > draft-suemura-protection-hierarchy-00.txt > draft-ylee-protection-occ-00.txt > ----------------------------------------------------- > draft-atlas-rsvp-local-protect-interop-02.txt > draft-chang-mpls-path-protection-03.txt > draft-chang-mpls-rsvpte-path-protection-ext-02.txt > draft-owens-crldp-path-protection-ext-01.txt > > The first draft is the requirements for Protection & Restoration > produced by the TEWG Design Team. Functionality that you come up > with should satisfy these requirements; stuff that you come up > with that either goes beyond these requirements or doesn't meet > some of them should be called out so that we can re-evaluate. > > The drafts below the line may be MPLS-specific, so they may or may > not apply. > >| AD's comment: For the first round... please refrain as much as possible >| from going beyond the requirements specified in the first draft. That >| document restricted itself (on purpose) to requirements that are felt >| to be realistic for real operators and in the reasonably short term. >| So that is the scope you should be working in. > >b) produce a terminology document, preferably using ITU-T terminology, > but having a decoder ring to translate to terminology in current > drafts as well as the TE WG document >c) produce an interim analysis document, comparing and contrasting > approaches (i.e., the above drafts, published and ongoing work > at the ITU/T1-X1/...) > >| AD's comment: And be careful. Leave the ITU and T1X1-... etc work in >| those organisations if that is where it belongs (and often it does)! > >d) produce a more complete version of (c) >e) produce a functional spec delineating > o What's in scope, out of scope, what's for future study, which of > the TEWG reqts have been met, which not, and what goes beyond. > o Overall approach > o Objects/procedures/... needed in a protocol-independent fashion >f) produce a document detailing the changes for RSVP-TE and CR-LDP >g) produce a document detailing the changes for OSFP-TE and IS-IS-TE > >The timeline for (a-c) is before the next IETF (March 1, 2002). > >A first cut of (d) and (e) should be available by end of April, 2002. >If there is rough consensus in the CCAMP WG for the approach in (e), >work should then start on (f) and (g). > >Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 09:04:03 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5E0@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" , neil.2.harrison@bt.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 08:59:22 -0800 MIME-Version: 1.0 Content-Type: text/plain Tom, > Lets not misrepresent the facts again. There are > lots of equipment > vendors > who think that there are alternative ways of achieving defect > detection/repair using > simpler, Simpler and scalable such as GTTP?!!!!!!!!!! very interesting? > more practical mechanisms. These same vendors and > operators alike > spoke out at the OAM BOF against your grand architecture of > OAM for this > reason. To my knowledge only 3 opertors spoke against, which one of them does not exist any more (bankrupted). That leaves us with 2 operators against and 6 opertors for MPLS OAM!!!!!!!!!! > I have also been told this numerous times by > operational carrier > types privately as well. > > > > Please don't just refer us again to your OAM draft, > > > because I think it is clear that is a non-starter. > >NH=> Why is this.....and are you speaking on behalf of > yourself, Cisco or > >the IETF? > > People at the IETF speak for themselves. Read the > IETF guidelines > if you are unclear on this. > > >By saying this you are also stating that you also don't > >value/respect the fact that these requirements are supported by the > >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of > >manafuacturers, who are prepared it seems to meet these > requirements). > >You offer no rationale for this statement.......so I can > only assume you (or > >your company) disagree with these carrier's requirements. > > I always value the input of carriers, and specifically weigh > heavily the input > from their operational organizations (versus marketing or > research). I > learned this > lesson a long time ago. It is what drives what I do every day. Crrier > representatives > who are on the operational side of their organizations have > expressed concern > publicly and to me privately over these requirements and the > approaches > proposed > to solve them in Y.1711. Could you please name those carriers and their rational? > I am hearing that people want to > use simpler > approaches, > even if they are not architecturally pure. Some of these > approaches that > are available > today and won't double the cost >of a device because the OAM > functions are > built > on top of existing software, and thus don't require an army > of software and > hardware > developers to realize. Interesting. So you actually beleive that MPLS OAM doubles the cost of device!!! > > I really think that operators and vendors want to > eat OAM pudding, > not just talk about what color and shape it is. I just think > if we try to > build the > pudding described in Y.1711, that we will all starve Why? > > > > If there are still holes after this exercise, lets work together > > > on these problems and find efficient and solvable solutions > > > to them. This may not result > > > in an architectural correct over-all grand reference, > >NH=> Let me paraphrase what you are saying here: > >- I assume this remark is suggesting that the > requirements given in > >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is > not really what > >carriers want, even though they are asking for them, and > that Y.1711 is not > >a good solution.... > > I do not think that Y.1711 presents good solutions > to the problem of > OAM. Why? The approach taken in Y.1711 is not new, it has been around for many many years in other technologies and has proven to work fine. > I don't think I am out in left field on this one either. > So again, I > propose that we work on practical solutions to the problem of OAM > for MPLS. What do you mean by practical solution? -Shahram > > --Tom > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 07:52:29 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD34020EBC16@zcard0ka.ca.nortel.com> From: "David Allan" To: neil.2.harrison@bt.com, tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: re: Y1711 applicability...was draft-bonica-tunneltrace-02 Date: Mon, 4 Mar 2002 10:45:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C393.A1D0F780" 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_01C1C393.A1D0F780 Content-Type: text/plain; charset="iso-8859-1" Neil/Tom: Somthing that is missing from this discussion is an appreciation of the applicability of, limitations of..and deployment scenarios for Y.1711. It is not a panacea, nor is it a product of some networking "axis of evil". Y.1711 simply provides some defect detection/handling tools that can be implemented on LERs for explicitly routed p2p LSPs regardless of payload, and defines a framework and criteria for doing availability measurement with the same tools. When used in this fashion, it can be overlaid on an existing network and would work just fine as there are no dependencies on the intermediate LSRs. There are no backward compatibility issues, and the mechanism itself is quite lightweight, suggesting simple H/W assisted implementation on the edge devices. It's not hard to imagine all the places it could be used, as well as the places where it would add no value. As such I'm not sure why folks are labelling this as a non-starter, similarly I'm also seeing preliminary marketing literature suggesting that by the mere existence of OAM as a topic means the problems have been solved. IMHO neither is true. What I got out of the BOF last December (and subsequent e-mail blizzard) is that there are some operators and some vendors who don't think an MPLS specific approach is useful and a similar camp who do (and we're all quite passionate about it). Seems to me that if you examine the facts, there is room for both camps to co-exist. cheers Dave > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Sunday, March 03, 2002 6:24 PM > To: tnadeau@cisco.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Tom, > > You keep making assertions like like 'grand architecture' and > stating a need > for 'simpler solutions' but you offer no quantification of > such, and seem > quite happy to shift the defect detection/handling > problems/costs towards > the operator. > > To break the deadlock, let me ask you to answer a simple question: > > - The CV pkt is a simple 'keepalive' in the data-plane > carrying the > LSP source address......many protocols use such a device, > this one just > happens to look after the customer traffic (you know, the > stuff that earns > carrier's money?). This is about it complexity-wise as regards defect > detection. The only other things defined are an FDI pkt > (forward) and BDI > pkt (backward) notifications which only appear after a defect > is detected. > I think we would all therefore benefit if you can please > quantify why this > single CV pkt is so complex as you keep asserting....esp given all the > 'grand arch' benefits it brings? We await your comparative technical > analysis and costings for review. > > regards, Neil > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: 03 March 2002 18:30 > > To: neil.2.harrison > > Cc: ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > Neil, > > > > I am very glad that you have taken the time to reply to my > > response. Regards Tom. > > > > >Hi Tom...I am very glad you raised these points....please see my > > >observations on them. regards Neil > > > > > > > > > > Achitectural correctness is bunk if it > > > > does not leads to > > > > implementations that cannot support the architecture in such > > > > a way as to a) be > > > > implemented in one's lifetime, > > >NH=> I wholeheartedly agree with this......and for as long > > as I can remember > > >management-plane X-I/Fs have been promised but never materialised. > > > > Again you misstate the facts. Management IFs exist > > today: SNMP, > > LSP ping, etc... > > > > >However, > > >wrt to the topic here I am already aware of trial > > implementations by certain > > >vendors and Shahram Davari has been involved since very > early on.... > > >and since his company cuts the silicon many then use then > > this tells me it > > >can't > > >be be too complex. Maybe this is just a problem for your > > company?....a > > >quick look-see at who has problems seems to indicate Cisco > > figures largely > > >here in a class of 1. > > > > Lets not misrepresent the facts again. There are > > lots of equipment > > vendors > > who think that there are alternative ways of achieving defect > > detection/repair using > > simpler, more practical mechanisms. These same vendors and > > operators alike > > spoke out at the OAM BOF against your grand architecture of > > OAM for this > > reason. I have also been told this numerous times by > > operational carrier > > types privately as well. > > > > > > Please don't just refer us again to your OAM draft, > > > > because I think it is clear that is a non-starter. > > >NH=> Why is this.....and are you speaking on behalf of > > yourself, Cisco or > > >the IETF? > > > > People at the IETF speak for themselves. Read the > > IETF guidelines > > if you are unclear on this. > > > > >By saying this you are also stating that you also don't > > >value/respect the fact that these requirements are supported by the > > >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of > > >manafuacturers, who are prepared it seems to meet these > > requirements). > > >You offer no rationale for this statement.......so I can > > only assume you (or > > >your company) disagree with these carrier's requirements. > > > > I always value the input of carriers, and > specifically weigh > > heavily the input > > from their operational organizations (versus marketing or > > research). I > > learned this > > lesson a long time ago. It is what drives what I do every > day. Crrier > > representatives > > who are on the operational side of their organizations have > > expressed concern > > publicly and to me privately over these requirements and the > > approaches > > proposed > > to solve them in Y.1711. I am hearing that people want to > > use simpler > > approaches, > > even if they are not architecturally pure. Some of these > > approaches that > > are available > > today and won't double the cost of a device because the OAM > > functions are > > built > > on top of existing software, and thus don't require an army > > of software and > > hardware > > developers to realize. > > > > I really think that operators and vendors want to > > eat OAM pudding, > > not just talk about what color and shape it is. I just think > > if we try to > > build the > > pudding described in Y.1711, that we will all starve > > > > > > If there are still holes after this exercise, lets > work together > > > > on these problems and find efficient and solvable solutions > > > > to them. This may not result > > > > in an architectural correct over-all grand reference, > > >NH=> Let me paraphrase what you are saying here: > > >- I assume this remark is suggesting that the > > requirements given in > > >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is > > not really what > > >carriers want, even though they are asking for them, and > > that Y.1711 is not > > >a good solution.... > > > > I do not think that Y.1711 presents good solutions > > to the problem of > > OAM. I don't think I am out in left field on this one either. > > So again, I > > propose that we work on practical solutions to the problem of OAM > > for MPLS. > > > > --Tom > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > Mathematics is the supreme nostalgia of our time. > > > > ------_=_NextPart_001_01C1C393.A1D0F780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable re: Y1711 applicability...was = draft-bonica-tunneltrace-02

Neil/Tom:

Somthing that is missing from this discussion is an = appreciation of the applicability of, limitations of..and deployment = scenarios for Y.1711. It is not a panacea, nor is it a product of some = networking "axis of evil".

Y.1711 simply provides some defect detection/handling = tools that can be implemented on LERs for explicitly routed p2p LSPs = regardless of payload, and defines a framework and criteria for doing = availability measurement with the same tools. When used in this = fashion, it can be overlaid on an existing network and would work just = fine as there are no dependencies on the intermediate LSRs. There are = no backward compatibility issues, and the mechanism itself is quite = lightweight, suggesting simple H/W assisted implementation on the edge = devices. It's not hard to imagine all the places it could be used, as = well as the places where it would add no value.

As such I'm not sure why folks are labelling this as = a non-starter, similarly I'm also seeing preliminary marketing = literature suggesting that by the mere existence of OAM as a topic = means the problems have been solved. IMHO neither is true.

What I got out of the BOF last December (and = subsequent e-mail blizzard) is that there are some operators and some = vendors who don't think an MPLS specific approach is useful and a = similar camp who do (and we're all quite passionate about = it).

Seems to me that if you examine the facts, there is = room for both camps to co-exist.

cheers
Dave 

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com= ]
> Sent: Sunday, March 03, 2002 6:24 PM
> To: tnadeau@cisco.com
> Cc: ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 =
>
>
> Tom,
>
> You keep making assertions like like 'grand = architecture' and
> stating a need
> for 'simpler solutions' but you offer no = quantification of
> such, and seem
> quite happy to shift the defect = detection/handling
> problems/costs towards
> the operator. 
>
> To break the deadlock, let me ask you to answer = a simple question:
>
> -     The CV pkt is a = simple 'keepalive' in the data-plane
> carrying the
> LSP source address......many protocols use such = a device,
> this one just
> happens to look after the customer traffic (you = know, the
> stuff that earns
> carrier's money?).  This is about it = complexity-wise as regards defect
> detection.  The only other things defined = are an FDI pkt
> (forward) and BDI
> pkt (backward) notifications which only appear = after a defect
> is detected.
> I think we would all therefore benefit if you = can please
> quantify why this
> single CV pkt is so complex as you keep = asserting....esp given all the
> 'grand arch' benefits it brings?   We = await your comparative technical
> analysis and costings for review.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: 03 March 2002 18:30
> > To: neil.2.harrison
> > Cc: ccamp@ops.ietf.org
> > Subject: RE: draft-bonica-tunneltrace-02 =
> >
> >
> >
> = >          Neil,
> >
> = >          I am very = glad that you have taken the time to reply to my
> > response. Regards Tom.
> >
> > >Hi Tom...I am very glad you raised = these points....please see my
> > >observations on them.  regards = Neil
> > >
> > ><snip>
> > > > Achitectural correctness is bunk = if it
> > > > does not leads to
> > > > implementations that cannot = support the architecture in such
> > > > a way as to a) be
> > > > implemented in one's = lifetime,
> > >NH=3D> I wholeheartedly agree with = this......and for as long
> > as I can remember
> > >management-plane X-I/Fs have been = promised but never materialised.
> >
> = >          Again you = misstate the facts. Management IFs exist
> > today: SNMP,
> > LSP ping, etc...
> >
> > >However,
> > >wrt to the topic here I am already = aware of trial
> > implementations by certain
> > >vendors and Shahram Davari has been = involved since very
> early on....
> > >and since his company cuts the silicon = many then use then
> > this tells me it
> > >can't
> > >be be too complex.  Maybe this is = just a problem for your
> > company?....a
> > >quick look-see at who has problems = seems to indicate Cisco
> > figures largely
> > >here in a class of 1.
> >
> = >          Lets not = misrepresent the facts again. There are
> > lots of equipment
> > vendors
> > who think that there are alternative ways = of achieving defect
> > detection/repair using
> > simpler, more practical mechanisms. These = same vendors and
> > operators alike
> > spoke out at the OAM BOF against your = grand architecture of
> > OAM for this
> > reason.  I have also been told this = numerous times by
> > operational carrier
> > types privately as well.
> >
> > > > Please don't just refer us again = to your OAM draft,
> > > > because I think  it is = clear that is a non-starter.
> > >NH=3D> Why is this.....and are you = speaking on behalf of
> > yourself, Cisco or
> > >the IETF?
> >
> = >          People at = the IETF speak for themselves.  Read the
> > IETF guidelines
> > if you are unclear on this.
> >
> > >By saying this you are also stating = that you also don't
> > >value/respect the fact that these = requirements are supported by the
> > >following carriers AT&T, SBC, NTT, = DT, Sprint, BT (+ a list of
> > >manafuacturers, who are prepared it = seems to meet these
> > requirements).
> > >You offer no rationale for this = statement.......so I can
> > only assume you (or
> > >your company) disagree with these = carrier's  requirements.
> >
> = >          I always = value the input of carriers, and
> specifically weigh
> > heavily the input
> > from their operational  organizations = (versus marketing or
> > research). I
> > learned this
> > lesson a long time ago. It is what drives = what I do every
> day. Crrier
> > representatives
> > who are on the operational side of their = organizations have
> > expressed concern
> > publicly and to me privately over these = requirements and the
> > approaches
> > proposed
> > to solve them in Y.1711.  I am = hearing that people want to
> > use simpler
> > approaches,
> > even if they are not architecturally pure. = Some of these
> > approaches that
> > are available
> > today and won't double the cost of a = device because the OAM
> > functions are
> > built
> > on top of existing software, and thus = don't require an army
> > of software and
> > hardware
> > developers to realize.
> >
> = >          I really = think that operators and vendors want to
> > eat OAM pudding,
> > not just talk about what color and shape = it is. I just think
> > if we try to
> > build the
> > pudding described in Y.1711, that we will = all starve
> >
> > > >  If there are still holes = after this exercise, lets
> work together
> > > > on these problems and find = efficient and solvable solutions
> > > > to them. This may not = result
> > > > in an architectural correct = over-all grand reference,
> > >NH=3D> Let me paraphrase what you = are saying here:
> > >-       = I assume this remark is suggesting that the
> > requirements given in
> > >draft-harrison-mpls-oam-req-01.txt = (and also in Y.1710) is
> > not really what
> > >carriers want, even though they are = asking for them, and
> > that Y.1711 is not
> > >a good solution....
> >
> = >          I do not = think that Y.1711 presents good solutions
> > to the problem of
> > OAM. I don't think I am out in left field = on this one either.
> > So again, I
> > propose that we work on practical = solutions to the problem of OAM
> > for MPLS.
> >
> = >          --Tom
> >
> >
> >
> >
> >
> > = --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of = our time.
> >
>
>

------_=_NextPart_001_01C1C393.A1D0F780-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 04:06:58 -0800 Message-Id: <200203041206.HAA20556@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-cheng-ccamp-ospf-multiarea-te-extensions-00.txt Date: Mon, 04 Mar 2002 07:06:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions to Support Multi-Area Traffic Engineering Author(s) : D. Cheng Filename : draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt Pages : 6 Date : 01-Mar-02 The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-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-cheng-ccamp-ospf-multiarea-te-extensions-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-cheng-ccamp-ospf-multiarea-te-extensions-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: <20020301135034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135034.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 04:06:50 -0800 Message-Id: <200203041206.HAA20530@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-imajuku-ml-routing-01.txt Date: Mon, 04 Mar 2002 07:06:30 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-layer routing using multiple-layer switch capable LSRs Author(s) : W. Imajuku et al. Filename : draft-imajuku-ml-routing-01.txt Pages : 9 Date : 01-Mar-02 The integration of multi-layer switching capabilities within one box, such as the packet-switch capability (PSC) and the lambda- switch capability (LSC) under MPLS/Generalized-MPLS control mechanism, paves the way for realizing network resource optimization with consideration of multi-layer routing. This document clarifies the model of the GMPLS-controlled integrated PSC/LSC label switch router (LSR) and discusses the requirements of the routing extensions needed to realize optimized multi-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-imajuku-ml-routing-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-imajuku-ml-routing-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-imajuku-ml-routing-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: <20020301135011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-imajuku-ml-routing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-imajuku-ml-routing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135011.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 04:05:25 -0800 Message-Id: <200203041204.HAA20200@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-mib-01.txt Date: Mon, 04 Mar 2002 07:04:17 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-ccamp-lmp-mib-01.txt Pages : 70 Date : 01-Mar-02 This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP) [LMP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lmp-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020301134407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301134407.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 04:05:22 -0800 Message-Id: <200203041204.HAA20184@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-sdhsonet-control-00.txt Date: Mon, 04 Mar 2002 07:04:13 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS-based Control of SDH/SONET Networks Author(s) : G. Bernstein et al. Filename : draft-ietf-ccamp-sdhsonet-control-00.txt Pages : 26 Date : 01-Mar-02 The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-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-sdhsonet-control-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-sdhsonet-control-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: <20020301134348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-sdhsonet-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301134348.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Mar 2002 02:18:45 -0800 From: Emmanuel.Desmet@alcatel.be Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF To: ccamp@ops.ietf.org Date: Mon, 4 Mar 2002 11:17:24 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 2) "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 03 Mar 2002 22:52:00 -0800 Message-ID: <9FC28E726D21D6119FD90008C71EF3B00978B4@exzh002.alcatel.ch> From: Hug Werner To: "Wijnen Bert (Bert)" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Mon, 4 Mar 2002 07:45:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" My vote is for (2). Werner "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 03 Mar 2002 15:29:53 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Sun, 3 Mar 2002 23:24:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Tom, You keep making assertions like like 'grand architecture' and stating a need for 'simpler solutions' but you offer no quantification of such, and seem quite happy to shift the defect detection/handling problems/costs towards the operator. To break the deadlock, let me ask you to answer a simple question: - The CV pkt is a simple 'keepalive' in the data-plane carrying the LSP source address......many protocols use such a device, this one just happens to look after the customer traffic (you know, the stuff that earns carrier's money?). This is about it complexity-wise as regards defect detection. The only other things defined are an FDI pkt (forward) and BDI pkt (backward) notifications which only appear after a defect is detected. I think we would all therefore benefit if you can please quantify why this single CV pkt is so complex as you keep asserting....esp given all the 'grand arch' benefits it brings? We await your comparative technical analysis and costings for review. regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 03 March 2002 18:30 > To: neil.2.harrison > Cc: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > Neil, > > I am very glad that you have taken the time to reply to my > response. Regards Tom. > > >Hi Tom...I am very glad you raised these points....please see my > >observations on them. regards Neil > > > > > > > Achitectural correctness is bunk if it > > > does not leads to > > > implementations that cannot support the architecture in such > > > a way as to a) be > > > implemented in one's lifetime, > >NH=> I wholeheartedly agree with this......and for as long > as I can remember > >management-plane X-I/Fs have been promised but never materialised. > > Again you misstate the facts. Management IFs exist > today: SNMP, > LSP ping, etc... > > >However, > >wrt to the topic here I am already aware of trial > implementations by certain > >vendors and Shahram Davari has been involved since very early on.... > >and since his company cuts the silicon many then use then > this tells me it > >can't > >be be too complex. Maybe this is just a problem for your > company?....a > >quick look-see at who has problems seems to indicate Cisco > figures largely > >here in a class of 1. > > Lets not misrepresent the facts again. There are > lots of equipment > vendors > who think that there are alternative ways of achieving defect > detection/repair using > simpler, more practical mechanisms. These same vendors and > operators alike > spoke out at the OAM BOF against your grand architecture of > OAM for this > reason. I have also been told this numerous times by > operational carrier > types privately as well. > > > > Please don't just refer us again to your OAM draft, > > > because I think it is clear that is a non-starter. > >NH=> Why is this.....and are you speaking on behalf of > yourself, Cisco or > >the IETF? > > People at the IETF speak for themselves. Read the > IETF guidelines > if you are unclear on this. > > >By saying this you are also stating that you also don't > >value/respect the fact that these requirements are supported by the > >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of > >manafuacturers, who are prepared it seems to meet these > requirements). > >You offer no rationale for this statement.......so I can > only assume you (or > >your company) disagree with these carrier's requirements. > > I always value the input of carriers, and specifically weigh > heavily the input > from their operational organizations (versus marketing or > research). I > learned this > lesson a long time ago. It is what drives what I do every day. Crrier > representatives > who are on the operational side of their organizations have > expressed concern > publicly and to me privately over these requirements and the > approaches > proposed > to solve them in Y.1711. I am hearing that people want to > use simpler > approaches, > even if they are not architecturally pure. Some of these > approaches that > are available > today and won't double the cost of a device because the OAM > functions are > built > on top of existing software, and thus don't require an army > of software and > hardware > developers to realize. > > I really think that operators and vendors want to > eat OAM pudding, > not just talk about what color and shape it is. I just think > if we try to > build the > pudding described in Y.1711, that we will all starve > > > > If there are still holes after this exercise, lets work together > > > on these problems and find efficient and solvable solutions > > > to them. This may not result > > > in an architectural correct over-all grand reference, > >NH=> Let me paraphrase what you are saying here: > >- I assume this remark is suggesting that the > requirements given in > >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is > not really what > >carriers want, even though they are asking for them, and > that Y.1711 is not > >a good solution.... > > I do not think that Y.1711 presents good solutions > to the problem of > OAM. I don't think I am out in left field on this one either. > So again, I > propose that we work on practical solutions to the problem of OAM > for MPLS. > > --Tom > > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 03 Mar 2002 13:16:21 -0800 Message-Id: <4.3.2.7.2.20020303124940.01d6f7c8@161.44.167.72> Date: Sun, 03 Mar 2002 13:30:03 -0500 To: From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Neil, I am very glad that you have taken the time to reply to my response. Regards Tom. >Hi Tom...I am very glad you raised these points....please see my >observations on them. regards Neil > > > > Achitectural correctness is bunk if it > > does not leads to > > implementations that cannot support the architecture in such > > a way as to a) be > > implemented in one's lifetime, >NH=> I wholeheartedly agree with this......and for as long as I can remember >management-plane X-I/Fs have been promised but never materialised. Again you misstate the facts. Management IFs exist today: SNMP, LSP ping, etc... >However, >wrt to the topic here I am already aware of trial implementations by certain >vendors and Shahram Davari has been involved since very early on.... >and since his company cuts the silicon many then use then this tells me it >can't >be be too complex. Maybe this is just a problem for your company?....a >quick look-see at who has problems seems to indicate Cisco figures largely >here in a class of 1. Lets not misrepresent the facts again. There are lots of equipment vendors who think that there are alternative ways of achieving defect detection/repair using simpler, more practical mechanisms. These same vendors and operators alike spoke out at the OAM BOF against your grand architecture of OAM for this reason. I have also been told this numerous times by operational carrier types privately as well. > > Please don't just refer us again to your OAM draft, > > because I think it is clear that is a non-starter. >NH=> Why is this.....and are you speaking on behalf of yourself, Cisco or >the IETF? People at the IETF speak for themselves. Read the IETF guidelines if you are unclear on this. >By saying this you are also stating that you also don't >value/respect the fact that these requirements are supported by the >following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of >manafuacturers, who are prepared it seems to meet these requirements). >You offer no rationale for this statement.......so I can only assume you (or >your company) disagree with these carrier's requirements. I always value the input of carriers, and specifically weigh heavily the input from their operational organizations (versus marketing or research). I learned this lesson a long time ago. It is what drives what I do every day. Crrier representatives who are on the operational side of their organizations have expressed concern publicly and to me privately over these requirements and the approaches proposed to solve them in Y.1711. I am hearing that people want to use simpler approaches, even if they are not architecturally pure. Some of these approaches that are available today and won't double the cost of a device because the OAM functions are built on top of existing software, and thus don't require an army of software and hardware developers to realize. I really think that operators and vendors want to eat OAM pudding, not just talk about what color and shape it is. I just think if we try to build the pudding described in Y.1711, that we will all starve > > If there are still holes after this exercise, lets work together > > on these problems and find efficient and solvable solutions > > to them. This may not result > > in an architectural correct over-all grand reference, >NH=> Let me paraphrase what you are saying here: >- I assume this remark is suggesting that the requirements given in >draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is not really what >carriers want, even though they are asking for them, and that Y.1711 is not >a good solution.... I do not think that Y.1711 presents good solutions to the problem of OAM. I don't think I am out in left field on this one either. So again, I propose that we work on practical solutions to the problem of OAM for MPLS. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Mar 2002 13:28:57 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Sat, 2 Mar 2002 21:24:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Tom...please see below. Regards, Neil >>If you noted in some of my earlier mails I was very > careful to refer to > >'simple breaks' when using trail-trace type of mechanisms for defect > >diagnosis. If you ever get a misbranching/mismerging defect then: > >- you need to know it exists in the 1st place (not > obvious how this > >can be done....with CV it's trivial, as you see the source ID of any > >offending LSP at the sink of the offended LSP, so you both > detect/diagnose > >immediately)....I'll ignore the fact that a whole raft of > consequent actions > >are also missing; > > Please clarify. NH=> I provided info in earlier mails on this but you may have missed them, also a read of Y.1710 and Y.1711 may not go amiss (BTW Cisco has 4 delegates to the last SG13 where these Recs where agreed so they should be able to provide you with copies, and I also noted Bian Moore recently flagged a URL where copies of SG13 Recs should be available soon)....however, in summary: - need to raise an alarm relevant to the defect - need to suppress alarms in higher layer networks.....we all take FDI (from networks like SDH/ATM/OTN) for granted.....some additonal features in MPLS FDI which are defined are DL (Defect Location) and DT (Defect Type)......former gives AS of original defect (but no lower level detail) and latter indicates nature of original defect; - need to squelch traffic if misdelivered; - need to provide BDI if single-ended monitoring of availability and/or 1:N-type of prot-sw used.....also replicates DL/DT fields from FDI; - need to suppress any QoS aggregation (into long-term registers of such, eg pkt loss) when entering unavailable state.....but this pre-supposes we have agreed/standardised (and in order) (i) defect entry/exit citeria (ii) unavailable state entry/exit criteria. > >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a > >possibility....and as Geroge hints in an earlier mail is > actually an example > >of a layer violation, but so be it. However, this should > not be used in > >XoverMPLS....you need a solution here that is self-contained > within the MPLS > >network. > > What is a "self-contained MPLS network"? MPLS > networks require IP > networks. > When running X over MPLS why does that requirement change at all? NH=> See my response to George S on this who raised the same point. Note: small point re above....I did not say 'self-contained MPLS network' I said 'self-contained within the MPLS network', ie wrt the defect handling behaviour. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Mar 2002 13:28:54 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Sat, 2 Mar 2002 21:24:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Tom...I am very glad you raised these points....please see my observations on them. regards Neil > Achitectural correctness is bunk if it > does not leads to > implementations that cannot support the architecture in such > a way as to a) be > implemented in one's lifetime, NH=> I wholeheartedly agree with this......and for as long as I can remember management-plane X-I/Fs have been promised but never materialised. However, wrt to the topic here I am already aware of trial implementations by certain vendors and Shahram Davari has been involved since very early on....and since his company cuts the silicon many then use then this tells me it can't be be too complex. Maybe this is just a problem for your company?....a quick look-see at who has problems seems to indicate Cisco figures largely here in a class of 1. However, you are not compelled to implement all (or even any) of this stuff if you choose not to. > and b) can be sold for a > reasonable price. > If neither > can be met, then we are all just wasting our time. NH=> What is a reasonable price to your company wrt to a box may mean an unreasonable price/risk to an operator wrt to a network and the services it supports, ie the operator may have increased Opex costs and unhappy customers because they cannot offer robust carrier-strength network/service management. It would really help if you could give us some hard proof that what has been requested/proposed is too costly for us/you? But so far it seems I can't get answers to this. > I think what might be more constructive is to set out the > current problems that you as an operator (and other > operators) think need > to be > solved and then see how the existing solutions can be used to > solve these > problems. NH=> I though we did this at the last BoF?....Peter Willis represented BT and gave these. They are stated (as requirements) in draft-harrison-mpls-oam-req-01.txt. > Please don't just refer us again to your OAM draft, > because I think > it is clear that is a non-starter. NH=> Why is this.....and are you speaking on behalf of yourself, Cisco or the IETF? By saying this you are also stating that you also don't value/respect the fact that these requirements are supported by the following carriers AT&T, SBC, NTT, DT, Sprint, BT (+ a list of manafuacturers, who are prepared it seems to meet these requirements). You offer no rationale for this statement.......so I can only assume you (or your company) disagree with these carrier's requirements. > If there are still holes > after this > exercise, lets work together > on these problems and find efficient and solvable solutions > to them. This > may not result > in an architectural correct over-all grand reference, NH=> Let me paraphrase what you are saying here: - I assume this remark is suggesting that the requirements given in draft-harrison-mpls-oam-req-01.txt (and also in Y.1710) is not really what carriers want, even though they are asking for them, and that Y.1711 is not a good solution....so, as I have asked many times now, it would help if you could please provide evidence to support this remark. - irrespective of what carriers want, it seems the answer is X, so let's develop X and only X come what may. Given this, is there actually any point is submitting requirements? > but it > is probably > going to get us further > than arguing over what is architecturally pure and what is > not, which IMHO > is a waste > of everyone's time. NH=> Agree with the waste of everyone's time bit......IMO it hardly seems to matter what certain carrier's bring to IETF, it seems they just get ignored if it does not suit certain parties. Indeed, we are seriously reviewing the value of continued IETF participation because of this. I think it would be far more constructive if you could explain to the carriers noted above why they don't really want what they are asking for. It would also help if you can explain how the 'existing solutions' (sic) that you refer to can meet (or not) these requirements? However, if you are not even prepared to countenance such requirements as you stated above (ie "Please don't just refer us again to your OAM draft, because I think it is clear that is a non-starter."), then maybe the simple way out now (esp so we don't continue to waste each others time) is that 'IETF' develop the OAM solutions for MPLS that they feel are fit for purpose and we let the carriers choose what they want to ask for? And, as I remarked earlier, there is no need whatsoever for your company to implement all (or even any) of the Y.1711 stuff if you don't feel its any good. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Mar 2002 13:28:50 -0800 Message-ID: From: neil.2.harrison@bt.com To: swallow@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Sat, 2 Mar 2002 21:24:18 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > NH=> Asking ICMP to proxy for missing defect handling in MPLS is a > > possibility....and as George hints in an earlier mail is > actually an example > > of a layer violation, but so be it. However, this should > not be used in > > XoverMPLS....you need a solution here that is > self-contained within the MPLS > > network. > > Have we found the crux of the matter? MPLS as defined by the IETF > (and I personally don't believe any other body has jurisdiction over > the core MPLS technology) requires that all boxes be IP capable. > > ...George NH=> Yes I think you have hit on the key point here George.....but you need to be clear which *plane* you are referring to. To do what is being suggested (implicitly by your comment) requires an IP capable transfer-mode network that is decoupled from the other layer network that it is proxying defect handling for. In other words, the IP network is acting as though its some form of (i) higher layer client application/test-probe in the traffic-plane and (ii) management-plane gatherer of information. Several points flow from this: - its a well known fact to us in telco world that the data-planes of the traffic, control and management planes are not necessarily congruent.....indeed for CO networks there are many advantages in not having them congruent and in some cases this is clearly forced, eg OTNs. A key point of this observation is that the topology/design of the control (or management) data-planes must only take its survivability cues from the duct layer. So even if one is using an IP-based encapsulation/transfer mode in the user-plane of the control or management networks here, one may not be doing so in the traffic-plane (this also has implications for 'addressing' of the data-plane access points of the networks that constitute these different planes). - if I build on the above and consider SDH/OTNs in general (we can collectively call these GMPLS if it helps), the traffic-plane here is a cct-sw 'quantised BW' entity.....clearly this has nothing to do with IP at all (it may ultimately carry an IP-based pkt stream, or indeed anything else, but that is irrelevant). You might use an IP delivered set of protocols in the management or control planes for such networks.....but these lie in a different data-plane network as I noted above. - if one agrees with the above (and I can't see how anyone could not since its obvious), then it follows that this logic can be applied to any CO layer network.....MPLS is therefore but one example that I can add to FR, ATM, SDH, OTNs, etc. Ergo GMPLS....in principle, if not in embodiment. - and to reinforce the point.....the fact that MPLS creates new CO trail entities (that can carry clients other than IP) means these will have failure modes that are not relevant to any other layer network (inc IP), and need decoupling from any specific client or server layer technologies. This is just a fact......you can disagree with it if you like (and I am sure many will) but I can't alter the truth of this observation (hopefully such a truth is a bit more obvious for an OTN in the context of 'GMPLS' for anyone still struggling to grasp this). Trying to pretend MPLS is not a layer network which creates CO trails (when ER/signalled at least) does not help anyone long-term....esp if one is also prepared to accept what is happening in GMPLS, as such a stance would be a logical contradiction. IMO its time we faced this fact and stopped skirting the issue. BTW - I would be careful saying that no other body should have jurisdiction over MPLS as: (i) I can't equate this remark with what I see happening to SDH and OTN wrt GMPLS in IETF; (ii) there are other bodies out there like ITU, ATMF, MPLSF, IEEE who will need to have some say wrt MPLS development (ditto GMPLS....or put another way SDH/OTNs/etc and the interfacing/control/management of such); (iii) it assumes that IETF are eventually going to provide some carrier-strength defect detection/handling functions for MPLS, but given what I have seen over the last year this seems very unlikely to materialise. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Mar 2002 13:28:48 -0800 Message-ID: From: neil.2.harrison@bt.com To: lmak@lucent.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Sat, 2 Mar 2002 21:24:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Leen, This is quite correct. And it really does help not hinder. The difficult bit for most people I think is accepting MPLS fits here. SDH and OTNs are very obvious in that they do fit....ergo GMPLS fits. FR and ATM also fit. MPLS also fits but its hard for some to make this association (for whatever reason....be it a truly held conviction or (more worryingly) commercially driven motives). All I have been saying is that this gives a formal way of describing layered network relationships (just like your periodic table analogy)....and once grasped it is very powerful in understanding/specifying required network behaviour (and it also immediately explains the reality of the L1/2/3 tags people use somewhat arbitrarily and the fact there there is no such thing as 'one' L3 network, viz the OSI 7-layer model). It actually would help with progressing Bonnica and also understanding the approach others have taken in Y.1710/1711.....but it requires a willingness to be able to go into Rx mode rather than just Tx mode. regards, Neil > -----Original Message----- > From: Mak, L (Leen) [mailto:lmak@lucent.com] > Sent: 01 March 2002 15:58 > To: ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Let me make a Friday afternoon remark and than duck > for the flak: > > IMHO, the layering concept (and the associated system > of functional modelling) is to the study and design of > (circuit based) transport networks what the Periodic > System of Elements is to chemistry. > > Of course, you can do without, but with such an ordening > principle the work in the field becomes a bit less intuitive > and a bit more structured. If you like: less of an art and > more of an engineering discipline. > > I'm afraid this does not progress the discussion on the > bonica draft, but it might help getting the layering concept > where it belongs ... > > > Leen Mak. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 13:56:14 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF12710569184C@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Bradford, Richard" , Jonathan Lang Cc: ccamp-wg Subject: RE: LMP Date: Fri, 1 Mar 2002 22:55:48 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Bradford, Richard [mailto:rbradfor@cisco.com] > Sent: Friday, March 01, 2002 10:03 PM > To: Jonathan Lang > Cc: 'Wijnen, Bert (Bert)'; ccamp-wg > Subject: RE: LMP > > > At 11:30 AM 3/1/2002 -0800, Jonathan Lang wrote: > >Bert, > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Tuesday, February 26, 2002 2:26 PM > > > To: ccamp-wg > > > Subject: LMP > > > > > > > > > > > > When I look at section 14, then I wonder: > > > > > > LOCAL_CCID: Class = 1, C-Type = 1, 4 byte CC_id > > > REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id > > > > > > Why is that not: > > > > > > CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id > > > CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id > >This change is fine with me unless there is objection from others. > > I'll raise an objection. Throughout the draft the Class is > being used to define the meaning of the object and C-type its format. > Local and remote CCIDs are two completely different objects. > They are as different as remote and local node-IDs. > They are not different formats of the same object. > Sorry, I had a cut-and-paste error. I meant: Why is that not: CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id CCID: Class = 1, REMOTE: C-Type = 2, 4 byte CC_id Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 13:43:01 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC0DCA1E@nimbus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Luc Ceuppens To: "'bwijnen@lucent.com'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 1 Mar 2002 13:39:42 -0800 [ post by non-subscriber ] (2) > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 1:37 AM > To: ccamp-wg > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic > parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in > RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 13:23:02 -0800 Message-ID: <3C7FF26F.29EA6A2C@alcatel.com> Date: Fri, 01 Mar 2002 15:28:15 -0600 From: Jim Jones Organization: Alcatel USA MIME-Version: 1.0 To: "'Wijnen, Bert (Bert)'" CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Option 2.) Jim > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, February 26, 2002 1:37 AM > > To: ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic > > parameters > > > and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in > > RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 13:06:32 -0800 Message-Id: <4.3.2.7.2.20020301155729.01a5d188@pilgrim.cisco.com> Date: Fri, 01 Mar 2002 16:02:57 -0500 To: Jonathan Lang From: "Bradford, Richard" Subject: RE: LMP Cc: "'Wijnen, Bert (Bert)'" , ccamp-wg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:30 AM 3/1/2002 -0800, Jonathan Lang wrote: >Bert, > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, February 26, 2002 2:26 PM > > To: ccamp-wg > > Subject: LMP > > > > > > > > When I look at section 14, then I wonder: > > > > LOCAL_CCID: Class = 1, C-Type = 1, 4 byte CC_id > > REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id > > > > Why is that not: > > > > CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id > > CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id >This change is fine with me unless there is objection from others. I'll raise an objection. Throughout the draft the Class is being used to define the meaning of the object and C-type its format. Local and remote CCIDs are two completely different objects. They are as different as remote and local node-IDs. They are not different formats of the same object. -- Rich Bradford Email: rbradfor@cisco.com Cisco Systems, Inc. Tel: 978-497-3079 300 Apollo Drive Fax: 978-497-3079 Chelmsford, Mass 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 12:49:42 -0800 Message-ID: From: "Natale, Robert C (Bob)" To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 1 Mar 2002 15:48:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, Apologies in advance for this post going against the grain of the AD's guidance for this thread. I am not (I hope!) posting a "diatribe" here :-) -- I am just curious about something and maybe the answer to it will affect my own and possibly others' assessment of the options before us.... As a non-expert (re the diffs between SONET and SDH as they might necessarily affect labeling requirements or not), I opted for #1 (or #4, which I consider to be its moral equivalent) on the basis of my interpretation of s/w engineering principles and my (negative) experience with allowing optionality in widely deployed standards. Since the respondents seems largely divided between #1 and #2 (with the few mentioning #4 as an acceptable alternative about equally divided between #1 and #2 as another acceptable choice for them), my attention is naturally drawn to the absence of any "votes" for #3 (apologies if I've missed anyone's vote for #3)...? The only diff that I can discern between #2 and #3 is the SHOULD in #2 vs the MUST in #3. It is that SHOULD in #2 that caused me to discount it up front. I am curious to know how the people expressing a preference for #2 feel about #3 -- that is, do they see it important that we specify #2 rather than #3, or rather than #1? I'm really against that SHOULD in #2. But -- although I do prefer #1 (or, second, #4) for the reasons mentioned above -- I might not feel as determinedly antagonistic to #3, if that were to end up being the WG's consensus. Thanks, BobN >At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote: >If people want to express their support for this 4th option >then that is fine with me. WG chair(s) do you agree too >(don't want to step on your toes or sit in your chair). > >Bert > > > -----Original Message----- > > From: Mannie, Eric > [mailto:Eric.Mannie@ebone.com] > > Sent: Tuesday, February 26, 2002 11:32 AM > > To: 'Wijnen, Bert (Bert)'; ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > > Hello Bert and all, > > > > One question is missing: > > > > 4) Do you think we should have just a single set of traffic > > parameters and label format (values) for both SDH and SONET. > > > > In 1) "none for SONET" assumes that SONET doesn't exist > > anymore. Note also that the traffic parameters are already > > identical, the only difference is about the label. As editor > > of these drafts I would like at least to see the right > > questions asked on the mailing list. > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > [mailto:bwijnen@lucent.com] > > Sent: Tuesday, February 26, 2002 10:37 AM > > To: ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic > > > parameters and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in > > > RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 12:21:47 -0800 Message-Id: <4.3.2.7.2.20020301152011.01e9c2a0@mo-ex1> Date: Fri, 01 Mar 2002 15:21:32 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Cc: "Mannie, Eric" ,"ccamp-wg" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed (4) or if not approved, (2). Lou At 07:39 AM 2/26/2002, Wijnen, Bert (Bert) wrote: >If people want to express their support for this 4th option >then that is fine with me. WG chair(s) do you agree too >(don't want to step on your toes or sit in your chair). > >Bert > > > -----Original Message----- > > From: Mannie, Eric > [mailto:Eric.Mannie@ebone.com] > > Sent: Tuesday, February 26, 2002 11:32 AM > > To: 'Wijnen, Bert (Bert)'; ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > > Hello Bert and all, > > > > One question is missing: > > > > 4) Do you think we should have just a single set of traffic > > parameters and > > label format (values) for both SDH and SONET. > > > > In 1) "none for SONET" assumes that SONET doesn't exist > > anymore. Note also > > that the traffic parameters are already identical, the only > > difference is > > about the label. As editor of these drafts I would like at > > least to see the > > right questions asked on the mailing list. > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > [mailto:bwijnen@lucent.com] > > Sent: Tuesday, February 26, 2002 10:37 AM > > To: ccamp-wg > > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic > > parameters > > > and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in > > RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 12:20:16 -0800 Message-Id: <4.3.2.7.2.20020301151332.01e9d538@mo-ex1> Date: Fri, 01 Mar 2002 15:18:41 -0500 To: CCAMP From: Lou Berger Subject: GMPLS Signaling Implementation Survey Form Cc: Yakov Rekhter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed All, If you'd like to participate in a GMPLS signaling implementation survey, please complete (as much as you can/want) and return the enclosed. We will consolidate all answers and publish the results (to the list and as a draft.) Thank you, Lou (and Yakov) ---------------------------------- GMPLS Signaling Implementation Survey Form [V 1.0] This is form is derived from V2.2 of the "RSVP and QoS Implementation Survey Information Form" authored by Gene Gaines and Marco Festa . See http://www.iit.nrc.ca/IETF/RSVP_survey/rsvp-qos_quest_980210.txt. This form is also available from http://www.labn.net/gmpls/sig-survey.txt ======================================================================= 1. Organization: 1.1 Organization url(s): 2. Product title(s): 2.1 Brief description(s): ---------------------------------------------------------------- 3. Contact for GMPLS information 3.1 Name: 3.2 Title: 3.3 E-mail: 3.4 Organization/department: 3.5 Postal address: 3.6 Phone: 3.7 Fax: ---------------------------------------------------------------- 4. Status: 4.1 [ ] Development 4.2 [ ] Alpha 4.3 [ ] Beta 4.4 [ ] Product 4.5 [ ] Other (describe): 5. Switching capabilities 5.1 [ ] PSC 5.2 [ ] TDM 5.3 [ ] LSC 5.4 [ ] FSC 6. Reference Drafts (please list, include version numbers) 6.1 [ ] 6.2 [ ] 6.3 [ ] 6.4 [ ] 6.5 [ ] 6.6 [ ] 7. Interface technologies 7.1 [ ] Frame Relay 7.2 [ ] ATM 7.3 [ ] Ethernet V2/DIX 7.4 [ ] Ethernet 802.3 7.5 [ ] SDH 7.6 [ ] SONET 7.7 [ ] Lambda (photonic) 7.8 [ ] Fiber 7.9 [ ] FiberChannel 7.10 [ ] Other (describe): 8. Availability 8.1 [ ] Public and free 8.2 [ ] Only to selected organizations/companies but free 8.3 [ ] On sale. 8.4 [ ] For internal company use only 8.5 [ ] Other: 9. Implementation based on: (check all that apply) 9.1 [ ] Purchased code (please list source if possible) 9.2 [ ] Free code (please list source if possible) 9.3 [ ] Internal implementation (no outside code, just from specs) 9.4 [ ] Internal implementation on top of purchased or free code 9.4.1 [ ] List portions from external source 9.4.2 [ ] List portions developed internally 10. Supported Label Types 10.1 [ ] MPLS Label 10.2 [ ] Generalized Label 10.3 [ ] Waveband Label 10.4 [ ] SONET/SDH Label 11. Label Related 11.1 [ ] Suggested Label 11.2 [ ] Label Set 12. Traffic Parameters 12.1 [ ] Intserv (Please list which) 12.2 [ ] CR-LDP 12.3 [ ] GMPLS Bandwidth Encoding 12.4 [ ] SONET/SDH 13. [ ] Bidirectional LSPs 14. Notification 14.1 [ ] Acceptable Label Set 14.2 [ ] Notify Request Objects (GMPLS-RSVP) 14.3 [ ] Notify Message (GMPLS-RSVP) 14.4 [ ] Removing State with a PathErr message (GMPLS-RSVP) 15 Other features 15.1 [ ] Explicit Label Control 15.2 [ ] Protection Information 15.3 [ ] Administrative Status Information 15.4 [ ] Interface Identification 15.5 [ ] Errored Interface Identification 15.6 [ ] Link Fault Handling 15.7 [ ] Nodal Fault Handling 16. Other specification(s) which apply: 17. Other features supported: 18. Currently-defined GMPLS signaling features not supported: 19. Notes (please describe purpose of project, give any information that might be useful to those interested in developing or using GMPLS) 20. If you feel the above categories are not complete, add others which will better describe your project: ======================================================================= Person filling out this form: Name: E-mail: Tel.: Title: Company: Date prepared: ---------------------------------------------------------------- Return your information to the authors: Lou Berger or and Yakov Rekhter all returned information will be consolidated and reported to the CCAMP WG mailing list. Thank you! Updated 03/01/02 --end-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:40:05 -0800 Message-ID: From: Jonathan Lang To: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 1 Mar 2002 11:33:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2) Thanks, Jonathan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 1:37 AM > To: ccamp-wg > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic > parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in > RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:39:33 -0800 Message-ID: From: Jonathan Lang To: "'Wijnen, Bert (Bert)'" , ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-lmp-02.txt Date: Fri, 1 Mar 2002 11:32:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Thanks for pointing this out. We have already started working on this as can be seen by the recent contribution by Alex Zinin on LMP Security. Thanks, Jonathan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 2:55 AM > To: ccamp@ops.ietf.org > Subject: draft-ietf-ccamp-lmp-02.txt > > > From Kireeti's "wg document status" email > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Monday, February 25, 2002 2:52 AM > > To: ccamp@ops.ietf.org > > Subject: WG dcoument status > > > > > > Here's a status update. > > > ... snip ... > > > The LMP draft: > > draft-ietf-ccamp-lmp-02.txt > > has gone through one round of WG Last Call comments and, once a > > new version has been produced incorporating these comments, will > > go through a final WG Last Call. This is also targeted as a > > Proposed Standard. > > > I will note that in my view, the security section will need > serious work. I doubt that the Security ADs will sign off on the > current text. The security section should address the risks > and treats. It should then specify how to protect against them. > A text like "LMP exchanges may be authenticated with MD5" (which > is basically what you write now) seems not sufficient to me. > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:38:00 -0800 Message-ID: From: Jonathan Lang To: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: LMP Date: Fri, 1 Mar 2002 11:30:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 2:26 PM > To: ccamp-wg > Subject: LMP > > > > When I look at section 14, then I wonder: > > LOCAL_CCID: Class = 1, C-Type = 1, 4 byte CC_id > REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id > > Why is that not: > > CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id > CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id This change is fine with me unless there is objection from others. Thanks, Jonathan > > The above is just an example. this is type of definitions > occur throughout section 14, and it seems we are using > many more name space code points than really needed. > Is this handy? Wise? Good design? > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:33:04 -0800 Message-Id: <200203011932.g21JWpT30931@merlot.juniper.net> To: "Wijnen, Bert (Bert)" cc: ccamp@ops.ietf.org Subject: Re: WG dcoument status MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56208.1015011170.1@juniper.net> Date: Fri, 01 Mar 2002 11:32:51 -0800 From: Yakov Rekhter Bert, > Mmm.. RFC1264 says on page 4, pls note items 4) and 5): > > > 4.0 Requirements for Proposed Standard > > 1) Documents specifying the Protocol and its Usage. The > specification for the routing protocol must be well written such > that independent, interoperable implementations can be developed > solely based on the specification. For example, it should be > possible to develop an interoperable implementation without > consulting the original developers of the routing protocol. > > 2) A Management Information Base (MIB) must be written for the > protocol. The MIB does not need to submitted for Proposed > Standard at the same time as the routing protocol, but must be > at least an Internet Draft. > > 3) The security architecture of the protocol must be set forth > explicitly. The security architecture must include mechanisms for > authenticating routing messages and may include other forms of > protection. > > 4) One or more implementations must exist. > > 5) There must be evidence that the major features of the protocol > have been tested. > > 6) No operational experience is required for the routing protocol > at this stage in the standardization process. (4) is satisfied by having just *one* implementation. Ditto for (5). Nowhere in the above there is a requirement for multiple interoperable implementations. With this in mind, please take out the part about "interoperability test results". Yakov. > > Bert > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, March 01, 2002 2:58 PM > > To: Wijnen, Bert (Bert) > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: WG dcoument status > > > > .. snip .. > > > > showing up.... In other words... it might be good if people start to > > > report implementation and interoperability test reults. > > > > Please note that in the RTG area (rfc1264) there is no requirement > > for a Proposed Standard to have (a) more than one implementation, and > > (b) for these implementations to be interoperable. > > > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:32:39 -0800 Message-ID: <3C7FD629.5335DADD@alcatel.be> Date: Fri, 01 Mar 2002 20:27:37 +0100 From: Gert Van Hoey MIME-Version: 1.0 To: Kireeti Kompella CC: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I prefer option (2) Gert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 11:29:15 -0800 Message-Id: <200203011928.g21JSYT30661@merlot.juniper.net> To: "ccamp-wg cc: "Wijnen, Bert (Bert)" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54870.1015010914.1@juniper.net> Date: Fri, 01 Mar 2002 11:28:34 -0800 From: Yakov Rekhter My vote is for (2) Yakov. > "Wijnen, Bert (Bert)" wrote: > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic parameters > > > and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 10:43:27 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5DC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Thomas D. Nadeau'" , neil.2.harrison@bt.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Fri, 1 Mar 2002 10:42:30 -0800 MIME-Version: 1.0 Content-Type: text/plain Eric, > This being the IETF, there's not much point in > criticizing a particular > proposal on the ground that it only works when IP is used. I didn't criticize the IETF. I suggested that it would be preferred to develop a non-IP based OAM tool, if at all possible, and if it does not introduce excess complexity. -Shahram Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 10:35:20 -0800 Message-Id: <200203011834.NAA26147@erosen-u10.cisco.com> To: Shahram Davari cc: "'Thomas D. Nadeau'" , neil.2.harrison@bt.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 01 Mar 2002 13:34:56 -0500 From: Eric Rosen Shahram> But we could also have configured LSPs (without signaling), and in Shahram> future people may use other non-IP based routing/signaling Shahram> protocols such as PNNI. I certainly hope not. But of course there's no telling what people might try to do. Shahram> Therefore developing an IP-based OAM for MPLS will unnecessarily Shahram> limit the routing/signaling protocols that could be used for MPLS This being the IETF, there's not much point in criticizing a particular proposal on the ground that it only works when IP is used. I would propose that issues having to do with the use of non-IP control planes be declared out of scope. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 10:34:08 -0800 Message-ID: From: Jonathan Lang To: "'Wijnen, Bert (Bert)'" , ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-lmp-02.txt Date: Fri, 1 Mar 2002 10:25:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Thanks for your comments. Responses inline. -Jonathan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 6:03 AM > To: ccamp@ops.ietf.org > Subject: RE: draft-ietf-ccamp-lmp-02.txt > > > Further comments (I have not checked the whole document, > just reporting as I see thibgs while looking for specific > stuff). > > The IANA considerations section is setting aside 4% of the > name space for Message Type and 8% of Object Class name space for > OIF UNI. Is that the proper thing to do? > > I understand OIF has already "provisionally claimed" a few > of the "reserved" numbers. We can honor that while we move forward. > But I think it would be better to keep the whole name space > assignments in one place, and under control of IANA. > > The OIF (and other organisations) can then request assignments through > the normal process, similar to how > > http://www.ietf.org/internet-drafts/draft-bala-uni-signaling-extensions-00.t xt > is trying to do right now. agreed. We have rewritten the IANA considerations section to keep the whole name space assignments under control of IANA. >By the way, you use these terms: > > - Message Type > - Msg Type > - MsgType > >Probably better to settle for one "spelling" and be consistent I think Done. Thanks for catching that. >In IANA Considerations section you also talk about >"class and class type name spaces" while you only elaborate on the >control of the "Object Class Name Space". So are there multiple names spaces >for class and class-type or just one. There seem to be two, i.e. Object Class >and Class Type (within a class). Does the Class Type name space not have >IANA considerations? This has been clarified as you suggest. > >Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Tuesday, February 26, 2002 11:52 AM > To: ccamp@ops.ietf.org > Subject: draft-ietf-ccamp-lmp-02.txt > > > From Kireeti's "wg document status" email > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Monday, February 25, 2002 2:52 AM > > To: ccamp@ops.ietf.org > > Subject: WG dcoument status > > > > > > Here's a status update. > > > ... snip ... > > > The LMP draft: > > draft-ietf-ccamp-lmp-02.txt > > has gone through one round of WG Last Call comments and, once a > > new version has been produced incorporating these comments, will > > go through a final WG Last Call. This is also targeted as a > > Proposed Standard. > > > I will note that in my view, the security section will need > serious work. I doubt that the Security ADs will sign off on the > current text. The security section should address the risks > and treats. It should then specify how to protect against them. > A text like "LMP exchanges may be authenticated with MD5" (which > is basically what you write now) seems not sufficient to me. > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 09:40:07 -0800 Message-ID: <3C7FBC91.E0586433@alcatel.be> Date: Fri, 01 Mar 2002 18:38:25 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: CCAMP P&R DT output: draft-design-team-gmpls-recovery-analysis-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii CCAMPers, You can find from today the second output of the P&R DT on "GMPLS-based recovery analysis" at the following location: http://www.cs.odu.edu/~sudheer/draft-design-team-gmpls-recovery-analysis-00.txt Don't hesitate to share with us your comments and input. - dimitri. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Address: Alcatel - Optical NA, 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, 01 Mar 2002 08:54:12 -0800 Message-Id: <4.3.2.7.2.20020301115315.03c7bda8@mo-ex1> Date: Fri, 01 Mar 2002 11:53:51 -0500 To: From: Lou Berger Subject: Re: WG dcoument status Cc: "John Drake" ,"Berger, Lou" , "Wijnen, Bert (Bert)" , "Yakov Rekhter" , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I'll send the form to the ccamp list and post a URL. Lou At 11:49 AM 3/1/2002, Dimitri.Papadimitriou@alcatel.be wrote: >Lou, > >Could you please send me a form, > >Many thanks, >- dimitri. > >John Drake wrote: > > > > Lou, > > > > Please send me a form. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@movaz.com] > > Sent: Friday, March 01, 2002 8:20 AM > > To: Wijnen, Bert (Bert) > > Cc: Yakov Rekhter; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: WG dcoument status > > > > hmm, looks like all that is missing is a formal statement on 4. > > My guess is that just making a statement that one exists (and it does) > > isn't sufficient. I volunteer to pull together an implementation > > report. I'll send out a form later today, collect the info and post the > > results. > > > > Lou > > > > At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote: > > > > >Mmm.. RFC1264 says on page 4, pls note items 4) and 5): > > > > > > > > > 4.0 Requirements for Proposed Standard > > > > > > 1) Documents specifying the Protocol and its Usage. The > > > specification for the routing protocol must be well written such > > > that independent, interoperable implementations can be developed > > > solely based on the specification. For example, it should be > > > possible to develop an interoperable implementation without > > > consulting the original developers of the routing protocol. > > > > > > 2) A Management Information Base (MIB) must be written for the > > > protocol. The MIB does not need to submitted for Proposed > > > Standard at the same time as the routing protocol, but must be > > > at least an Internet Draft. > > > > > > 3) The security architecture of the protocol must be set forth > > > explicitly. The security architecture must include mechanisms for > > > authenticating routing messages and may include other forms of > > > protection. > > > > > > 4) One or more implementations must exist. > > > > > > 5) There must be evidence that the major features of the protocol > > > have been tested. > > > > > > 6) No operational experience is required for the routing protocol > > > at this stage in the standardization process. > > > > > >Bert > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter > [<mailto:yakov@juniper.net>mailto:yakov@juniper.net] > > > > Sent: Friday, March 01, 2002 2:58 PM > > > > To: Wijnen, Bert (Bert) > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: WG dcoument status > > > > > > > > > >.. snip .. > > > > > > > > showing up.... In other words... it might be good if people start to > > > > > report implementation and interoperability test reults. > > > > > > > > Please note that in the RTG area (rfc1264) there is no requirement > > > > for a Proposed Standard to have (a) more than one implementation, and > > > > (b) for these implementations to be interoperable. > > > > > > > > Yakov. > > > > > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Website: >http://www.rc.bel.alcatel.be/~papadimd/index.html > >Address: Alcatel - Optical NA, 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, 01 Mar 2002 08:50:33 -0800 Message-ID: <3C7FB11C.9A2D3757@alcatel.be> Date: Fri, 01 Mar 2002 17:49:32 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: John Drake Cc: "'Lou Berger'" , "Wijnen, Bert (Bert)" , Yakov Rekhter , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Lou, Could you please send me a form, Many thanks, - dimitri. John Drake wrote: > > Lou, > > Please send me a form. > > Thanks, > > John > > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Friday, March 01, 2002 8:20 AM > To: Wijnen, Bert (Bert) > Cc: Yakov Rekhter; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: WG dcoument status > > hmm, looks like all that is missing is a formal statement on 4. > My guess is that just making a statement that one exists (and it does) > isn't sufficient. I volunteer to pull together an implementation > report. I'll send out a form later today, collect the info and post the > results. > > Lou > > At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote: > > >Mmm.. RFC1264 says on page 4, pls note items 4) and 5): > > > > > > 4.0 Requirements for Proposed Standard > > > > 1) Documents specifying the Protocol and its Usage. The > > specification for the routing protocol must be well written such > > that independent, interoperable implementations can be developed > > solely based on the specification. For example, it should be > > possible to develop an interoperable implementation without > > consulting the original developers of the routing protocol. > > > > 2) A Management Information Base (MIB) must be written for the > > protocol. The MIB does not need to submitted for Proposed > > Standard at the same time as the routing protocol, but must be > > at least an Internet Draft. > > > > 3) The security architecture of the protocol must be set forth > > explicitly. The security architecture must include mechanisms for > > authenticating routing messages and may include other forms of > > protection. > > > > 4) One or more implementations must exist. > > > > 5) There must be evidence that the major features of the protocol > > have been tested. > > > > 6) No operational experience is required for the routing protocol > > at this stage in the standardization process. > > > >Bert > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: Friday, March 01, 2002 2:58 PM > > > To: Wijnen, Bert (Bert) > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: WG dcoument status > > > > > > >.. snip .. > > > > > > showing up.... In other words... it might be good if people start to > > > > report implementation and interoperability test reults. > > > > > > Please note that in the RTG area (rfc1264) there is no requirement > > > for a Proposed Standard to have (a) more than one implementation, and > > > (b) for these implementations to be interoperable. > > > > > > Yakov. > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, 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, 01 Mar 2002 08:42:49 -0800 From: "John Strand" To: "Wijnen Bert \(Bert\)" , "ccamp-wg" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 1 Mar 2002 11:42:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My vote is for (1). John "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:42:00 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5D9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" , neil.2.harrison@bt.com Cc: erosen@cisco.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Fri, 1 Mar 2002 08:41:26 -0800 MIME-Version: 1.0 Content-Type: text/plain Thom, > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, March 01, 2002 11:08 AM > To: neil.2.harrison@bt.com > Cc: erosen@cisco.com; Shahram Davari; ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > >Eric/Shahram, see addtional remarks below. regards Neil > > > > > Shahram> 1) If a router is not GTTP upgraded, it will drop > > > the TTL expired > > > Shahram> GTTP messages. Consequently the host will not > > > receive any reply > > > Shahram> from that router, which translates to a break > > > in the tunnel at > > > Shahram> that point. > > > > > > For GTTP to be useful at all, the tunnel head ends must > support it. > > > > > > If a particular node within a tunnel does not support GTTP, > > > but some nodes > > > beyond it do, we won't get complete trace info, but > > > should be able to > > > continue tracing beyond the non-supporting node. > > > > > > But the basic point is valid, that in order to use GTTP to > > > trace through > > > your network, your routers must support it. I guess I > > > don't see this as > > > much of a problem. I wouldn't call it an interoperability > > > problem, because > > > no existing mechanisms are broken by the use of GTTP. > >NH=> If you noted in some of my earlier mails I was very > careful to refer to > >'simple breaks' when using trail-trace type of mechanisms for defect > >diagnosis. If you ever get a misbranching/mismerging defect then: > >- you need to know it exists in the 1st place (not > obvious how this > >can be done....with CV it's trivial, as you see the source ID of any > >offending LSP at the sink of the offended LSP, so you both > detect/diagnose > >immediately)....I'll ignore the fact that a whole raft of > consequent actions > >are also missing; > > Please clarify. I think what Neil is saying is that a path-trace is only a diagnostics tool. It can't be used to detect path-defects in real-time. You still need another tool to detect that the defect exists in the first place, and then you may use path-trace to find what the problem is. Also using a GTTP type of path-trace, you have to assume either: 1) the path is fine (has no defect) or 2) If there is any defect, it is a simple path-break defect. Defects such as misbranching, merging, etc can't be detected, unless: 1) All nodes are GTTP upgraded and 2) There is a return path from all nodes to the GTTP host > > >- since the location of such defects cannot be known a > priori, then if > >you want the 'misbranched' GTTP messages to elicit a > response then the > >arbitrary nodes where they end up must be able to respond......and in > >general this means the whole network/nodes need to be 'GTTP > aware' and they > >need a return channel to the source. > >IMO any trail-trace functions are best used under the > assumption that the > >network is actually defect-free.....we need other tools to > detect/handle the > >defects (for the many reasons I tried to point out in earlier mails). > > > > > > Shahram> 2) TTL expired user packets will now be forwarded to > > > UDP module > > > Shahram> instead of being dropped. Which could overload > > > the UDP module in > > > Shahram> certain situations. > > > > > > TTL-expired user packets are not simply dropped today; they > > > are forwarded to > > > the ICMP module to cause the generation of an ICMP message. > > > Usually there > > > is some sort of limit placed on the number of packets that > > > can be queued for > > > ICMP processing, or the number of such packets that can be > > > seen in a given > > > amount of time, etc. The marginal overhead to see whether > > > a packet that > > > makes it through to ICMP processing is a GTTP packet doesn't > > > seem like that > > > big a deal. > >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a > >possibility....and as Geroge hints in an earlier mail is > actually an example > >of a layer violation, but so be it. However, this should > not be used in > >XoverMPLS....you need a solution here that is self-contained > within the MPLS > >network. > > What is a "self-contained MPLS network"? MPLS > networks require IP > networks. > When running X over MPLS why does that requirement change at all? The basic philosophy of MPLS was to decouple forwarding from routing and signaling (control-plane). The idea was that any routing and signaling protocol could be used, without the need to change the forwarding paradigm. It is true that today we have LDP, CR-LDP, RSVP-TE, BGP, etc as control-plane. But we could also have configured LSPs (without signaling), and in future people may use other non-IP based routing/signaling protocols such as PNNI. Therefore developing an IP-based OAM for MPLS will unnecessarily limit the routing/signaling protocols that could be used for MPLS. If it was impossible to define a non-IP based OAM, then we had no choice, but it is possible. Yours, -Shahram > > --Tom > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:30:37 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E220@nimbus> From: John Drake To: 'Lou Berger' , "Wijnen, Bert (Bert)" Cc: Yakov Rekhter , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Fri, 1 Mar 2002 08:29:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lou, Please send me a form. Thanks, John -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Friday, March 01, 2002 8:20 AM To: Wijnen, Bert (Bert) Cc: Yakov Rekhter; Kireeti Kompella; ccamp@ops.ietf.org Subject: RE: WG dcoument status hmm, looks like all that is missing is a formal statement on 4. My guess is that just making a statement that one exists (and it does) isn't sufficient. I volunteer to pull together an implementation report. I'll send out a form later today, collect the info and post the results. Lou At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote: >Mmm.. RFC1264 says on page 4, pls note items 4) and 5): > > > 4.0 Requirements for Proposed Standard > > 1) Documents specifying the Protocol and its Usage. The > specification for the routing protocol must be well written such > that independent, interoperable implementations can be developed > solely based on the specification. For example, it should be > possible to develop an interoperable implementation without > consulting the original developers of the routing protocol. > > 2) A Management Information Base (MIB) must be written for the > protocol. The MIB does not need to submitted for Proposed > Standard at the same time as the routing protocol, but must be > at least an Internet Draft. > > 3) The security architecture of the protocol must be set forth > explicitly. The security architecture must include mechanisms for > authenticating routing messages and may include other forms of > protection. > > 4) One or more implementations must exist. > > 5) There must be evidence that the major features of the protocol > have been tested. > > 6) No operational experience is required for the routing protocol > at this stage in the standardization process. > >Bert > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, March 01, 2002 2:58 PM > > To: Wijnen, Bert (Bert) > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: WG dcoument status > > > >.. snip .. > > > > showing up.... In other words... it might be good if people start to > > > report implementation and interoperability test reults. > > > > Please note that in the RTG area (rfc1264) there is no requirement > > for a Proposed Standard to have (a) more than one implementation, and > > (b) for these implementations to be interoperable. > > > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:30:33 -0800 Message-ID: <3C7FAC7E.91771BDE@alcatel.de> Date: Fri, 01 Mar 2002 17:29:50 +0100 From: Dieter Beller Organization: Alcatel SEL AG, TND Stuttgart, Germany MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Kireeti Kompella Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: multipart/mixed; boundary="------------92F447776B4FA072BE972122" This is a multi-part message in MIME format. --------------92F447776B4FA072BE972122 Content-Type: multipart/alternative; boundary="------------5F237EA30320C44D576F5575" --------------5F237EA30320C44D576F5575 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My vote is for 2). Dieter ------------------------------------------------------------------------ > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 4:11 PM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote: > > > Guys... I have seen to much of this. I have asked Kireeti > > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the > > WG mailing list. I do NOT want another 500 emails going back > > and forth on this issue. We need to approach this pragmatically. > > > > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the > > WG mailing list on what exactly we agreed in SLC. That will > > help to prepare a response to ITU-T as well > > First off, I should apologize for letting this go on unchecked. > > Second, I should make it known to the WG as a whole that there was > a discussion of this issue at SLC among several folks directly > involved, the ADs and the chairs. I thought we had achieved > consensus, but now it seems not. > > Here's what I thought we had agreed: > > 1) There is a document in the ITU that defines a *single* standard that > encompasses both SONET and SDH -- almost. There are a few signals > that are in SONET but not in SDH; it was believed that the only such > signal was VC-3. Also, there are "legacy" implementations of SONET > that do not match the ITU document. > > 2) Thus, it was agreed (to my recollection) that both the SONET and > SDH label formats will be retained, with wording that says that > whenever possible, the SDH equivalent should be used. This covers > both the cases of SONET signals that don't have SDH equivalents, > and legacy equipment. > > It is *not* the IETF's intention to promote an artificial separation > between SONET and SDH. Nor is it the intent to promote as standard > work that is now "pre-standard". > > However, it *is* the IETF's goal to be able to set up paths across > SONET and SDH networks, and to be pragmatic about this. This was > the spirit in which an agreement was forged -- or so I thought. In > retrospect, it would have been wise to go one step further and > decide the actual words. > > So, here we are again, arguing over this. Let's follow the AD's > suggestion and look for consensus in the WG. > > 1) Do you think we should have just a single set of traffic parameters > and label values for SDH, and none for SONET? > or > 2) Do you think we should have one for SONET and one for SDH, with > the proviso that, if an SDH equivalent is available, one SHOULD > use the SDH equivalent? > or > 3) Do you think we should have one for SONET and one for SDH, with > the proviso that, if an SDH equivalent is available, one MUST > use the SDH equivalent? > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Feedback is welcome from *all* those interested in the CCAMP WG. > Also, what we are looking for is rough consensus, not votes. > > Thanks, > Kireeti. -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ V +---------------+ Dieter Beller | A L C A T E L | Alcatel Optics Group +---------------+ Terrestrial Networks Division Dept. US/EA3 Alcatel SEL AG Lorenzstrasse 10 D-70435 Stuttgart, Germany Phone: +49 711 821-43125 Fax: +49 711 821-42303 E-mailto:D.Beller@alcatel.de ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------5F237EA30320C44D576F5575 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My vote is for 2).

Dieter

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Sunday, February 24, 2002 4:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg;
> 'sob@harvard.edu'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
>
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> >
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
>
> First off, I should apologize for letting this go on unchecked.
>
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
>
> Here's what I thought we had agreed:
>
> 1) There is a document in the ITU that defines a *single* standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
>
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.

--

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        V
+---------------+      Dieter Beller
| A L C A T E L |      Alcatel Optics Group
+---------------+      Terrestrial Networks Division
                       Dept. US/EA3

                       Alcatel SEL AG
                       Lorenzstrasse 10
                       D-70435 Stuttgart, Germany

                       Phone:   +49 711 821-43125
                       Fax:     +49 711 821-42303

                       E-mailto:D.Beller@alcatel.de

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  --------------5F237EA30320C44D576F5575-- --------------92F447776B4FA072BE972122 Content-Type: text/x-vcard; charset=us-ascii; name="D.Beller.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dieter Beller Content-Disposition: attachment; filename="D.Beller.vcf" begin:vcard n:Beller;Dieter tel;fax:+49 711 821 - 42303 tel;work:+49 711 821 - 43125 x-mozilla-html:FALSE org:Alcatel - Optics Group - Terrestrial Networks Division;US/EA3 version:2.1 email;internet:D.Beller@alcatel.de adr;quoted-printable:;;Alcatel SEL AG,=0D=0ALorenzstrasse 10;Stuttgart;;70435;Germany fn:Beller, Dieter end:vcard --------------92F447776B4FA072BE972122-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:24:47 -0800 Message-Id: <4.3.2.7.2.20020301111513.01e8cc98@161.44.167.72> Date: Fri, 01 Mar 2002 11:23:57 -0500 To: neil.2.harrison@bt.com From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: swallow@cisco.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >George....you are simply wrong here *if* applied architecturally correctly. We need to remember one of the guiding principles of the IETF (remember Neil, this is not the ITU): working code and rough consensus. Both exist for most of the existing "oam" solutions. As Yakov said recently, "the proof is not necessarily in the pudding, but in the eating of the pudding." I want to eat pudding. Achitectural correctness is bunk if it does not leads to implementations that cannot support the architecture in such a way as to a) be implemented in one's lifetime, and b) can be sold for a reasonable price. If neither can be met, then we are all just wasting our time. >But please explain/list examples of layer violations you are aware of. >BTW - If anyone takes what you have written at face value then all tunnels >should be banned, ie they are *all* layer violations (I see Shahram also >noted exactly similar). Sadly, from what I see you may be actually correct >in many cases (ie relying on fault management of one layer to proxy for >inadequacies in another layer)....but you'd need to think the consequences >of that out very carefully and the potential implications before you take it >further. > >In the meantime..... > >Think of a leased line (as a server...any technology) that you do not >own.....or even a duct network (yes its a real network, bottom layer in >fact....and sets the inherited disjoint connectiveity graph for *all* layers >above it) that you do not own, and I am aware of Andy Reid of BT here >telling me you lost a bet with him over virtualisation here. A 'Tunnel' is >a colloquialism for a (more formally defined) server layer trail (which can >be a link connection between client layer nodes). If you don't/can't grok >this yet please read the text book by Reid/Sexton on Broadband Networking or >G.805.....and tell us what is factually wrong with what is in there. I am >finding these terse 'I know better than you' assertions not all >constructive....esp when they are plainly wrong, like this one (*if* done >arch correctly of course). I think what might be more constructive is to set out the current problems that you as an operator (and other operators) think need to be solved and then see how the existing solutions can be used to solve these problems. Please don't just refer us again to your OAM draft, because I think it is clear that is a non-starter. If there are still holes after this exercise, lets work together on these problems and find efficient and solvable solutions to them. This may not result in an architectural correct over-all grand reference, but it is probably going to get us further than arguing over what is architecturally pure and what is not, which IMHO is a waste of everyone's time. --Tom >Neil > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: 28 February 2002 17:12 > > To: Shahram Davari > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org; > > swallow@cisco.com > > Subject: Re: draft-bonica-tunneltrace-02 > > > > > > Shahram - > > > > > and layer violation issues. > > > > Any sort of a tunnel is a layer violation in and of itself. So if you > > have to violate those same layers to trace them so be it. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:22:01 -0800 Message-Id: <4.3.2.7.2.20020301111529.03bc28d0@mo-ex1> Date: Fri, 01 Mar 2002 11:20:20 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: WG dcoument status Cc: "Yakov Rekhter" , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed hmm, looks like all that is missing is a formal statement on 4. My guess is that just making a statement that one exists (and it does) isn't sufficient. I volunteer to pull together an implementation report. I'll send out a form later today, collect the info and post the results. Lou At 11:02 AM 3/1/2002, Wijnen, Bert (Bert) wrote: >Mmm.. RFC1264 says on page 4, pls note items 4) and 5): > > > 4.0 Requirements for Proposed Standard > > 1) Documents specifying the Protocol and its Usage. The > specification for the routing protocol must be well written such > that independent, interoperable implementations can be developed > solely based on the specification. For example, it should be > possible to develop an interoperable implementation without > consulting the original developers of the routing protocol. > > 2) A Management Information Base (MIB) must be written for the > protocol. The MIB does not need to submitted for Proposed > Standard at the same time as the routing protocol, but must be > at least an Internet Draft. > > 3) The security architecture of the protocol must be set forth > explicitly. The security architecture must include mechanisms for > authenticating routing messages and may include other forms of > protection. > > 4) One or more implementations must exist. > > 5) There must be evidence that the major features of the protocol > have been tested. > > 6) No operational experience is required for the routing protocol > at this stage in the standardization process. > >Bert > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, March 01, 2002 2:58 PM > > To: Wijnen, Bert (Bert) > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: WG dcoument status > > > >.. snip .. > > > > showing up.... In other words... it might be good if people start to > > > report implementation and interoperability test reults. > > > > Please note that in the RTG area (rfc1264) there is no requirement > > for a Proposed Standard to have (a) more than one implementation, and > > (b) for these implementations to be interoperable. > > > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:10:04 -0800 Message-Id: <4.3.2.7.2.20020301110502.01e8acd8@161.44.167.72> Date: Fri, 01 Mar 2002 11:08:25 -0500 To: neil.2.harrison@bt.com From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: erosen@cisco.com, Shahram_Davari@pmc-sierra.com, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Eric/Shahram, see addtional remarks below. regards Neil > > > Shahram> 1) If a router is not GTTP upgraded, it will drop > > the TTL expired > > Shahram> GTTP messages. Consequently the host will not > > receive any reply > > Shahram> from that router, which translates to a break > > in the tunnel at > > Shahram> that point. > > > > For GTTP to be useful at all, the tunnel head ends must support it. > > > > If a particular node within a tunnel does not support GTTP, > > but some nodes > > beyond it do, we won't get complete trace info, but > > should be able to > > continue tracing beyond the non-supporting node. > > > > But the basic point is valid, that in order to use GTTP to > > trace through > > your network, your routers must support it. I guess I > > don't see this as > > much of a problem. I wouldn't call it an interoperability > > problem, because > > no existing mechanisms are broken by the use of GTTP. >NH=> If you noted in some of my earlier mails I was very careful to refer to >'simple breaks' when using trail-trace type of mechanisms for defect >diagnosis. If you ever get a misbranching/mismerging defect then: >- you need to know it exists in the 1st place (not obvious how this >can be done....with CV it's trivial, as you see the source ID of any >offending LSP at the sink of the offended LSP, so you both detect/diagnose >immediately)....I'll ignore the fact that a whole raft of consequent actions >are also missing; Please clarify. >- since the location of such defects cannot be known a priori, then if >you want the 'misbranched' GTTP messages to elicit a response then the >arbitrary nodes where they end up must be able to respond......and in >general this means the whole network/nodes need to be 'GTTP aware' and they >need a return channel to the source. >IMO any trail-trace functions are best used under the assumption that the >network is actually defect-free.....we need other tools to detect/handle the >defects (for the many reasons I tried to point out in earlier mails). > > > > Shahram> 2) TTL expired user packets will now be forwarded to > > UDP module > > Shahram> instead of being dropped. Which could overload > > the UDP module in > > Shahram> certain situations. > > > > TTL-expired user packets are not simply dropped today; they > > are forwarded to > > the ICMP module to cause the generation of an ICMP message. > > Usually there > > is some sort of limit placed on the number of packets that > > can be queued for > > ICMP processing, or the number of such packets that can be > > seen in a given > > amount of time, etc. The marginal overhead to see whether > > a packet that > > makes it through to ICMP processing is a GTTP packet doesn't > > seem like that > > big a deal. >NH=> Asking ICMP to proxy for missing defect handling in MPLS is a >possibility....and as Geroge hints in an earlier mail is actually an example >of a layer violation, but so be it. However, this should not be used in >XoverMPLS....you need a solution here that is self-contained within the MPLS >network. What is a "self-contained MPLS network"? MPLS networks require IP networks. When running X over MPLS why does that requirement change at all? --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:02:52 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF1271056917FA@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Yakov Rekhter Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Fri, 1 Mar 2002 17:02:19 +0100 MIME-Version: 1.0 Content-Type: text/plain Mmm.. RFC1264 says on page 4, pls note items 4) and 5): 4.0 Requirements for Proposed Standard 1) Documents specifying the Protocol and its Usage. The specification for the routing protocol must be well written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol. 2) A Management Information Base (MIB) must be written for the protocol. The MIB does not need to submitted for Proposed Standard at the same time as the routing protocol, but must be at least an Internet Draft. 3) The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating routing messages and may include other forms of protection. 4) One or more implementations must exist. 5) There must be evidence that the major features of the protocol have been tested. 6) No operational experience is required for the routing protocol at this stage in the standardization process. Bert > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Friday, March 01, 2002 2:58 PM > To: Wijnen, Bert (Bert) > Cc: Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: WG dcoument status > .. snip .. > > showing up.... In other words... it might be good if people start to > > report implementation and interoperability test reults. > > Please note that in the RTG area (rfc1264) there is no requirement > for a Proposed Standard to have (a) more than one implementation, and > (b) for these implementations to be interoperable. > > Yakov. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 08:01:13 -0800 Message-Id: <200203011600.LAA24655@telescope.cisco.com> To: neil.2.harrison@bt.com cc: erosen@cisco.com, Shahram_Davari@pmc-sierra.com, ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: draft-bonica-tunneltrace-02 Date: Fri, 01 Mar 2002 11:00:40 -0500 From: George Swallow > NH=> Asking ICMP to proxy for missing defect handling in MPLS is a > possibility....and as Geroge hints in an earlier mail is actually an example > of a layer violation, but so be it. However, this should not be used in > XoverMPLS....you need a solution here that is self-contained within the MPLS > network. Have we found the crux of the matter? MPLS as defined by the IETF (and I personally don't believe any other body has jurisdiction over the core MPLS technology) requires that all boxes be IP capable. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 07:58:24 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127104D070E2@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Fri, 1 Mar 2002 16:57:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Let me make a Friday afternoon remark and than duck for the flak: IMHO, the layering concept (and the associated system of functional modelling) is to the study and design of (circuit based) transport networks what the Periodic System of Elements is to chemistry. Of course, you can do without, but with such an ordening principle the work in the field becomes a bit less intuitive and a bit more structured. If you like: less of an art and more of an engineering discipline. I'm afraid this does not progress the discussion on the bonica draft, but it might help getting the layering concept where it belongs ... Leen Mak. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 07:18:57 -0800 Message-Id: <200203011517.KAA17113@telescope.cisco.com> To: neil.2.harrison@bt.com cc: swallow@cisco.com, ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: draft-bonica-tunneltrace-02 Date: Fri, 01 Mar 2002 10:17:16 -0500 From: George Swallow > George....you are simply wrong here *if* applied architecturally correctly. Some folks build architectures, others build boxes. > But please explain/list examples of layer violations you are aware of. RFC2390 (nee RFC1293) employed by a very large part of the commercial world for the last decade. > BTW - If anyone takes what you have written at face value then all tunnels > should be banned, ie they are *all* layer violations (I see Shahram also The point of my message is that "a layer violation" is not one of the Ten Commandments nor part of Hammurabi's code. It's simply an engineering caveat of "beyond here, there be dragons". One needs to be very careful, but one needs also to be practical and cost effective. > [...] > inadequacies in another layer)....but you'd need to think the consequences > of that out very carefully and the potential implications before you take it > further. Yes! ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:57:42 -0800 Message-ID: <3C7F8E1A.9819063C@research.att.com> Date: Fri, 01 Mar 2002 09:20:11 -0500 From: Dongmei MIME-Version: 1.0 To: Kireeti Kompella Cc: "Wijnen, Bert (Bert)" , "Mannie, Eric" , mvissers@lucent.com, vijay@umbc.edu, ccamp-wg , sob@harvard.edu Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: multipart/alternative; boundary="------------88721D24A8786D769D30348E" --------------88721D24A8786D769D30348E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vote for 1. -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 7:11 PM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF > > > > > On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote: > > > Guys... I have seen to much of this. I have asked Kireeti > > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the > > WG mailing list. I do NOT want another 500 emails going back > > and forth on this issue. We need to approach this pragmatically. > > > > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the > > WG mailing list on what exactly we agreed in SLC. That will > > help to prepare a response to ITU-T as well > > First off, I should apologize for letting this go on unchecked. > > Second, I should make it known to the WG as a whole that there was > a discussion of this issue at SLC among several folks directly > involved, the ADs and the chairs. I thought we had achieved > consensus, but now it seems not. > > Here's what I thought we had agreed: > > 1) There is a document in the ITU that defines a *single* standard > that > encompasses both SONET and SDH -- almost. There are a few signals > that are in SONET but not in SDH; it was believed that the only > such > signal was VC-3. Also, there are "legacy" implementations of SONET > > that do not match the ITU document. > > 2) Thus, it was agreed (to my recollection) that both the SONET and > SDH label formats will be retained, with wording that says that > whenever possible, the SDH equivalent should be used. This covers > both the cases of SONET signals that don't have SDH equivalents, > and legacy equipment. > > It is *not* the IETF's intention to promote an artificial separation > between SONET and SDH. Nor is it the intent to promote as standard > work that is now "pre-standard". > > However, it *is* the IETF's goal to be able to set up paths across > SONET and SDH networks, and to be pragmatic about this. This was > the spirit in which an agreement was forged -- or so I thought. In > retrospect, it would have been wise to go one step further and > decide the actual words. > > So, here we are again, arguing over this. Let's follow the AD's > suggestion and look for consensus in the WG. > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > or > 2) Do you think we should have one for SONET and one for SDH, with > the proviso that, if an SDH equivalent is available, one SHOULD > use the SDH equivalent? > or > 3) Do you think we should have one for SONET and one for SDH, with > the proviso that, if an SDH equivalent is available, one MUST > use the SDH equivalent? > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Feedback is welcome from *all* those interested in the CCAMP WG. > Also, what we are looking for is rough consensus, not votes. > > Thanks, > Kireeti. > --------------88721D24A8786D769D30348E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Vote for 1.

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

From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Sunday, February 24, 2002 7:11 PM
To: Wijnen, Bert (Bert)
Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg;
'sob@harvard.edu'
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
 
 
 

On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:

> Guys... I have seen to much of this. I have asked Kireeti
> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> WG mailing list. I do NOT want another 500 emails going back
> and forth on this issue. We need to approach this pragmatically.
>
> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
>   WG mailing list on what exactly we agreed in SLC. That will
>   help to prepare a response to ITU-T as well

First off, I should apologize for letting this go on unchecked.

Second, I should make it known to the WG as a whole that there was
a discussion of this issue at SLC among several folks directly
involved, the ADs and the chairs.  I thought we had achieved
consensus, but now it seems not.

Here's what I thought we had agreed:

1) There is a document in the ITU that defines a *single* standard that
   encompasses both SONET and SDH -- almost.  There are a few signals
   that are in SONET but not in SDH; it was believed that the only such
   signal was VC-3.  Also, there are "legacy" implementations of SONET
   that do not match the ITU document.

2) Thus, it was agreed (to my recollection) that both the SONET and
   SDH label formats will be retained, with wording that says that
   whenever possible, the SDH equivalent should be used.  This covers
   both the cases of SONET signals that don't have SDH equivalents,
   and legacy equipment.

It is *not* the IETF's intention to promote an artificial separation
between SONET and SDH.  Nor is it the intent to promote as standard
work that is now "pre-standard".

However, it *is* the IETF's goal to be able to set up paths across
SONET and SDH networks, and to be pragmatic about this.  This was
the spirit in which an agreement was forged -- or so I thought.  In
retrospect, it would have been wise to go one step further and
decide the actual words.

So, here we are again, arguing over this.  Let's follow the AD's
suggestion and look for consensus in the WG.

1) Do you think we should have just a single set of traffic parameters
   and label values for SDH, and none for SONET?
or
2) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one SHOULD
   use the SDH equivalent?
or
3) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one MUST
   use the SDH equivalent?

(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)

PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Feedback is welcome from *all* those interested in the CCAMP WG.
Also, what we are looking for is rough consensus, not votes.

Thanks,
Kireeti.
 

--------------88721D24A8786D769D30348E-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:55:43 -0800 Message-ID: <3C7F98E1.6ADE28@research.att.com> Date: Fri, 01 Mar 2002 10:06:09 -0500 From: Guangzhi Li MIME-Version: 1.0 Cc: "ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (1) is better. -- Guangzhi Diego Caviglia wrote: > I do agree with Jennifer. > > My vote is (1). > > Diego. > > Jennifer Yates @ops.ietf.org on 01/03/2002 > 15.16.27 > > Sent by: owner-ccamp@ops.ietf.org > > To: "Wijnen, Bert (Bert)" > cc: ccamp-wg > > Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF > > My vote is for (1). > > Jen > > "Wijnen, Bert (Bert)" wrote: > > > CCAMP WG members, > > > > before we start down another many 100s of emails re-discussing > > the same topic.... > > > > PLEASE express your support for one of the 3 options that Kireeti > > posed to the WG. Don't elaborate... just help the WG chair(s) to > > figure out the (rough) consensus of the WG. The choices formulated > > by Kireeti: > > > > > So, here we are again, arguing over this. Let's follow the AD's > > > suggestion and look for consensus in the WG. > > > > > > 1) Do you think we should have just a single set of traffic parameters > > > and label values for SDH, and none for SONET? > > > or > > > 2) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one SHOULD > > > use the SDH equivalent? > > > or > > > 3) Do you think we should have one for SONET and one for SDH, with > > > the proviso that, if an SDH equivalent is available, one MUST > > > use the SDH equivalent? > > > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > > > Thanks > > Bert, speaking as AD who would like to see the WG take > > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:46:08 -0800 Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF To: "ccamp-wg From: "Diego Caviglia" Date: Fri, 1 Mar 2002 15:45:08 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I do agree with Jennifer. My vote is (1). Diego. Jennifer Yates @ops.ietf.org on 01/03/2002 15.16.27 Sent by: owner-ccamp@ops.ietf.org To: "Wijnen, Bert (Bert)" cc: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF My vote is for (1). Jen "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:44:02 -0800 From: Bart.Rousseau@alcatel.be Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF To: bwijnen@lucent.com, ccamp@ops.ietf.org Date: Fri, 1 Mar 2002 15:43:34 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii My preference would go to option (2). Bart. "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:37:14 -0800 Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF To: "ccamp-wg Cc: "Kireeti Kompella From: "Mario Molinari" Date: Fri, 1 Mar 2002 15:35:54 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii If I'm not too late, I'd like to express my vote for (1). Mario Kireeti Kompella @ops.ietf.org on 25/02/2002 01.10.36 Sent by: owner-ccamp@ops.ietf.org To: "Wijnen, Bert (Bert)" cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote: > Guys... I have seen to much of this. I have asked Kireeti > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the > WG mailing list. I do NOT want another 500 emails going back > and forth on this issue. We need to approach this pragmatically. > > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the > WG mailing list on what exactly we agreed in SLC. That will > help to prepare a response to ITU-T as well First off, I should apologize for letting this go on unchecked. Second, I should make it known to the WG as a whole that there was a discussion of this issue at SLC among several folks directly involved, the ADs and the chairs. I thought we had achieved consensus, but now it seems not. Here's what I thought we had agreed: 1) There is a document in the ITU that defines a *single* standard that encompasses both SONET and SDH -- almost. There are a few signals that are in SONET but not in SDH; it was believed that the only such signal was VC-3. Also, there are "legacy" implementations of SONET that do not match the ITU document. 2) Thus, it was agreed (to my recollection) that both the SONET and SDH label formats will be retained, with wording that says that whenever possible, the SDH equivalent should be used. This covers both the cases of SONET signals that don't have SDH equivalents, and legacy equipment. It is *not* the IETF's intention to promote an artificial separation between SONET and SDH. Nor is it the intent to promote as standard work that is now "pre-standard". However, it *is* the IETF's goal to be able to set up paths across SONET and SDH networks, and to be pragmatic about this. This was the spirit in which an agreement was forged -- or so I thought. In retrospect, it would have been wise to go one step further and decide the actual words. So, here we are again, arguing over this. Let's follow the AD's suggestion and look for consensus in the WG. 1) Do you think we should have just a single set of traffic parameters and label values for SDH, and none for SONET? or 2) Do you think we should have one for SONET and one for SDH, with the proviso that, if an SDH equivalent is available, one SHOULD use the SDH equivalent? or 3) Do you think we should have one for SONET and one for SDH, with the proviso that, if an SDH equivalent is available, one MUST use the SDH equivalent? (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) PLEASE respond with just (1), (2) or (3), and avoid long diatribes! Feedback is welcome from *all* those interested in the CCAMP WG. Also, what we are looking for is rough consensus, not votes. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:36:13 -0800 Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF To: "Wijnen, Bert (Bert)" , ccamp-wg Message-ID: From: sven.van_den_bosch@alcatel.be Date: Fri, 1 Mar 2002 15:34:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii My preference would go to option (2). Sven. Jennifer Yates on 01/03/2002 15:16:27 To: "Wijnen, Bert (Bert)" cc: ccamp-wg (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject Re: SONET/SDH label agreement for IETF, ITU-T : and OIF My vote is for (1). Jen "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:28:47 -0800 Message-ID: <002b01c1c103$9668ae70$ad36989e@Boycie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Brian Moore" To: , Cc: Subject: Re: draft-bonica-tunneltrace-02 Date: Fri, 1 Mar 2002 09:29:28 -0000 [ post by non-subscriber ] Neil, Just to let you know that we (SG13) have set up an ftp site to allow us to share documents with our IETF colleagues. The process for registering for access is described on the site (http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html). The draft Rec Y.1711 is on the site. Brian. B W Moore Lucent Technologies bmoore1@lucent.com Tel: +44 1206 762335 Fax: +44 1206 762336 ----- Original Message ----- From: To: Cc: ; Sent: Thursday, February 28, 2002 10:08 PM Subject: RE: draft-bonica-tunneltrace-02 > Thanks Steve....nice to hear a voice of sanity. > > Just FYI.....many people from various IETF lists have privately asked me for > copies of Y.1711 (and/or Y.1710 - requirements/principles) and I have have > passed them on. Also SG13 have sent formal liaisons to IETF/ATMF/MPLSF on > these already. If anyone else wants a copy until such time they become > publically available please ask me and I'll do my best to post on.....but be > prepared for a little delay as I'll be travelling from tomorrow for a week > or so. > > As an aside.....this ITU/IETF bickering is really helping nobody here. Each > side can learn from the other. I get really sad when I see destructive > comments about the G.805 layering/partitioning arch > stuff......why?....because its how we all actually work even if some of us > don't actually consciously recognise it. G.805 just gives it a formal > base....and its a damn sight more useful than the almost useless L1/2/3 > classifications (which mean nothing) and the OSI model which gives the > illusion there is only *one* layer network (at L3, OSI sense)....absolute > bunkum. G.805 matches reality. Give it a shot. > > regards, Neil > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: 28 February 2002 17:28 > > To: Shahram Davari > > Cc: 'erosen@cisco.com'; 'Randy Bush'; Cuevas, Enrique G, ALASO; > > ccamp@ops.ietf.org; Brian Moore > > Subject: Re: draft-bonica-tunneltrace-02 > > > > > > (snip) > > > Why? Simply because it is produced by ITU is not a logical > > way to dismiss it. > > > Do you think the ITU architecture is wrong and if so why? > > and what architecture > > > (if any!) do you suggest that the requirements and > > solutions should fit in to? > > ITU and IETF do have a formal cooperation agreement. This > > does not mean that > > either organization needs to do what the other says, but in > > the event IETF were > > to choose to diverge, it would at least be polite to send a > > communication to > > the relevante ITU-T study group (in this case, SG13) to > > indicate why. ITU-T > > input should at least be given serious consideration. > > > > > As has been stated these are to a > > > large extent documented in the (sadly too new to get at for > > free) documents > > > Y.1711/Y.1710 but were in the now expired though surely google-able > > > draft-harrison... > > My understanding is that these should be made available to > > IETF through a > > public ftp site in the next few days. Material from Study > > Group 15 has been > > shared in this way in the past. A similar mechanism is now > > being set up for > > Study Group 13. > > > > Regards, > > Steve Trowbridge > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:19:54 -0800 Message-ID: <3C7F8D3B.5FF00952@research.att.com> Date: Fri, 01 Mar 2002 09:16:27 -0500 From: Jennifer Yates MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My vote is for (1). Jen "Wijnen, Bert (Bert)" wrote: > CCAMP WG members, > > before we start down another many 100s of emails re-discussing > the same topic.... > > PLEASE express your support for one of the 3 options that Kireeti > posed to the WG. Don't elaborate... just help the WG chair(s) to > figure out the (rough) consensus of the WG. The choices formulated > by Kireeti: > > > So, here we are again, arguing over this. Let's follow the AD's > > suggestion and look for consensus in the WG. > > > > 1) Do you think we should have just a single set of traffic parameters > > and label values for SDH, and none for SONET? > > or > > 2) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one SHOULD > > use the SDH equivalent? > > or > > 3) Do you think we should have one for SONET and one for SDH, with > > the proviso that, if an SDH equivalent is available, one MUST > > use the SDH equivalent? > > > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.) > > > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! > > Thanks > Bert, speaking as AD who would like to see the WG take > a decision on this topic. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 06:02:46 -0800 Message-Id: <200203011358.g21DwGT16034@merlot.juniper.net> To: "Wijnen, Bert (Bert)" cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG dcoument status MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72085.1014991096.1@juniper.net> Date: Fri, 01 Mar 2002 05:58:16 -0800 From: Yakov Rekhter Bert, > > Bert Wijnen (AD) has suggested that there should be an implementation > > statement before these move on to IETF Last Call; the WG chairs and > > draft editors agreed. > > Pls note that we discussed this in the SUB-IP Directorate and that a > wider set of people agreed. The reason why we do this is based on earlier > practice in the RTG area in that a protocol that touches the core of the > network, that we do want to see implementation/interoperability reports > at the PS stage as opposed to at the DS stage. > > This report is to be prepared by the WG (chairs). And it needs to be sent > to iesg-secretary who will put it online on the IETF webpages, so that > during IETF Last Call people can actually look at the reports. > > Please also not that some people worred (back at SLC meeting) that this > might delay the docs too much. I would like to remind you that it is now > 2.5 months later, and I have still not seen any signs of such a report. > So don't blame the process if things get delayed because of a report not > showing up.... In other words... it might be good if people start to > report implementation and interoperability test reults. Please note that in the RTG area (rfc1264) there is no requirement for a Proposed Standard to have (a) more than one implementation, and (b) for these implementations to be interoperable. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Mar 2002 00:34:54 -0800 Message-ID: <3C7F3CBB.6070004@utfors.se> Date: Fri, 01 Mar 2002 09:32:59 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Shahram Davari , 'Randy Bush' , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David Allan wrote: > Loa: > > First observation is that this has gone on way too long. T'would be nice > to see the chairs or ADs make a decision as to whether consensus exists > in one direction or another. seem like a good idea! /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se