Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 May 2003 16:53:20 +0000 Date: Sat, 31 May 2003 12:51:05 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq To: Xiaoming Fu Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Xiaoming, Thanks for the thorough review. A new version of the draft is available at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt. Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Xiaoming Fu > Sent: Friday, May 30, 2003 7:20 PM > To: Ron Bonica > Cc: ccamp@ops.ietf.org > Subject: Re: draft-ietf-ccamp-tracereq > > > Ron, > > It is a nice document. I went it through and have a few comments: > > - Section 3, 9) - "forwarding plane failu res" ==> _failures_ Oops.... > > - I didn't understand why the following paragraph appears twice - the > same in Section 3, 13) and 14). I assume you're talking about control > plane failure in 13). > Justification: MTU information is sometimes useful in identifying > the root cause of forwarding plane failures. You have a point. MTU information, in either direction, can be useful in debugging both control and forwarding plane failures. The paragraph should read as follows in both 3.13 and 3.14: Justification: MTU information is sometimes useful in identifying the root cause of forwarding and control plane failures. > > - Again, Section 3, 14): > 14) When tracing through the forwarding plane, display the MTU > associated with each hop in the reverse direction. > Meanwhile, in Section 4.3: > The protocol must be stateless. That is, nodes should not have to > maintain state between successive traceroute messages. > Are you assuming the probe and response messages are always hop-by-hop > addressed? Otherwise, the forwarding and reverse paths of transporting > the probe & response pair could differ, e.g., due to the Internet > routing, or policies. And - > Do we need a same transport path for them? If so, how a stateless > traceroute protocol knows the reverse path to forward the response > message? Probably we could create a temporary state while handling a > probe message, to include P_HOP & Interface information like in RSVP, > although the state is used only once in this case. Requirements 13 and 14 are ambiguous. As a result, you have interpretted them in a manner that was not intended. They should be restated as follows: 13) When tracing through the control plane, display the MTU associated with interface that forwards datagrams through the traced path. 14) When tracing through the forwarding plane, display the MTU associated with each interface that receives datagtrams along the traced path. > > - Section 4.1 - I don't understand the following sentense: > Many network forward datagrams that specify > IP options differently than they would forward datagrams that do not > specify IP options. > Maybe they ==> them, but the implication of this sentense is still > unclear to me. This paragraph should read as follows: Many networks forward datagrams that specify IP options differently than they would forward datagrams that do not specify IP options. Therefore, the introductions of IP options would cause the application to trace a forwarding path other than the path that its user intended to trace. > > - Section 4.2 "IP was _disqualified_ in order to conserve protocol > identifiers." - I'm not sure this is always valid. Anyway, > using UDP would have also to request a port number from IANA; there > is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP > type. BTW, UDP may introduce a little (although minor) > additional overhead. IANA is much more willing to assign UDP port numbers than protocol-IDs. This is because there are so many more UDP port numbers available. > > - In general I would expect the document would not constrain too much > on protocol details - the latter looks to me more of a protocol > design issue, instead of an informational RFC on "requirement". In principle, I agree. Section 4 provides just enough protocol requirements to keep protocol designers away from some known bad design approaches. For example, years ago we tried returning MPLS information in ICMP datagrams. This wasn't well received. So, the requirements document guides us around that bad approach. > > - It looks better if an experimental traceroute protocol (RFC1393 - > traceroute using an IP option) would be referenced and shortly > introduced in Section 2 (e.g., MTU determination). I thought about referencing RFC 1393 but decided not to because it is not widely known or implemented. Ron > > My 2 cents. > > Xiaoming > > Ron Bonica wrote: > > Folks, > > > > At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and > > sent a new copy to the draft editor. Until the draft editor > posts it, a copy > > can be found at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt. > > Please take a look, as this draft will need to go through another WG last > call. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli > > -- Xiaoming Fu University of Goettingen, Telematics Group Lotzestr. 16-18, 37083 Goettingen, Germany Tel.+49-551-39 14411, Fax.+49-551-39 14403 http://www.ifi.informatik.uni-goettingen.de Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 May 2003 07:22:22 +0000 Date: Sat, 31 May 2003 00:21:02 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org Subject: Re: ASON reqts - Moving on? Message-ID: <20030530154751.J81934@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 May 2003, Adrian Farrel wrote: > Kireeti, what are the next steps? Sorry that this has been so long. First of all, there is good consensus to make the ASON requirements doc (draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt) a CCAMP WG document. Authors, please resubmit it as a WG document. However, the ADs, seeing signs of World War III on this list for the umpteenth time, want to be clear where this is going. The rules of engagement are: 1) We *really* need to make sure that the ITU is in the loop on this -- that they tell us when we get things wrong or we miss things, and participate actively in reviewing the document. Fortunately, the draft is based on work done by folks active in the ITU, so we should have a good start; but we need to keep that up. If this means regular Liaison statements back and forth, so be it. 2) Regarding whether this work falls under the purview of CCAMP, CCAMP's charter is to "define signalling protocols and measurement protocols such that they support ... O-O and O-E-O optical switches", i.e., optical networks, and ASON is a very important example of an optical network. 3) It is thus incumbent on us as a group to define the requirements, and see whether GMPLS measures up; if so, document that; and if not, decide what needs to be done. 4) Let's do this with grace -- no inter-SDO or any other kind of egg throwing. It might be less fun that way, but it is definitely more productive. Since we are going down this path, I guess I should address Steve's questions re motivations for this document: | 5. Those who think that ITU-T didn't get the requirements right, so we | need to look at everything from scratch. This is explicitly *not* the intent. A requirement goes into this document iff: (a) the ITU-T says, "Yes, that's a requirement for ASON signaling"; and (b) CCAMP and the ITU-T agree that GMPLS doesn't meet it. Requirements that are already met MAY be documented, but it is not a goal to capture all ASON requirements. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 May 2003 05:42:07 +0000 Date: Fri, 30 May 2003 22:40:05 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Time slots for CCAMP 57 Message-ID: <20030530223234.L83077@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Please submit your requests for time slots for the CCAMP meeting at the 57th IETF to Ron and me. Note that to get a time slot, you MUST have submitted a draft by the draft deadline (June 30, 9:00AM ET). Furthermore, these time slots are for discussing and resolving issues raised on the mailing list, or for first time drafts, a *very* brief overview of the idea, why it's relevant, and how it fits into the CCAMP charter. No presentations! If you request a time slot, please follow up and start an email discussion on the CCAMP list. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 May 2003 01:57:15 +0000 Date: Fri, 30 May 2003 18:55:31 -0700 (PDT) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org, Stephen Trowbridge , "Wijnen, Bert" , "" , "Ronald P. Bonica" , "'Lam, Hing-Kam (Kam)'" Subject: RE: ASON RSVP-TE extensions Message-ID: <20030530185248.O81934@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 30 May 2003, Ong, Lyndon wrote: > The cutoff for uploading documents for the ITU meeting in > Chicago is this Monday - given the short time I wonder if > you couldn't just submit this as a contribution from > yourself and Ron as co-chairs of CCAMP (considering that > you were invited to participate). I'm copying this to > Kam Lam as well for his feedback. Good idea. I'll wait till Monday, and if I don't see any feedback, I will send formally to Kam Lam so that I can present it there. As for a formal Liaison, we can send that when the CCAMP WG has converged on the text. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 23:34:55 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A250158@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Cc: Stephen Trowbridge , "Wijnen, Bert" , zinin@psg.com, "Ronald P. Bonica" , "'Lam, Hing-Kam (Kam)'" Subject: RE: ASON RSVP-TE extensions Date: Fri, 30 May 2003 16:37:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, The cutoff for uploading documents for the ITU meeting in Chicago is this Monday - given the short time I wonder if you couldn't just submit this as a contribution from yourself and Ron as co-chairs of CCAMP (considering that you were invited to participate). I'm copying this to Kam Lam as well for his feedback. Cheers, Lyndon -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, May 30, 2003 3:46 PM To: ccamp@ops.ietf.org Cc: Stephen Trowbridge; Wijnen, Bert; zinin@psg.com; Ronald P. Bonica; Kireeti Kompella Subject: ASON RSVP-TE extensions Hi All, We would like to send the following as a Liaison to the ITU-T from the CCAMP WG. Please comment on the text. Ideally, we would like to send this out before the interim meeting in Chicago, and discuss it there. It would be helpful in this context to know what it means procedurally that a document "has been consented" in the ITU. Kireeti. ---------------------------------------------------------------------- To: ... From: ... Following up on the code point allocations in RFC 3474, we (the CCAMP WG) seek clarification on some further points. Regarding the following paragraph in the Introduction of the pre-publication draft of RFC 3474 which reads: Note that from the perspective of the ASON model ResvErr and ResvTear messages are not used. For backwards compatibility, when an ASON- compliant GMPLS node receives either a ResvErr or ResvTear as a response during the setup phase of message exchange, the GMPLS-ASON node should instead issue a PathTear message downstream and a PathErr (with Path_State_Removed flag set) message upstream. This is so that RSVP states are immediately removed upon error during the setup process. Removing this is a vital step in keeping the base semantics of the RSVP protocol intact. In particular, it would be unexpected and possibly fatal if as a consequence of a node issuing a ResvErr (and expecting the removal of Resv state alone), Path state were to be removed as well due to the "translation" of a ResvErr to a PathErr (with Path_State_Removed flag set) plus a PathTear. We thank you that you did so in RFC 3474 prior to publication. We understand that RFC 3474 is based in part on G.7713.2. In G.7713.2, we see no similar paragraph. The closest is the following, from Appendix III Protocol Elements Not Used (p. 46), which says in part: - ResvErr This message is modified from definitions in RFC 2205 and RFC 2961, with further extensions to support distributed connection management. This message is used to - Respond to a Resv connection setup request (when encountering problems with setup); however, note that in the GMPLS implementation where a connection setup error requires releasing the connection, and since ResvErr does not remove Path states, the PathTear is used for GMPLS connection-oriented network to remove Path states, i.e., ResvErr is not used during setup and release. G.7713.2 is silent on what is to be done if an implementation were in fact to receive a ResvErr or ResvTear message. We believe the Recommendation is incomplete without describing what should happen in this event. Is it intended that the behaviour of a node receiving a ResvErr/ResvTear be left unspecified, or is an explicit statement is forthcoming? Sincerely, Ronald Bonica and Kireeti Kompella, CCAMP WG chairs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 23:21:42 +0000 Message-ID: <3ED7E714.3080506@cs.uni-goettingen.de> Date: Sat, 31 May 2003 01:19:48 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-tracereq Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ron, It is a nice document. I went it through and have a few comments: - Section 3, 9) - "forwarding plane failu res" ==> _failures_ - I didn't understand why the following paragraph appears twice - the same in Section 3, 13) and 14). I assume you're talking about control plane failure in 13). Justification: MTU information is sometimes useful in identifying the root cause of forwarding plane failures. - Again, Section 3, 14): 14) When tracing through the forwarding plane, display the MTU associated with each hop in the reverse direction. Meanwhile, in Section 4.3: The protocol must be stateless. That is, nodes should not have to maintain state between successive traceroute messages. Are you assuming the probe and response messages are always hop-by-hop addressed? Otherwise, the forwarding and reverse paths of transporting the probe & response pair could differ, e.g., due to the Internet routing, or policies. And - Do we need a same transport path for them? If so, how a stateless traceroute protocol knows the reverse path to forward the response message? Probably we could create a temporary state while handling a probe message, to include P_HOP & Interface information like in RSVP, although the state is used only once in this case. - Section 4.1 - I don't understand the following sentense: Many network forward datagrams that specify IP options differently than they would forward datagrams that do not specify IP options. Maybe they ==> them, but the implication of this sentense is still unclear to me. - Section 4.2 "IP was _disqualified_ in order to conserve protocol identifiers." - I'm not sure this is always valid. Anyway, using UDP would have also to request a port number from IANA; there is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP type. BTW, UDP may introduce a little (although minor) additional overhead. - In general I would expect the document would not constrain too much on protocol details - the latter looks to me more of a protocol design issue, instead of an informational RFC on "requirement". - It looks better if an experimental traceroute protocol (RFC1393 - traceroute using an IP option) would be referenced and shortly introduced in Section 2 (e.g., MTU determination). My 2 cents. Xiaoming Ron Bonica wrote: > Folks, > > At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and > sent a new copy to the draft editor. Until the draft editor posts it, a copy > can be found at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt. > > Please take a look, as this draft will need to go through another WG last > call. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli > > -- Xiaoming Fu University of Goettingen, Telematics Group Lotzestr. 16-18, 37083 Goettingen, Germany Tel.+49-551-39 14411, Fax.+49-551-39 14403 http://www.ifi.informatik.uni-goettingen.de Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 22:48:43 +0000 Date: Fri, 30 May 2003 15:45:35 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: Stephen Trowbridge , "Wijnen, Bert" , "" , "Ronald P. Bonica" , Kireeti Kompella Subject: ASON RSVP-TE extensions Message-ID: <20030525154601.J58333@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, We would like to send the following as a Liaison to the ITU-T from the CCAMP WG. Please comment on the text. Ideally, we would like to send this out before the interim meeting in Chicago, and discuss it there. It would be helpful in this context to know what it means procedurally that a document "has been consented" in the ITU. Kireeti. ---------------------------------------------------------------------- To: ... From: ... Following up on the code point allocations in RFC 3474, we (the CCAMP WG) seek clarification on some further points. Regarding the following paragraph in the Introduction of the pre-publication draft of RFC 3474 which reads: Note that from the perspective of the ASON model ResvErr and ResvTear messages are not used. For backwards compatibility, when an ASON- compliant GMPLS node receives either a ResvErr or ResvTear as a response during the setup phase of message exchange, the GMPLS-ASON node should instead issue a PathTear message downstream and a PathErr (with Path_State_Removed flag set) message upstream. This is so that RSVP states are immediately removed upon error during the setup process. Removing this is a vital step in keeping the base semantics of the RSVP protocol intact. In particular, it would be unexpected and possibly fatal if as a consequence of a node issuing a ResvErr (and expecting the removal of Resv state alone), Path state were to be removed as well due to the "translation" of a ResvErr to a PathErr (with Path_State_Removed flag set) plus a PathTear. We thank you that you did so in RFC 3474 prior to publication. We understand that RFC 3474 is based in part on G.7713.2. In G.7713.2, we see no similar paragraph. The closest is the following, from Appendix III Protocol Elements Not Used (p. 46), which says in part: - ResvErr This message is modified from definitions in RFC 2205 and RFC 2961, with further extensions to support distributed connection management. This message is used to - Respond to a Resv connection setup request (when encountering problems with setup); however, note that in the GMPLS implementation where a connection setup error requires releasing the connection, and since ResvErr does not remove Path states, the PathTear is used for GMPLS connection-oriented network to remove Path states, i.e., ResvErr is not used during setup and release. G.7713.2 is silent on what is to be done if an implementation were in fact to receive a ResvErr or ResvTear message. We believe the Recommendation is incomplete without describing what should happen in this event. Is it intended that the behaviour of a node receiving a ResvErr/ResvTear be left unspecified, or is an explicit statement is forthcoming? Sincerely, Ronald Bonica and Kireeti Kompella, CCAMP WG chairs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 11:14:59 +0000 Message-Id: <200305301113.HAA27952@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-g709-04.txt Date: Fri, 30 May 2003 07:13:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-g709-04.txt Pages : 21 Date : 2003-5-29 This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the 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-ietf-ccamp-gmpls-g709-04.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-g709-04.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-g709-04.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: <2003-5-29161243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161243.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 11:14:50 +0000 Message-Id: <200305301113.HAA27968@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt Date: Fri, 30 May 2003 07:13:05 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : SONET/SDH Encoding for Link Management Protocol (LMP) Test messages Author(s) : J. Lang, D. Papadimitriou Filename : draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt Pages : 15 Date : 2003-5-29 This document details the Synchronous Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH) technology specific information needed when sending Link Management Protocol (LMP) test messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-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-test-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-lmp-test-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: <2003-5-29161314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161314.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 May 2003 03:37:16 +0000 Date: Thu, 29 May 2003 23:32:25 -0400 From: Ron Bonica Subject: draft-ietf-ccamp-tracereq To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and sent a new copy to the draft editor. Until the draft editor posts it, a copy can be found at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt. Please take a look, as this draft will need to go through another WG last call. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "We are not on Earth to guard a museum, but to cultivate a flourishing garden of life." -- Angelo Giuseppe Roncalli Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2003 15:12:01 +0000 Date: Thu, 29 May 2003 11:06:45 -0400 From: Ron Bonica Subject: RE: Route Exclusion To: Adrian Farrel , 'Kireeti Kompella' , ccamp@ops.ietf.org Cc: stefaan.de_cnodder@alcatel.be, Cheng-Yin.Lee@alcatel.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, Are there any objections to adopting the route exclusion draft as a WG item? If so, please post them to the mailing list by June 5. If not, CCAMP will adopt the draft as a WG item. Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Tuesday, May 27, 2003 3:57 PM > To: 'Kireeti Kompella'; Ron Bonica; ccamp@ops.ietf.org > Cc: stefaan.de_cnodder@alcatel.be; Cheng-Yin.Lee@alcatel.com; Adrian > Farrel > Subject: Route Exclusion > > > Kireeti, Ron, > > You may recall that at SF there was a surprisingly large number > of people (30+) > who had read this draft and expressed an interest. (In today's > climate, it seems > unusual if all of the authors have read a draft!) > > We (the authors) are also seeing a fair bit of interest expressed > to us from > people who need the function and want to go ahead and start > implementing - they > want to know what the future of the draft is. At the same time, > the ASON work > seems to be pulling in this requirement, and I shouldn't be surprised if > multi-area/multi-domain/multi-AS decides it is a requirement, too. > > So the question for you is, what do we do with this draft? > > There appear to be three possibilies: > > 1. The draft becomes a WG draft in the near future, and continues > to develop > with input from the WG. > > 2. The authors continue to spend their efforts on the draft with > no particular > IETF target in sight and without the GMPLS community having any realistic > expectation of the draft going anywhere. Other standards bodies, > needing the > function, develop their own alternatives and so on... > > 3. The authors bring the draft forward as an individual > submission to the IESG. > > Well, you can guess which I think is the best idea. > > What do you think? > > Cheers, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2003 13:17:10 +0000 Message-ID: <028801c325e4$622fb210$681810ac@movaz.com> From: "Adrian Farrel" To: , , Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt Date: Thu, 29 May 2003 09:15:32 -0400 FYI, Changes are minor nits and synchronization of new (final?) versions of the MIB drafts that have come out. Adrian ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, May 29, 2003 7:20 AM Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Multiprotocol Label Switching (MPLS) Management > Overview > Author(s) : T. Nadeau, C. Srinivasan, A. Farrel > Filename : draft-ietf-mpls-mgmt-overview-05.txt > Pages : 28 > Date : 2003-5-28 > > A range of Management Information Base (MIB) modules has > been developed to help model and manage the various aspects > of Multiprotocol Label Switching (MPLS) networks. These MIB > modules are defined in separate documents that focus on the > specific areas of responsibility of the modules that they > describe. > This memo describes the management architecture for MPLS > and indicates the inter-relationships between the different > MIB modules used for MPLS network management. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-05.txt > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 May 2003 11:22:50 +0000 Message-Id: <200305291120.HAA26929@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mpls@uu.net, te-wg@ops.ietf.org, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-05.txt Date: Thu, 29 May 2003 07:20:17 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Management Overview Author(s) : T. Nadeau, C. Srinivasan, A. Farrel Filename : draft-ietf-mpls-mgmt-overview-05.txt Pages : 28 Date : 2003-5-28 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-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-mpls-mgmt-overview-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-mpls-mgmt-overview-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: <2003-5-29072815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mgmt-overview-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072815.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 May 2003 11:47:47 +0000 Message-Id: <200305281146.HAA25754@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-recovery-analysis-01.txt Date: Wed, 28 May 2003 07:46:36 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Generalized MPLS-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-01.txt Pages : 40 Date : 2003-5-27 This document provides an analysis grid that can be used to evaluate, compare and contrast the numerous Generalized MPLS (GMPLS)-based recovery mechanisms currently proposed at the CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in [CCAMP-TERM]. Also, this document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-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-recovery-analysis-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-recovery-analysis-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: <2003-5-27151510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27151510.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 May 2003 19:57:44 +0000 Message-ID: <012401c3248a$13393970$681810ac@movaz.com> From: "Adrian Farrel" To: "'Kireeti Kompella'" , "Ron Bonica" , Cc: , , "Adrian Farrel" Subject: Route Exclusion Date: Tue, 27 May 2003 15:56:33 -0400 Kireeti, Ron, You may recall that at SF there was a surprisingly large number of people (30+) who had read this draft and expressed an interest. (In today's climate, it seems unusual if all of the authors have read a draft!) We (the authors) are also seeing a fair bit of interest expressed to us from people who need the function and want to go ahead and start implementing - they want to know what the future of the draft is. At the same time, the ASON work seems to be pulling in this requirement, and I shouldn't be surprised if multi-area/multi-domain/multi-AS decides it is a requirement, too. So the question for you is, what do we do with this draft? There appear to be three possibilies: 1. The draft becomes a WG draft in the near future, and continues to develop with input from the WG. 2. The authors continue to spend their efforts on the draft with no particular IETF target in sight and without the GMPLS community having any realistic expectation of the draft going anywhere. Other standards bodies, needing the function, develop their own alternatives and so on... 3. The authors bring the draft forward as an individual submission to the IESG. Well, you can guess which I think is the best idea. What do you think? Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 May 2003 13:24:11 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Vendor attributes in TE LSAs Date: Tue, 27 May 2003 09:19:28 -0400 Message-ID: <83040F98B407E6428FEC18AC720F5D73200F09@exchange.tropicnetworks.com> Thread-Topic: Vendor attributes in TE LSAs Thread-Index: AcMkUpoR9ApzCbnqScOXd84yz5YGfA== From: "Udo Neustadter" To: Cc: Hi all, I am working on a GMPLS implementation, and part of my problem is the addition of company specific data to the TE LSAs. The Internet-Draft http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt proposes an interoperable way to solve the following two issues: 1. Companies that already applied with IANA for an SMI Network management enterprise code do not need to re-apply for sub-TLV values from the pool of numbers reserved for private use 2. Allows private attributes/data to be embedded in the TE router LSA (the one TE LSA that contains the router address TLV). I would like for the draft to be considered part of this working group. This work is an extension to the work done in http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio ns-09.txt.=20 Thanks in advance for your support. Udo Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:05:24 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:04:17 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:03:10 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:02:38 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:02:06 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:01:32 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:00:52 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 19:00:19 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:59:44 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:59:12 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:58:38 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:58:05 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:57:04 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:52:54 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:42:33 +0000 Message-Id: <200305221831.OAA23845@ietf.org> Date: Thu, 22 May 2003 14:31:41 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 18:34:04 +0000 Message-Id: <200305221831.OAA23845@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ccamp@ops.ietf.org From: The IESG Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard, Version 07 Date: Thu, 22 May 2003 14:31:41 -0400 The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:10:56 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:10:22 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:08:16 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:07:34 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:06:49 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:06:16 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 17:05:44 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:46:38 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:44:58 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: braja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ietf-announce@ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:42:45 +0000 Message-Id: <200305221616.MAA19813@ietf.org> Date: Thu, 22 May 2003 12:16:51 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:42:14 +0000 Message-Id: <200305221616.MAA19813@ietf.org> Date: Thu, 22 May 2003 12:16:51 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:41:42 +0000 Message-Id: <200305221616.MAA19813@ietf.org> Date: Thu, 22 May 2003 12:16:51 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:41:09 +0000 Message-Id: <200305221616.MAA19813@ietf.org> Date: Thu, 22 May 2003 12:16:51 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:40:37 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:40:05 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:39:29 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:39:00 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:38:26 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:25:42 +0000 Message-Id: <200305221616.MAA19813@ietf.org> Date: Thu, 22 May 2003 12:16:51 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:23:35 +0000 Message-Id: <200305221607.MAA19494@ietf.org> Date: Thu, 22 May 2003 12:07:17 -0400 Cc: "RFC Editor" , "Internet Architecture Board" , ccamp@ops.ietf.org To: BRaja@tellium.com From: "The IESG" Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard [owner-ccamp@ops.ietf.org in Pass-Through List] The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:18:19 +0000 Message-Id: <200305221616.MAA19813@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ccamp@ops.ietf.org From: The IESG Subject: Document Action: Tracing Requirements for Generic Tunnels to Informational Date: Thu, 22 May 2003 12:16:51 -0400 The IESG has approved the Internet-Draft 'Tracing Requirements for Generic Tunnels' as a Informational. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 May 2003 16:10:58 +0000 Message-Id: <200305221607.MAA19494@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ccamp@ops.ietf.org From: The IESG Subject: Protocol Action: Generalized Multi-Protocol Label Switching Architecture to Proposed Standard Date: Thu, 22 May 2003 12:07:17 -0400 The IESG has approved the Internet-Draft 'Generalized Multi-Protocol Label Switching Architecture' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Alex Zinin. Technical Summary Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. Working Group Summary The CCAMP Working Group has consensus on this document to be published as a standards track document. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen and Alex Zinin. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 May 2003 13:39:28 +0000 From: "Jonathan Lang" To: "'Manoj Agiwal'" , "''Ccamp \(E-mail\)'" Subject: RE: Link Summary Message Date: Wed, 21 May 2003 06:36:49 -0700 Message-ID: <006b01c31f9e$086d4ae0$6501000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Manoj, > -----Original Message----- > From: Manoj Agiwal [mailto:manoj.agiwal@metro-optix.com] > Sent: Tuesday, May 20, 2003 8:56 PM > To: 'Ccamp (E-mail) > Cc: 'Jonathan.Lang@RinconNetworks.com' > Subject: FW: Link Summary Message > > > Hi , > LMP darft says > > "The linksummary MUST be send periodically transmitted until > (1) the node receives a LinkSummaryAck or LinkSummaryNack > message or (2) a retry limit has been reached and no > LinkSummaryAck or LinkSummaryNack message has been received" > > When a new Data Link is enabled for a TE link which is > already in UP state . Then how a Link Summary message is > initiated for a new DL added to a TE link ? Which event > should trigger the sending of Link Summary message in this scenario? You can trigger the LinkSummary message when the data link is enabled for the TE link. > > Do we sent Link Summary message periodically when TE is in UP state ? Sure. In section 4, it says "Link property correlation SHOULD be done before the link is brought up and MAY be done at any time a link is up and not in the Verification process." > > > When should Event evSummaryFail be generated to DL fsm . > > 1) When we receive Link Summary Nack message. > > or > > 2) When we negatively acknowlege Link Summary message > i.e. when we send Link Summary Nack . > > or > > In both the cases Both cases. Thanks, Jonathan > > Regards , > Manoj > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 May 2003 04:06:13 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213EE6@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "'Jonathan.Lang@RinconNetworks.com'" Subject: FW: Link Summary Message Date: Tue, 20 May 2003 22:56:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi , LMP darft says "The linksummary MUST be send periodically transmitted until (1) the node receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has been reached and no LinkSummaryAck or LinkSummaryNack message has been received" When a new Data Link is enabled for a TE link which is already in UP state . Then how a Link Summary message is initiated for a new DL added to a TE link ? Which event should trigger the sending of Link Summary message in this scenario? Do we sent Link Summary message periodically when TE is in UP state ? When should Event evSummaryFail be generated to DL fsm . 1) When we receive Link Summary Nack message. or 2) When we negatively acknowlege Link Summary message i.e. when we send Link Summary Nack . or In both the cases Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 May 2003 12:39:41 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C22F5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: draft-ietf-ccamp-gmpls-architecture-07.txt Date: Tue, 20 May 2003 14:37:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri posted a new rev, to address some more nits from IESG. If anyone wants to do a quick check, Here are ptrs to colored web pages showing the difference between rev 5 and 7 or the differences between rev 6 and rev 7. So depending on which one you reviewed you can see what has changed. http://psg.com/~bwijnen/gmplsarch.05-07.html http://psg.com/~bwijnen/gmplsarch.06-07.html I think all changes are fine and OK. IESG did approve rev 06, and so (assuming they are also OK with rev 07, which I expect to hear within a day or so) then it will go to RFC-Editor queue. Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 May 2003 11:32:06 +0000 Message-Id: <200305201125.HAA05999@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-07.txt Date: Tue, 20 May 2003 07:25:34 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching Architecture Author(s) : E. Mannie Filename : draft-ietf-ccamp-gmpls-architecture-07.txt Pages : 58 Date : 2003-5-19 Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.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-07.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-07.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: <2003-5-19141536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19141536.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 20:47:28 +0000 Date: Mon, 19 May 2003 13:46:25 -0700 (PDT) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org, "" , "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , "" Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Message-ID: <20030519134244.N832@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lyndon, On Mon, 19 May 2003, Ong, Lyndon wrote: > Maybe everyone is tired out :o) In any case, I think > a liaison response is certainly a good idea, and you > deserve some thanks for putting it together and attempting > to reach some consensus on the list. To give credit where it's due, there were many who helped; there were also many replies to the first version that helped shape this one. > Just wanted to clarify one point, though - the liaison says > that compared to G.7714.1 messages > > > "GMPLS identifiers are typically 32 bit numbers and as such are not > > printable characters." > > Maybe it's a fine point, but the messages in G.7714.1 are described > in bit-oriented format, not as characters; the Base64 encoding is > then applied to the message before it goes out on the trace, so that > what is sent on the wire is in the form of printable characters. > > That means that 32 bit numbers can still be carried in the message, > subject to the length limit. A decoding would be applied at the other > end to recover the original bit-oriented message. > (Folks who worked on 7714.1 can correct me if I'm wrong on this). Well, the liaison has already been sent. However, if necessary we can clarify this at the interim ITU SG14/15 meeting in a couple of weeks. Thanks for your comments, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 20:14:54 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500F7@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Cc: sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Mon, 19 May 2003 13:16:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, Maybe everyone is tired out :o) In any case, I think a liaison response is certainly a good idea, and you deserve some thanks for putting it together and attempting to reach some consensus on the list. Just wanted to clarify one point, though - the liaison says that compared to G.7714.1 messages > "GMPLS identifiers are typically 32 bit numbers and as such are not > printable characters." Maybe it's a fine point, but the messages in G.7714.1 are described in bit-oriented format, not as characters; the Base64 encoding is then applied to the message before it goes out on the trace, so that what is sent on the wire is in the form of printable characters. That means that 32 bit numbers can still be carried in the message, subject to the length limit. A decoding would be applied at the other end to recover the original bit-oriented message. (Folks who worked on 7714.1 can correct me if I'm wrong on this). Cheers, Lyndon -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Saturday, May 17, 2003 9:51 AM To: ccamp@ops.ietf.org Cc: sob@harvard.edu; Wijnen, Bert (Bert); Ron Bonica (E-mail); zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Hi All, On Sun, 11 May 2003, Kireeti Kompella wrote: > Please send your replies to the list (if you wish to reply privately, > include the Liaison Coordinator and the ADs in your reply). There was some support, no nay-sayers and no alternative text. I'm surprised at the somewhat tepid support, as when the subject of liaisons came up, there were heated opinions that CCAMP was not keeping its end up, and now that we have liaisons to send, there is limited (expressed) interest, either for or against. In any case, this is important, there is enough support, so I will send the liaison off as is. I encourage those who can to attend the interim meeting in Chicago. It's coming up soon, June 9-13. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 19:20:25 +0000 Message-ID: Date: Mon, 19 May 2003 12:15:45 -0700 (PDT) From: vivek_1975 Reply-To: vivek_1975 To: "Ccamp-wg (E-mail)" Subject: Re: FW: draft-ietf-ccamp-lmp-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Hi i am not sure whether the question has been raised previously in this list. In the ccamp-lmp draft for all the messages, there is more emphasize on the transmission order. Can somebody answer why this STRICT requirement is enforced rather than the similar kind of mechanism followed in RSVP(Objects can come in any order). Regards Vivek > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 19, 2003, 6:15 AM > To: "Ccamp-wg (E-mail)" > Subject: FW: draft-ietf-ccamp-lmp-08.txt > > Here is the last IESG comment on this document. > I think that Thomas had indeed uncovered a serious issue. > With various other IANA controlled name spaces, we have > recently found that the IANA guidelines/rules for making > assignments were either not clear or allowed for > assignments to be made too easily. That then later resulted > in all sorts of let us say "un-friendly" discussions. We > betetr try to avoid those in the future and so we must be > very specific and very precise in the IANA guidelines for > new namespaces. > > Pls fix as part of your new revision. > > Thanks, > Bert > > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: maandag 19 mei 2003 14:47 > To: Bert Wijnen > Cc: iesg@ietf.org > Subject: draft-ietf-ccamp-lmp-08.txt > > > Discuss comments: > > > The LMP Message Type name space should be allocated as follows: > pursuant to the policies outlined in [RFC2434], the numbers in the > range 0-127 are allocated by Standards Action, 128-240 are allocated > through an Expert Review, and 241-255 are reserved for Private Use. > > It might be good to expand on expert review just a bit. Is the > intention that anyone can get one an allocation? Allocations only for > stuff that will clearly eventually be published as an RFC? What sort > of review is the expert expected to do? The more text one can give > here, the less confusion there will be later should people disagree > with the decision of the expert. > > The LMP Sub-object Class name space should be allocated as follows: > pursuant to the policies outlined in [RFC2434], the numbers in the > range of 0-127 are allocated by Standards Action, 128-247 are > allocated through an Expert Review, and 248-255 are reserved for > Private Use. > > seems wrong. the sub-object assignment policy should be determined by > the Class. I.e., when you create a class, you define what the policy > should be for sub-classes. For some sub-classes, FCFS might be fine, > for others maybe only standards action. One-size fits all doesn't seem > right. I'd suggest something like: > > The policy for allocating values out of the LMP Sub-object Class > name space is part of the defintion of the specific Class > instance. When a Class is defined, its definition must also include > a description of the policy underwhich sub-objects are allocated. > > note: that also means this needs to be done for all of the sub-objects > that are defined in this document. > > The LMP Object Class type name space should be allocated as follows: > pursuant to the policies outlined in [RFC2434], the numbers in the > range 0-111 are allocated by Standards Action, 112-119 are allocated > through an Expert Review, and 120-127 are reserved for Private Use. > > ditto > > > Thomas > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 13:52:30 +0000 Reply-To: From: "Vishal Sharma" To: "Dieter Beller" Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , Subject: RE: ASON reqts Date: Mon, 19 May 2003 09:51:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jerry, Deiter, Thanks very much for your emails, and for pointers to additional information. This is very helpful. -Vishal > -----Original Message----- > From: Dieter Beller [mailto:D.Beller@alcatel.de] > Sent: Monday, May 19, 2003 4:55 AM > To: v.sharma@ieee.org > Cc: Ash, Gerald R (Jerry), ALABS; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Vishal, > > Ash, Gerald R (Jerry), ALABS wrote: > > Vishal, > > > > > >>>>I believe the initial routing requirements are captured in ITU doc. > >>>>G.7715. However, I am not sure whether, unlike signaling, the ITU has > >>>>begun work on the protocol-specific instantiations of routing > >>>>requirements. > > > > > > > >>>The conclusion drawn from some initial discussions on specific > >>>routing protocols was to step back for a moment and develop a > >>>so-called mid-level requirements recommendation for a link state > >>>routing protocol which still should be protocol neutral. This > >>>requirements recommendation will then be used for the assessment > >>>of existing link state routing protocols to be applied in ASON. > > > > > >>Would you know where this work currently stands within the ITU? > >>Has this intermediate or mid-level document been created? > >>If so, how may one get access to it, and has it been liased > >>to the IETF? > > > > > > There is a Liaison from ITU-T to IETF that reports the status > of the ASON routing work at > http://www.ietf.org/IESG/LIAISON/ls15-39.htm. There is also a > pointer to G.7715 at the bottom of the Liaison: > > > > click the link at the bottom of the Liaison --> > > click "Common Control and Measurement Plane (ccamp) Working Group" --> > > click "I accept" at the bottom of this page --> > > click "ASON Routing Activities" --> > > click "download" on the G.7715 line --> > > brings up G.7715 > > > > please find some more information by checking these: > > http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00330.html > > http://ops.ietf.org/lists/ccamp/ccamp.2003/ppt00001.ppt > > > Dieter > > > > Thanks, > > Jerry > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 12:56:04 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C1F5F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-lmp-08.txt Date: Mon, 19 May 2003 14:53:53 +0200 MIME-Version: 1.0 Content-Type: text/plain Here is the last IESG comment on this document. I think that Thomas had indeed uncovered a serious issue. With various other IANA controlled name spaces, we have recently found that the IANA guidelines/rules for making assignments were either not clear or allowed for assignments to be made too easily. That then later resulted in all sorts of let us say "un-friendly" discussions. We betetr try to avoid those in the future and so we must be very specific and very precise in the IANA guidelines for new namespaces. Pls fix as part of your new revision. Thanks, Bert -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: maandag 19 mei 2003 14:47 To: Bert Wijnen Cc: iesg@ietf.org Subject: draft-ietf-ccamp-lmp-08.txt Discuss comments: The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use. It might be good to expand on expert review just a bit. Is the intention that anyone can get one an allocation? Allocations only for stuff that will clearly eventually be published as an RFC? What sort of review is the expert expected to do? The more text one can give here, the less confusion there will be later should people disagree with the decision of the expert. The LMP Sub-object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use. seems wrong. the sub-object assignment policy should be determined by the Class. I.e., when you create a class, you define what the policy should be for sub-classes. For some sub-classes, FCFS might be fine, for others maybe only standards action. One-size fits all doesn't seem right. I'd suggest something like: The policy for allocating values out of the LMP Sub-object Class name space is part of the defintion of the specific Class instance. When a Class is defined, its definition must also include a description of the policy underwhich sub-objects are allocated. note: that also means this needs to be done for all of the sub-objects that are defined in this document. The LMP Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. ditto Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 May 2003 08:58:22 +0000 Message-ID: <3EC89BEF.2050509@alcatel.de> Date: Mon, 19 May 2003 10:55:11 +0200 From: Dieter Beller Organization: Alcatel SEL AG, OND Stuttgart, Germany User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: v.sharma@ieee.org CC: "Ash, Gerald R (Jerry), ALABS" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vishal, Ash, Gerald R (Jerry), ALABS wrote: > Vishal, > > >>>>I believe the initial routing requirements are captured in ITU doc. >>>>G.7715. However, I am not sure whether, unlike signaling, the ITU has >>>>begun work on the protocol-specific instantiations of routing >>>>requirements. > > > >>>The conclusion drawn from some initial discussions on specific >>>routing protocols was to step back for a moment and develop a >>>so-called mid-level requirements recommendation for a link state >>>routing protocol which still should be protocol neutral. This >>>requirements recommendation will then be used for the assessment >>>of existing link state routing protocols to be applied in ASON. > > >>Would you know where this work currently stands within the ITU? >>Has this intermediate or mid-level document been created? >>If so, how may one get access to it, and has it been liased >>to the IETF? > > > There is a Liaison from ITU-T to IETF that reports the status of the ASON routing work at http://www.ietf.org/IESG/LIAISON/ls15-39.htm. There is also a pointer to G.7715 at the bottom of the Liaison: > > click the link at the bottom of the Liaison --> > click "Common Control and Measurement Plane (ccamp) Working Group" --> > click "I accept" at the bottom of this page --> > click "ASON Routing Activities" --> > click "download" on the G.7715 line --> > brings up G.7715 > please find some more information by checking these: http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00330.html http://ops.ietf.org/lists/ccamp/ccamp.2003/ppt00001.ppt Dieter > Thanks, > Jerry > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 May 2003 11:23:03 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213EDC@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Subject: evSummaryFail Date: Sun, 18 May 2003 06:15:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi , When should Event evSummaryFail be generated to DL fsm . 1) When we receive Link Summary Nack message. or 2) When we negatively acknowlege Link Summary message i.e. when we send Link Summary Nack . or In both the cases . Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 May 2003 11:10:21 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213ED9@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Subject: Link Summary Message Date: Sun, 18 May 2003 06:01:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi , LMP darft says "The linksummary MUST be send periodically transmitted until (1) the node receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has been reached and no LinkSummaryAck or LinkSummaryNack message has been received" When a new Data Link is enabled for a TE link which is already in UP state . Then how a Link Summary message is initiated for a new DL added to a TE link ? Which event should trigger the sending of Link Summary message in this scenario? Do we sent Link Summary message periodically when TE is in UP state ? Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 23:31:30 +0000 From: "zafar ali" To: , Cc: "'Anca Zamfir'" Subject: A new draft for Explicit Resource Control over GMPLS Link Bundles is available for your comments Date: Sat, 17 May 2003 19:29:54 -0400 Message-ID: <003701c31ccc$396e6c70$91053918@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C31CAA.B25CCC70" This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C31CAA.B25CCC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Fellows, A new draft for Explicit Resource Control over GMPLS Link Bundles is available for your comments and suggestions. Please find the draft at the IETF Web site, http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-contr ol-bundle-01.txt Abstract Explicit label/ resource control using the Label ERO and Label RRO subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE links are bundled, identification of label resource is not enough for the purpose of explicit resource control. Specifically, when link bundling [GMPLS-BUNDLE] is used, resource identification requires mechanisms to specify the component link identifier, along the TE link identifier and Label. This draft defines the extensions to RSVP- TE [RFC2119, RFC3209] to specify component link identifiers for explicit resource control and recording over GMPLS link bundles. Revision History Version 00 was posted on March 4, 2003, but we just missed the cut-off time for the 56th IETF meeting in San Francisco. Since then we have made some minor changes. Your input will be much appreciated, as usual. Thanks Regards... Anca & Zafar ------=_NextPart_000_0038_01C31CAA.B25CCC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dear=20 Fellows,
 
A new=20 draft for Explicit Resource Control over GMPLS Link Bundles is available = for=20 your comments and suggestions. Please find the draft at the IETF Web = site,=20
 
http://www.ietf.org/internet-drafts/draft-zamfir= -explicit-resource-control-bundle-01.txt
 
Abstract
    =
  =20 Explicit label/ resource control using the Label ERO and Label RRO=20
   subobjects is defined in [RFC 3471] and [RFC 3473]. = However,=20 when TE
   links are bundled, identification of label = resource is=20 not enough for
   the purpose of explicit resource = control.=20 Specifically, when link
   bundling [GMPLS-BUNDLE] is = used,=20 resource identification requires
   mechanisms to specify = the=20 component link identifier, along the TE
   link identifier = and=20 Label. This draft defines the extensions to RSVP-
   TE = [RFC2119,=20 RFC3209] to specify component link identifiers for
   = explicit=20 resource control and recording over GMPLS link bundles. =
 
Revision History
 
Version 00 was posted on March 4, 2003, but = we=20 just missed the cut-off time for the 56th IETF meeting in = San=20 Francisco. Since then we have made some minor changes.=20
 
Your input will be much appreciated, as usual.

Thanks
 
Regards...=20 Anca & Zafar=20
------=_NextPart_000_0038_01C31CAA.B25CCC70-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 17:31:46 +0000 Date: Sat, 17 May 2003 10:31:10 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , "" Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Message-ID: <20030517101854.U95522@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > In any case, this is important, there is enough support, so I will > send the liaison off as is. Done. We need a couple of follow-up items: | Based on information contained in the ITU and T1X1 liaison, as well as | subsequent e-mail exchanges on the CCAMP mailing list, and in order to | ensure proper interoperability in legacy SDH/SONET networks as well as | networks in which G.7714.1 is deployed, it will be recommended by the | editors to the CCAMP community to support only the Jx trace correlation | procedure and not the in-band Jx procedure. Pending agreement, the | draft will be updated. There was reasonable consensus (and no opposition) to this change. | We agree that terminology differences between IETF and ITU-T wrt | GMPLS have been confusing. There is an ongoing effort within | CCAMP to work together with T1X1/ITU-T on bridging the terminology | gaps. For example, there is a new Internet draft | (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in | CCAMP to do this mapping for LMP. When the current hubbub over the ASON requirements document dies down, I will check for WG consensus to move this forward. | > 5. Clarification of the usage of transport and control | > names for transport resources in the subject draft, as | > described in G.8080 Amendment | | The trace correlation transport mechanism supports a separation of | the transport and control plane identifiers. Would it be useful to call this out explicitly in the document? | > 6. Consideration of the ANSI 64-byte J1. | | This was mistakenly deleted from the latest version of the draft. | This will be included in the next version. Editors of the lmp-sonet-sdh doc, please update it with the change to the in-band Jx procedure, the above clarification (if needed), and the 64-byte J1, and resubmit it. Thanks! Thanks, All, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 16:54:54 +0000 Date: Sat, 17 May 2003 09:51:16 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , "" Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Message-ID: <20030517093623.B95522@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Sun, 11 May 2003, Kireeti Kompella wrote: > Please send your replies to the list (if you wish to reply privately, > include the Liaison Coordinator and the ADs in your reply). There was some support, no nay-sayers and no alternative text. I'm surprised at the somewhat tepid support, as when the subject of liaisons came up, there were heated opinions that CCAMP was not keeping its end up, and now that we have liaisons to send, there is limited (expressed) interest, either for or against. In any case, this is important, there is enough support, so I will send the liaison off as is. I encourage those who can to attend the interim meeting in Chicago. It's coming up soon, June 9-13. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 10:18:03 +0000 Message-ID: <3EC60D5C.3080608@alcatel.be> Date: Sat, 17 May 2003 12:22:20 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Stephen Shew Cc: "'Stephen Trowbridge'" , John Drake , "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed stephen, well for me it is entirely clear, we are at a turning point of the whole story, either gmpls extensions are backward/forward compatible, or you will end-up in a way or another with two protocol sets, the issue is "who gains something in maintaining the current confusing situation ?" ... the response is clear ... neither the ietf nor the itu (and unfortunately as a consequence, both the developer and the user community) in the note sent by fred baker (early'01), see http://www.ietf.org/IESG/STATEMENTS/sub_area.txt it was overwhelmingly clear that the following is the motto: "For example, optical networking is clearly a next generation requirement for service providers and for fiber consortia. However, the obvious next hop router in a general network may differ from the obvious next hop router in an optical network. Therefore, the use of optical networking may change the results that we need to get from routing protocols. It would be better for us to determine how the routing protocols should model those networks than for another body to arbitrarily change them or substitute others." and the exactly same applies for signalling, if this is still not clear, i'll explain it as follows, as you want a well- designed control plane architecture for optical networks, i want that the corresponding protocol extensions (routing, signalling, etc.) to be also well-designed and consistent with the internet protocols, this is my take as an ietf'er. stepping now in the protocol motivation behind this thread using the stephen t. detector i would call it a 3.5 motivation: > Those who think that RFC 3474/G.7713.2 (ITU-T extensions) don't > meet fully the ASON requirements and are not GMPLS compliant, so > this draft is a first step not only to fix RFC 3474/G.7713.2 > but also to make them GMPLS compliant taking one of the main discussion points in the above i-d, in my view, we should even look at it as follows, what are the possible methods to achieve call/connection separation well we have the following possibilities: "rfc3474, extend the notify message, define a new message" then detail pros and cons and decide upon wg consensus, which method is the more appropriate from a technical perspective. hope this clarifies. thanks, - dimitri. Stephen Shew wrote: > I have read the requirements draft (and most of this thread) and tend to > agree with Stephen T. that the problem is not entirely clear. However, > for the purpose of dialogue between standards bodies, having a CCAMP WG > document to liaise is helpful. In that regard I fine with it > progressing to a CCAMP WG document. > > One major technical comment I have is that the ASON addressing > requirements aren't fully represented. For example, "G.8080 defines a > UNI Transport Resource Addresses for the bearer links at the UNI > reference point" (from G.7713.2 and G.7713.3). This is important for > ASON services. Also, reference points and call segments are missing. I > would hope these can be discussed between CCAMP and SG15. Hence a > liaison would be helpful. > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Wednesday, May 14, 2003 11:59 > To: John Drake > Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > John, > I still think it is better to argue it out now and reach agreement on > what problem we are trying to solve. > > If we accept this as a WG draft without doing this, we seem to be > accepting that we do have SOME problem to solve, and then arguing later > on what it was. Regards, Steve > > John Drake wrote: > > > > Regardless of what we do now, I'm sure there will be lots of arguments > > later. > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 02:44:41 +0000 Message-Id: <4.3.2.7.2.20030516223017.041bcb30@pilgrim.cisco.com> Date: Fri, 16 May 2003 22:43:39 -0400 To: "Jonathan Lang" From: "Bradford, Richard" Subject: RE: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt Cc: "'Bradford, Richard'" , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_123386330==_.ALT" --=====================_123386330==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jonathan, Clarifications inline. Thanks for the feedback, Rich At 01:30 PM 5/16/2003 -0700, Jonathan Lang wrote: >Richard, > I read the draft and I like it. More comments inline. > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Bradford, Richard > > Sent: Friday, May 16, 2003 7:35 AM > > To: ccamp@ops.ietf.org > > Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt > > > > > > I'd like to get feedback from the list on the this draft. In > > addition to any problems with the draft itself: > > a) Does it solve the problem of Link Verification for OXCs? >I think "the problem" can be solved with existing mechanisms, but I like >your proposal. > > > b) If this isn't used, then how will Link Verification be > > performed for pure OXCs? Addition of Link Termination modules > > such as OC-48 and 10GigE? Build test circuits through the switches? >One way to do it is switch the port to an internal "test" port. Is this >what you mean by "build test circuits"? There were two other ways that I was thinking of. The first was switching to an internal test port, which it seems would have to be terminated in a compatible way with the neighbor (e,g, OC-48 or 10GigE). Another way to verify links, but not discover them, would be to build test circuits between the termination capable devices surrounding a network of pure optical switches. This wouldn't be something LMP could do, being a purely local protocol. > > c) Will carriers deploy (i.e. not just lab trials) OXCs > > without Link Verification capabilities? >I highly doubt it, but I'll let them add their input. > >Thanks, >Jonathan --=====================_123386330==_.ALT Content-Type: text/html; charset="us-ascii" Jonathan,
  Clarifications inline.
  Thanks for the feedback,
  Rich

At 01:30 PM 5/16/2003 -0700, Jonathan Lang wrote:
Richard,
  I read the draft and I like it.  More comments inline.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Bradford, Richard
> Sent: Friday, May 16, 2003 7:35 AM
> To: ccamp@ops.ietf.org
> Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt
>
>
> I'd like to get feedback from the list on the this draft. In
> addition to any problems with the draft itself:
> a) Does it solve the problem of Link Verification for OXCs?
I think "the problem" can be solved with existing mechanisms, but I like
your proposal.

> b) If this isn't used, then how will Link Verification be
> performed for pure OXCs? Addition of Link Termination modules
> such as OC-48 and 10GigE? Build test circuits through the switches?
One way to do it is switch the port to an internal "test" port.  Is this
what you mean by "build test circuits"?
There were two other ways that I was thinking of. The first was switching to an internal test port, which it seems would have to be terminated in a compatible way with the neighbor (e,g, OC-48 or 10GigE).
Another way to verify links, but not discover them, would be to build test circuits between the termination capable devices surrounding a network of pure optical switches. This wouldn't be something LMP could do, being a purely local protocol.


> c) Will carriers deploy (i.e. not just lab trials) OXCs
> without Link Verification capabilities?
I highly doubt it, but I'll let them add their input.

Thanks,
Jonathan

--=====================_123386330==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 May 2003 01:29:07 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213ED6@MAILHOSTNB> From: Manoj Agiwal To: "'Baktha Muralidharan'" , Manoj Agiwal Cc: "'Ccamp (E-mail)" , "'Jonathan.Lang@RinconNetworks.com'" Subject: RE: FW: LMP Message ID Date: Fri, 16 May 2003 04:07:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Bakhta , Neighbour is only interested in knowing if the message is out-of-order or not. If retransmission algorithm sends the message with the same Message Id , Neighbor will not consider it as out-of-order and process it. Out of order condition being (int)oldmsgid - (int)newmsgid > 0 In case a new message is received with a greater Message id and latter Neighbor receives the re-transmitted message , re-transmitted message should be discarded as it is out-of-order. New message identifies change in configuration and should be send with a higher message id and should be accepted by neighbor while re-trnasmitted message represents old values and should be discarded. I feel if retransmitted message is sent with the same message Id or new message id , it does not matter , since in either case neighboring node will process it completely. Only disadvantage is one will eat away Message Id space at faster rate if new message id is generated for every re-transmitted message. Regards , Manoj -----Original Message----- From: Baktha Muralidharan [mailto:muralidb@cisco.com] Sent: Wednesday, May 14, 2003 8:33 PM To: Manoj Agiwal Cc: 'Ccamp (E-mail); 'Jonathan.Lang@RinconNetworks.com' Subject: Re: FW: LMP Message ID At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote: >Hi , > Lmp drafts tells that Message ID should be monotonically increasing > > Section 7 also tells that "Unacknowledge messages sent with Message_id >object should be retransmitted until the message is > acknowledged or until retry limit is reached." > > Do we have to sent all retransmitted messages with the same Message Id >as sent previously or it should be in monotonically > increasing order. > >Regards , >Manoj Hi Manoj, An unacknowledged message could have been lost; i.e. might not have reached the neighbor. So, the neighbor has no way of determining if a message is a re-transmit and will fail [and nack] a message with out-of-order message-id. So, re-transmit attempts should increase message id. /Baktha Muralidharan Cisco Systems. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 22:37:39 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Fri, 16 May 2003 17:36:24 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A67BD@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMb67vWXy5XdcehQBqD0qPORdzMXAACyhBA From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" , "Dieter Beller" , "Kireeti Kompella" , Vishal, >>> I believe the initial routing requirements are captured in ITU doc. >>> G.7715. However, I am not sure whether, unlike signaling, the ITU = has >>> begun work on the protocol-specific instantiations of routing >>> requirements. =20 >> The conclusion drawn from some initial discussions on specific >> routing protocols was to step back for a moment and develop a >> so-called mid-level requirements recommendation for a link state >> routing protocol which still should be protocol neutral. This >> requirements recommendation will then be used for the assessment >> of existing link state routing protocols to be applied in ASON. > Would you know where this work currently stands within the ITU? > Has this intermediate or mid-level document been created? > If so, how may one get access to it, and has it been liased > to the IETF? There is a Liaison from ITU-T to IETF that reports the status of the = ASON routing work at http://www.ietf.org/IESG/LIAISON/ls15-39.htm. = There is also a pointer to G.7715 at the bottom of the Liaison: click the link at the bottom of the Liaison -->=20 click "Common Control and Measurement Plane (ccamp) Working Group" --> click "I accept" at the bottom of this page --> click "ASON Routing Activities" --> click "download" on the G.7715 line --> brings up G.7715 Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 20:48:15 +0000 From: "Srini Datari" To: "Kireeti Kompella" , Subject: RE: Proposed change to LMP Link Verification draft Date: Fri, 16 May 2003 16:47:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree with above change -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Kireeti Kompella Sent: Monday, May 12, 2003 2:28 AM To: ccamp@ops.ietf.org Subject: Proposed change to LMP Link Verification draft Hi All, | Based on information contained in the ITU and T1X1 liaison, as well as | subsequent e-mail exchanges on the CCAMP mailing list, and in order to | ensure proper interoperability in legacy SDH/SONET networks as well as | networks in which G.7714.1 is deployed, it will be recommended by the | editors to the CCAMP community to support only the Jx trace correlation | procedure and not the in-band Jx procedure. Please respond with one of the following: - Agree with above change; OR - Don't agree with above change [i.e., keep in-band Jx procedure as is]. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 20:42:54 +0000 Reply-To: From: "Vishal Sharma" To: "Dieter Beller" , "Ash, Gerald R \(Jerry\), ALABS" Cc: "Kireeti Kompella" , Subject: RE: ASON reqts Date: Fri, 16 May 2003 16:41:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Deiter, Jerry Thanks for your inputs. > -----Original Message----- > From: Dieter Beller [mailto:D.Beller@alcatel.de] > Sent: Friday, May 16, 2003 7:57 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: v.sharma@ieee.org; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > > > > >>I believe the initial routing requirements are captured in ITU doc. > >>G.7715. However, I am not sure whether, unlike signaling, the ITU has > >>begun work on the protocol-specific instantiations of routing > >>requirements. > > > > The conclusion drawn from some initial discussions on specific > routing protocols was to step back for a moment and develop a > so-called mid-level requirements recommendation for a link state > routing protocol which still should be protocol neutral. This > requirements recommendation will then be used for the assessment > of existing link state routing protocols to be applied in ASON. Would you know where this work currently stands within the ITU? Has this intermediate or mid-level document been created? If so, how may one get access to it, and has it been liased to the IETF? -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 20:33:47 +0000 From: "Jonathan Lang" To: Cc: , Subject: FW: FW: LMP Message ID Date: Fri, 16 May 2003 13:33:27 -0700 Message-ID: <002701c31bea$68776c20$6801000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry, I meant to cc ccamp on this. -Jonathan > -----Original Message----- > From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > Sent: Thursday, May 15, 2003 1:02 PM > To: 'Baktha Muralidharan' > Subject: RE: FW: LMP Message ID > > > Baktha, > Retransmitted messages should have the same Message Id as > the originally transmitted message. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Baktha Muralidharan [mailto:muralidb@cisco.com] > > Sent: Wednesday, May 14, 2003 8:03 AM > > To: Manoj Agiwal > > Cc: 'Ccamp (E-mail); 'Jonathan.Lang@RinconNetworks.com' > > Subject: Re: FW: LMP Message ID > > > > > > At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote: > > >Hi , > > > Lmp drafts tells that Message ID should be monotonically > > >increasing . > > > > > > Section 7 also tells that "Unacknowledge messages sent with > > >Message_id object should be retransmitted until the message is > > > acknowledged or until retry limit is reached." > > > > > > Do we have to sent all retransmitted messages with the same > > >Message Id as sent previously or it should be in monotonically > > > increasing order. > > > > > >Regards , > > >Manoj > > > > Hi Manoj, > > > > An unacknowledged message could have been lost; i.e. might > > not have reached the neighbor. So, the neighbor has no way of > > determining if a message is a re-transmit and will fail [and > > nack] a message with out-of-order message-id. > > > > So, re-transmit attempts should increase message id. > > > > /Baktha Muralidharan > > Cisco Systems. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 20:32:24 +0000 From: "Jonathan Lang" To: "'Bradford, Richard'" Cc: Subject: RE: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt Date: Fri, 16 May 2003 13:30:53 -0700 Message-ID: <002601c31bea$0caa4b10$6801000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, I read the draft and I like it. More comments inline. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Bradford, Richard > Sent: Friday, May 16, 2003 7:35 AM > To: ccamp@ops.ietf.org > Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt=20 >=20 >=20 > I'd like to get feedback from the list on the this draft. In=20 > addition to any problems with the draft itself: > a) Does it solve the problem of Link Verification for OXCs? I think "the problem" can be solved with existing mechanisms, but I like your proposal. > b) If this isn't used, then how will Link Verification be=20 > performed for pure OXCs? Addition of Link Termination modules=20 > such as OC-48 and 10GigE? Build test circuits through the switches? One way to do it is switch the port to an internal "test" port. Is this what you mean by "build test circuits"? > c) Will carriers deploy (i.e. not just lab trials) OXCs=20 > without Link Verification capabilities? I highly doubt it, but I'll let them add their input. Thanks, Jonathan >=20 >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Link Management Protocol Extensions for Link > discovery > Using Loss of Light > Author(s) : R. Bradford, D. Papadimitriou, D. Tappan > Filename : draft-rbradfor-ccamp-lmp-lol-01.txt > Pages : 13 > Date : 2003-4-11 > =20 > This document proposes an enhanced mechanism for Link=20 > Management Protocol=C6s Link Verification procedure that is=20 > independent of the data encoding type. It can be used for any=20 > point-to-point link, including both Optical Links and=20 > SONET/SDH Links. The general proposal is to use the=20 > transmission of light by the sender and recognition of the=20 > presence or absence of light by the receiver to identify port=20 > mapping. The proposal includes minor extensions to the=20 > existing messages to implement this extension to the link=20 > verification procedure. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-l ol-01.txt To remove yourself from the IETF Announcement list, send a message to=20 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-rbradfor-ccamp-lmp-lol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-rbradfor-ccamp-lmp-lol-01.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 15:59:50 +0000 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343E07@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: "'Stephen Trowbridge'" , John Drake Cc: "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Fri, 16 May 2003 11:59:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BC4.19E6EC50" 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_01C31BC4.19E6EC50 Content-Type: text/plain I have read the requirements draft (and most of this thread) and tend to agree with Stephen T. that the problem is not entirely clear. However, for the purpose of dialogue between standards bodies, having a CCAMP WG document to liaise is helpful. In that regard I fine with it progressing to a CCAMP WG document. One major technical comment I have is that the ASON addressing requirements aren't fully represented. For example, "G.8080 defines a UNI Transport Resource Addresses for the bearer links at the UNI reference point" (from G.7713.2 and G.7713.3). This is important for ASON services. Also, reference points and call segments are missing. I would hope these can be discussed between CCAMP and SG15. Hence a liaison would be helpful. -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Wednesday, May 14, 2003 11:59 To: John Drake Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); ccamp@ops.ietf.org Subject: Re: ASON reqts John, I still think it is better to argue it out now and reach agreement on what problem we are trying to solve. If we accept this as a WG draft without doing this, we seem to be accepting that we do have SOME problem to solve, and then arguing later on what it was. Regards, Steve John Drake wrote: > > Regardless of what we do now, I'm sure there will be lots of arguments > later. > ------_=_NextPart_001_01C31BC4.19E6EC50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ASON reqts

I have read the requirements draft (and most of this = thread) and tend to agree with Stephen T. that the problem is not = entirely clear.  However, for the purpose of dialogue between = standards bodies, having a CCAMP WG document to liaise is = helpful.  In that regard I fine with it progressing to a CCAMP WG = document.

One major technical comment I have is that the ASON = addressing requirements aren't fully represented.  For example, = "G.8080 defines a UNI Transport Resource Addresses for the bearer = links at the UNI reference point" (from G.7713.2 and = G.7713.3).  This is important for ASON services.  Also, = reference points and call segments are missing.  I would hope = these can be discussed between CCAMP and SG15.  Hence a liaison = would be helpful.

-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Wednesday, May 14, 2003 11:59
To: John Drake
Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert = (Bert); ccamp@ops.ietf.org
Subject: Re: ASON reqts


John,
I still think it is better to argue it out now and = reach agreement on what problem we are trying to solve.

If we accept this as a WG draft without doing this, = we seem to be accepting that we do have SOME problem to solve, and then = arguing later on what it was. Regards, Steve

John Drake wrote:
>
> Regardless of what we do now, I'm sure there = will be lots of arguments
> later.
>
<snip>

------_=_NextPart_001_01C31BC4.19E6EC50-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 15:53:03 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500E2@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Stephen Shew' , "'Ash, Gerald R (Jerry), ALABS'" , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Fri, 16 May 2003 08:54:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BC3.6C549100" 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_01C31BC3.6C549100 Content-Type: text/plain; charset="iso-8859-1" Hi Folks, Slightly off the topic, but for routing, I think one impact of the control and bearer plane separation is that the identification of the link (in the transport plane) is really separate from the identification of the routing controller advertising the link (in the control plane). You could also implement the routing controller as a physically separate system from the transport node, as opposed to being combined as in an LSR. Cheers, Lyndon -----Original Message----- From: Stephen Shew [mailto:sdshew@nortelnetworks.com] Sent: Friday, May 16, 2003 8:08 AM To: 'Ash, Gerald R (Jerry), ALABS'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes. In G.7713.x we have the following text: "Addressing of transport resources in the protocol is done by SNPP identifiers. A pair of these would identify an SNPP link. SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these. For example, neither routing controller nor connection manager identifiers are used for bearer link names." This affects things that describe the context of a GMPLS label. For example, the hop objects in an explicit route. They need to make sense to the transport plane in the absence of signalling. -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [ mailto:gash@att.com ] Sent: Thursday, May 15, 2003 18:52 To: Jonathan Sadler Cc: Ash, Gerald R (Jerry), ALABS; ccamp@ops.ietf.org Subject: RE: ASON reqts Jonathan, I've looked back over your posts, and have a few comments. We agree with you that at this stage we should 'focus on the requirements, not the solution'. Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements: 1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains. 4. Use of transport plane names instead of DCN addresses when referring to transport plane resources. #2 is clear, and we agree to add '0-connection calls' to the requirements I-D. #1, 3, and 4 aren't very specific/clear, and we'd like some clarification: #1 What does 'required behavior' mean here? #3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue? ------_=_NextPart_001_01C31BC3.6C549100 Content-Type: text/html; charset="iso-8859-1" RE: ASON reqts
Hi Folks,
 
Slightly off the topic, but for routing, I think one impact of the control and bearer
plane separation is that the identification of the link (in the transport plane)
is really separate from the identification of the routing controller advertising
the link (in the control plane).  You could also implement the routing controller
as a physically separate system from the transport node, as opposed to being
combined as in an LSR.
 
Cheers,
 
Lyndon
-----Original Message-----
From: Stephen Shew [mailto:sdshew@nortelnetworks.com]
Sent: Friday, May 16, 2003 8:08 AM
To: 'Ash, Gerald R (Jerry), ALABS'; Jonathan Sadler
Cc: ccamp@ops.ietf.org
Subject: RE: ASON reqts

On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes.  In G.7713.x we have the following text:

"Addressing of transport resources in the protocol is done by SNPP identifiers.  A pair of these would identify an SNPP link.  SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these.  For example, neither routing controller nor connection manager identifiers are used for bearer link names."

This affects things that describe the context of a GMPLS label.  For example, the hop objects in an explicit route.  They need to make sense to the transport plane in the absence of signalling.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Thursday, May 15, 2003 18:52
To: Jonathan Sadler
Cc: Ash, Gerald R (Jerry), ALABS; ccamp@ops.ietf.org
Subject: RE: ASON reqts


Jonathan,

I've looked back over your posts, and have a few comments.

We agree with you that at this stage we should 'focus on the requirements, not the solution'.  Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements:

1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains.

4. Use of transport plane names instead of DCN addresses when referring to transport plane resources.

#2 is clear, and we agree to add '0-connection calls' to the requirements I-D.  #1, 3, and 4 aren't very specific/clear, and we'd like some clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue?

------_=_NextPart_001_01C31BC3.6C549100-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 15:10:00 +0000 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343E06@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: "'Ash, Gerald R (Jerry), ALABS'" , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Fri, 16 May 2003 11:08:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BBC.FC7C8E2E" 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_01C31BBC.FC7C8E2E Content-Type: text/plain On #4, use of transport plane names is an important part of ASON architecture which separates control from bearer planes. In G.7713.x we have the following text: "Addressing of transport resources in the protocol is done by SNPP identifiers. A pair of these would identify an SNPP link. SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these. For example, neither routing controller nor connection manager identifiers are used for bearer link names." This affects things that describe the context of a GMPLS label. For example, the hop objects in an explicit route. They need to make sense to the transport plane in the absence of signalling. -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: Thursday, May 15, 2003 18:52 To: Jonathan Sadler Cc: Ash, Gerald R (Jerry), ALABS; ccamp@ops.ietf.org Subject: RE: ASON reqts Jonathan, I've looked back over your posts, and have a few comments. We agree with you that at this stage we should 'focus on the requirements, not the solution'. Regarding your suggestions on the requirements, so far I think you've suggested 4 additional requirements: 1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including 0-connection calls 3. Explicit support for connection partitioning in different administrative domains. 4. Use of transport plane names instead of DCN addresses when referring to transport plane resources. #2 is clear, and we agree to add '0-connection calls' to the requirements I-D. #1, 3, and 4 aren't very specific/clear, and we'd like some clarification: #1 What does 'required behavior' mean here? #3 Connection partitions are not across ADs, perhaps this issue relates to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, perhaps this is an implementation issue? ------_=_NextPart_001_01C31BBC.FC7C8E2E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ASON reqts

On #4, use of transport plane names is an important = part of ASON architecture which separates control from bearer = planes.  In G.7713.x we have the following text:

"Addressing of transport resources in the = protocol is done by SNPP identifiers.  A pair of these would = identify an SNPP link.  SNPP names are defined from transport name = spaces (see Section 10, G.8080) and it is important to note that = control plane names/addresses are not used for these.  For = example, neither routing controller nor connection manager identifiers = are used for bearer link names."

This affects things that describe the context of a = GMPLS label.  For example, the hop objects in an explicit = route.  They need to make sense to the transport plane in the = absence of signalling.

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
Sent: Thursday, May 15, 2003 18:52
To: Jonathan Sadler
Cc: Ash, Gerald R (Jerry), ALABS; = ccamp@ops.ietf.org
Subject: RE: ASON reqts


Jonathan,

I've looked back over your posts, and have a few = comments.

We agree with you that at this stage we should 'focus = on the requirements, not the solution'.  Regarding your = suggestions on the requirements, so far I think you've suggested 4 = additional requirements:

1. Discussion of required behavior at E-NNI and UNI = reference points. 2. Support for complete Call/Connection separation, = including 0-connection calls 3. Explicit support for connection = partitioning in different administrative domains.

4. Use of transport plane names instead of DCN = addresses when referring to transport plane resources.

#2 is clear, and we agree to add '0-connection calls' = to the requirements I-D.  #1, 3, and 4 aren't very specific/clear, = and we'd like some clarification:

#1 What does 'required behavior' mean here?
#3 Connection partitions are not across ADs, perhaps = this issue relates to session split across ADs? #4 We're using = transport plane names, however GMPLS allows for both, perhaps this is = an implementation issue?

------_=_NextPart_001_01C31BBC.FC7C8E2E-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 14:42:56 +0000 From: "Hirokazu Ishimatsu" To: Subject: RE: ASON reqts Date: Fri, 16 May 2003 23:42:26 +0900 Message-ID: <000201c31bb9$5e9d4250$6a02a8c0@LavieG> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" List, I have read this document and it is ready to be a CCAMP WG doc because of 2 in Steve's email. Hiro Ishimatsu > I think I have detected the following motivations from > different posts in the thread: > > 1. Those who don't want this to be a WG document (we are done with > this version of the specifications, lets get some experience > with them before considering any further change or evolution). > > 2. Those who think this should be a WG document so that ASON > extensions > currently standardized in ITU-T will get standards track status in > IETF (no intent to change the protocol, but document the superset > in one place so that we don't get so many GMPLS implementations > that don't support the ASON extensions). > > 3. Those who think there is nothing wrong with the ITU-T extensions to > meet the ASON requirements, but believe that RFC 3474 > didn't translate > G.7713.2 properly and this draft is a first step to fixing > RFC 3474. > > 4. Those who think that even the ITU-T extensions don't meet the ASON > requirements, so IETF should now take it over and do it > better starting > with this draft. > > 5. Those who think that ITU-T didn't get the requirements right, so we > need to look at everything from scratch. > > Regards, > Steve Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 14:40:09 +0000 Message-Id: <4.3.2.7.2.20030516100634.04144f98@pilgrim.cisco.com> Date: Fri, 16 May 2003 10:34:47 -0400 To: ccamp@ops.ietf.org From: "Bradford, Richard" Subject: Re: I-D ACTION:draft-rbradfor-ccamp-lmp-lol-01.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_79901342==_.ALT" --=====================_79901342==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable I'd like to get feedback from the list on the this draft. In addition to=20 any problems with the draft itself: a) Does it solve the problem of Link Verification for OXCs? b) If this isn't used, then how will Link Verification be performed for=20 pure OXCs? Addition of Link Termination modules such as OC-48 and 10GigE?=20 Build test circuits through the switches? c) Will carriers deploy (i.e. not just lab trials) OXCs without Link=20 Verification capabilities? A New Internet-Draft is available from the on-line Internet-Drafts= directories. Title : Link Management Protocol Extensions for Link=20 discovery Using Loss of Light Author(s) : R. Bradford, D. Papadimitriou, D. Tappan Filename : draft-rbradfor-ccamp-lmp-lol-01.txt Pages : 13 Date : 2003-4-11 This document proposes an enhanced mechanism for Link Management Protocol=C6s Link Verification procedure that is independent of the data encoding type. It can be used for any point-to-point link, including both Optical Links and SONET/SDH Links. The general proposal is to use the transmission of light by the sender and recognition of the presence or absence of light by the receiver to identify port mapping. The proposal includes minor extensions to the existing messages to implement this extension to the link verification procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp-lmp-lol-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-rbradfor-ccamp-lmp-lol-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-rbradfor-ccamp-lmp-lol-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. --=====================_79901342==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd like to get feedback from the list on the this draft. In addition to any problems with the draft itself:
a) Does it solve the problem of Link Verification for OXCs?
b) If this isn't used, then how will Link Verification be performed for pure OXCs? Addition of Link Termination modules such as OC-48 and 10GigE? Build test circuits through the switches?
c) Will carriers deploy (i.e. not just lab trials) OXCs without Link Verification capabilities?





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


        Title&= nbsp;         &n= bsp;: Link Management Protocol Extensions for Link discovery
            &nbs= p;             Using Loss of Light
        Author(s)       : R. Bradford, D. Papadimitriou, D. Tappan
        Filename        : draft-rbradfor-ccamp-lmp-lol-01.txt
        Pages&= nbsp;         &n= bsp;: 13
        Date&n= bsp;         &nb= sp; : 2003-4-11
        
This document proposes an enhanced mechanism for Link Management
Protocol=C6s Link Verification procedure that is independent of the
data encoding type. It can be used for any point-to-point link,
including both Optical Links and SONET/SDH Links. The general
proposal is to use the transmission of light by the sender and
recognition of the presence or absence of light by the receiver
to identify port mapping.  The proposal includes minor extensions
to the existing messages to implement this extension to the link
verification procedure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rbradfor-ccamp= -lmp-lol-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-rbradfor-ccamp-lmp-lol-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-rbradfor-ccamp-lmp-lol-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
        "multipa= rt" 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.
<ftp://ftp.ietf.org/internet-drafts/draft-rbradfor-ccamp-= lmp-lol-01.txt>

--=====================_79901342==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 11:59:43 +0000 Message-ID: <3EC4D21D.1060800@alcatel.de> Date: Fri, 16 May 2003 13:57:17 +0200 From: Dieter Beller Organization: Alcatel SEL AG, OND Stuttgart, Germany User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" CC: v.sharma@ieee.org, Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jerry, Vishal, and all, Ash, Gerald R (Jerry), ALABS wrote: > Vishal, > Kireeti, > > > >>I believe the initial routing requirements are captured in ITU doc. >>G.7715. However, I am not sure whether, unlike signaling, the ITU has >>begun work on the protocol-specific instantiations of routing >>requirements. > The conclusion drawn from some initial discussions on specific routing protocols was to step back for a moment and develop a so-called mid-level requirements recommendation for a link state routing protocol which still should be protocol neutral. This requirements recommendation will then be used for the assessment of existing link state routing protocols to be applied in ASON. > > That is my understanding as well. The GMPLS-ASON routing requirements should be based on the ITU-T G.7715 requirements. > > Hopefully the IETF will progress GMPLS-ASON routing extensions to meet the requirements, so that hopefully the ITU will not need to undertake protocol-specific extensions of GMPLS routing. And hopefully this would then avoid another G.7713.2-like debacle. > > I believe that ASON routing work is the subject of an ITU-T experts' meeting of Question 14/15, to be held in Chicago 9-13 June 2003. The ITU-T has invited the IETF GMPLS routing experts to participate, as per Wesam's presentation documented in the IETF-56/CCAMP meeting minutes http://ietf.org/proceedings/03mar/minutes/ccamp.htm. > I fully share your view - the idea was indeed to invite IETF GMPLS routing experts in order to have a closer and much better cooperation on routing compared to what happened with signaling. Furthermore, I would like to add that I have read this document and it is ready to be a CCAMP WG doc (being aware that some issues need further discussion or clarification which shouldn't preclude that this document becomes a WG doc) Dieter Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 May 2003 09:16:46 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213ED6@MAILHOSTNB> From: Manoj Agiwal To: 'Baktha Muralidharan' , Manoj Agiwal Cc: "'Ccamp (E-mail)" , "'Jonathan.Lang@RinconNetworks.com'" Subject: RE: FW: LMP Message ID Date: Fri, 16 May 2003 04:07:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Bakhta , Neighbour is only interested in knowing if the message is out-of-order or not. If retransmission algorithm sends the message with the same Message Id , Neighbor will not consider it as out-of-order and process it. Out of order condition being (int)oldmsgid - (int)newmsgid > 0 In case a new message is received with a greater Message id and latter Neighbor receives the re-transmitted message , re-transmitted message should be discarded as it is out-of-order. New message identifies change in configuration and should be send with a higher message id and should be accepted by neighbor while re-trnasmitted message represents old values and should be discarded. I feel if retransmitted message is sent with the same message Id or new message id , it does not matter , since in either case neighboring node will process it completely. Only disadvantage is one will eat away Message Id space at faster rate if new message id is generated for every re-transmitted message. Regards , Manoj -----Original Message----- From: Baktha Muralidharan [mailto:muralidb@cisco.com] Sent: Wednesday, May 14, 2003 8:33 PM To: Manoj Agiwal Cc: 'Ccamp (E-mail); 'Jonathan.Lang@RinconNetworks.com' Subject: Re: FW: LMP Message ID At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote: >Hi , > Lmp drafts tells that Message ID should be monotonically increasing . > > Section 7 also tells that "Unacknowledge messages sent with Message_id >object should be retransmitted until the message is > acknowledged or until retry limit is reached." > > Do we have to sent all retransmitted messages with the same Message Id >as sent previously or it should be in monotonically > increasing order. > >Regards , >Manoj Hi Manoj, An unacknowledged message could have been lost; i.e. might not have reached the neighbor. So, the neighbor has no way of determining if a message is a re-transmit and will fail [and nack] a message with out-of-order message-id. So, re-transmit attempts should increase message id. /Baktha Muralidharan Cisco Systems. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 22:55:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Thu, 15 May 2003 17:52:28 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A711B@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMaZwfOyYIs0mpNQcqzlJAgGd+A0gAfm9JgAA0lABAABM1TAA== From: "Ash, Gerald R (Jerry), ALABS" To: "Jonathan Sadler" Cc: "Ash, Gerald R (Jerry), ALABS" , Jonathan, I've looked back over your posts, and have a few comments. We agree with you that at this stage we should 'focus on the = requirements, not the solution'. Regarding your suggestions on the = requirements, so far I think you've suggested 4 additional requirements: 1. Discussion of required behavior at E-NNI and UNI reference points. 2. Support for complete Call/Connection separation, including = 0-connection calls 3. Explicit support for connection partitioning in different = administrative domains.=20 4. Use of transport plane names instead of DCN addresses when referring = to transport plane resources. #2 is clear, and we agree to add '0-connection calls' to the = requirements I-D. #1, 3, and 4 aren't very specific/clear, and we'd = like some clarification: #1 What does 'required behavior' mean here? #3 Connection partitions are not across ADs, perhaps this issue relates = to session split across ADs? #4 We're using transport plane names, however GMPLS allows for both, = perhaps this is an implementation issue? We agree that if these are ASON requirements (regardless of whether = signaling changes are needed) we should list them in the I-D. If some are ASON = requirements that are not applicable to GMPLS we should list and say so. Regarding G.7713.1, you pointed out that 'the ATM Forum certainly did = add Information Elements in order to support ASON services.' We agree with this approach, and that's the model we're following here, = the IETF should deliver (by WG consensus) the agreed-on 'IEs' (objects) = to support the ASON requirements. Regarding the basis for the ASON requirements, you said that = 'draft-lin-ccamp-gmpls-ason-rsvpte-00.txt was originally contributed in = June 2002.' We'd like to point out that the GMPLS-ASON requirements I-D is based on = draft-lin-ccamp-gmpls-ason-rqts-00.txt, originally contributed in August = 2002. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 20:55:41 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Thu, 15 May 2003 15:52:54 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A7119@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMa+O1MTRpVLPGPRzSEh/myWHqy0gAJdntA From: "Ash, Gerald R (Jerry), ALABS" To: , "Kireeti Kompella" Cc: "Ash, Gerald R (Jerry), ALABS" , Vishal, Kireeti, > I should have clarified that I did not mean that the two pieces of > work (routing and signaling) should be so tightly coupled that one > cannot proceed independently of the other. What I did mean was that > it would be better to initiate the routing work as well, so that=20 > any impact that routing has on signaling is captured in the signaling > work early on. This will be useful, as it'll prevent problems later. Agreed. We should progress the GMPLS-ASON routing requirements in a = separate, parallel effort to the GMPLS-ASON signaling requirements. > I believe the initial routing requirements are captured in ITU doc. > G.7715. However, I am not sure whether, unlike signaling, the ITU has > begun work on the protocol-specific instantiations of routing=20 > requirements. That is my understanding as well. The GMPLS-ASON routing requirements = should be based on the ITU-T G.7715 requirements. =20 Hopefully the IETF will progress GMPLS-ASON routing extensions to meet = the requirements, so that hopefully the ITU will not need to undertake = protocol-specific extensions of GMPLS routing. And hopefully this would = then avoid another G.7713.2-like debacle. I believe that ASON routing work is the subject of an ITU-T experts' = meeting of Question 14/15, to be held in Chicago 9-13 June 2003. The = ITU-T has invited the IETF GMPLS routing experts to participate, as per = Wesam's presentation documented in the IETF-56/CCAMP meeting minutes = http://ietf.org/proceedings/03mar/minutes/ccamp.htm. Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 18:42:40 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500D7@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Brungard, Deborah A, ALABS'" , "Ong, Lyndon" , Stephen Trowbridge Cc: "Wijnen, Bert (Bert)" , Bart.Rousseau@alcatel.be, ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Thu, 15 May 2003 11:44:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Deborah, Regarding the requirements, it sounds to me as if the scope of ccamp efforts is somewhat different from the scope of the sg15 effort, so the result of discussion may be also different. I would hope that we can make an extra effort to avoid diverging. Cheers, Lyndon -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, May 14, 2003 1:33 PM To: Ong, Lyndon; Stephen Trowbridge Cc: Wijnen, Bert (Bert); Bart.Rousseau@alcatel.be; ccamp@ops.ietf.org Subject: RE: ASON reqts Thanks Lyndon for asking clarification- I was trying to say that ASON does not require supporting multiple address formats for a E-PC (Protocol Controller) e.g. G7713.1. Similar to NSAP support of IP, IPv6 supports NSAP. Can you clarify your take on the requirements discussion? If I read the email, the discussion was related to the definition of a control domain and support of a non-RSVP domain or legacy (management system). The answer for supporting a non-RSVP domain was the need for an interworking function (which was considered out of scope). This is analogous to ITU's work, both for G7713.1 (PNNI) and G7713.2, the interworking functions are considered out of scope. And support of legacy is via SPC (same as G7713.1) and it is included. Were any other requirements identified as missing? Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 17:47:27 +0000 Message-ID: <3EC3C08D.6060809@tellabs.com> Date: Thu, 15 May 2003 11:30:05 -0500 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Kireeti, G.8080 (ASON Architecture) addresses both signaling and routing, and thereafter the two areas are addressed in separate documents. I agree that it is good to keep these separate from a protocol perspective. I suppose it is OK to write separate requirements documents for each area as long as requirements are not missed in the process. This would still mean that routing or high-level architectural issues that impact signaling should be considered in determining the signaling requirements. Considering the discussion on the list, I tend to agree with the idea that the ASON requirements have already been documented in G.7713 and G.7715 and creating additional documents that overlap these will likely only add additional confusion. Therefore I'm not convinced that this should be a WG doc, even as signaling only. Regards, Ben Kireeti Kompella wrote: > Hi Ben, > > On Wed, 14 May 2003, Ben Mack-Crane wrote: > > >>CCAMPers, >> >>Having reviewed the proposed requirements draft, and some of the ensuing >>e-mail discussion, I would say that >> >>"I have read this document, and it isn't ready to be a CCAMP doc" > > > Thanks for your input (thanks too to all others who've voiced their > opinion). > > >>I am principally concerned that routing requirements are not included. >>While draft's title is encompassing "GMPLS Usage and Extensions for >>ASON," the abstract limits this to signaling only. > > > You're right -- this document doesn't address routing (and doesn't > profess to). In keeping with other GMPLS work, I think it makes sense > to have separate signaling and routing documents, be they functional > specs, protocol details or requirements. This view appears to be > shared by the ITU-T as well, from what I understand. > > In the light of this, I have a question for you: > - In your opinion, should the document under consideration become a > CCAMP WG _just for signaling_? I.e., if we had a companion doc > that described the routing requirements for ASON, would that meet > your objection? > > Thanks, > Kireeti. > ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 16:47:51 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C1A10@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: IESG approved: draft-ietf-ccamp-tracereq-02.txt for Informational Date: Thu, 15 May 2003 18:45:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" IESG just approved this revision of the document. Formal annoucement will follow from the IESG secretariat in the next few days. Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 15:40:57 +0000 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" Cc: "Ben Mack-Crane" , Subject: RE: ASON reqts Date: Thu, 15 May 2003 11:36:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kireeti, Thanks for your note. Some clarifications in-line. -Vishal > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Wednesday, May 14, 2003 6:03 PM > To: Vishal Sharma > Cc: Ben Mack-Crane; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > Both documents would then have to be progressed in tandem within > > the WG, because, as Ben rightly observed, routing specifications > > do influence what is carried in signaling. > > The progress of GMPLS signaling and routing was always separate, as > can be seen even now: signaling has been an RFC for some time now, > whereas routing is still in Last Call. > > In fact, the charter states that signaling and routing be kept > separate: > - Define signalling and measurement protocols that are independent of > each other. This allows applications other than the signalling > protocol to use the measurement protocol; it also allows the > signalling protocol to use knowledge obtained by means other than the > measurement protocol. > > This is not to say that they must be developed separately, but a > too-strong tie between them would hurt the above goal. I should have clarified that I did not mean that the two pieces of work (routing and signaling) should be so tightly coupled that one cannot proceed independently of the other. What I did mean was that it would be better to initiate the routing work as well, so that any impact that routing has on signaling is captured in the signaling work early on. This will be useful, as it'll prevent problems later. (I think this was also largely true of the way in which we developed the GMPLS protocols.) > Finally, there is a need for GMPLS for ASON signaling requirements, > whereas there doesn't appear to be such a pressing need for GMPLS > for ASON routing requirements. I believe the initial routing requirements are captured in ITU doc. G.7715. However, I am not sure whether, unlike signaling, the ITU has begun work on the protocol-specific instantiations of routing requirements. The apparent lack of GMPLS for ASON routing requirements might just be a reflection of work not having begun in full swing on the routing aspect yet. (As per my reasoning above, I would expect that the ITU too would also be working on the routing aspect, perhaps some of the ITU experts here can shed more light on this.) -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 11:23:45 +0000 Message-Id: <200305151119.HAA03627@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-tracereq-02.txt Date: Thu, 15 May 2003 07:19:26 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Tracing Requirements for Generic Tunnels Author(s) : R. Bonica, K. Kompella, D. Meyer Filename : draft-ietf-ccamp-tracereq-02.txt Pages : 9 Date : 2003-5-14 This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support the generic route-tracing application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They also use the application to discover details regarding tunnels that support IP forwarding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-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-tracereq-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-tracereq-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: <2003-5-14154024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-tracereq-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-tracereq-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-14154024.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 May 2003 00:30:54 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500D4@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Brungard, Deborah A, ALABS'" , "Ong, Lyndon" , Stephen Trowbridge Cc: "Wijnen, Bert (Bert)" , Bart.Rousseau@alcatel.be, ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 17:33:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Deborah, One more clarification, by legacy I meant a domain with a centralized control structure, such as a controlling EMS or NMS. SPC seems like more of a service type to me, which can be supported by distributed or centralized control. Cheers, Lyndon -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, May 14, 2003 1:33 PM To: Ong, Lyndon; Stephen Trowbridge Cc: Wijnen, Bert (Bert); Bart.Rousseau@alcatel.be; ccamp@ops.ietf.org Subject: RE: ASON reqts Thanks Lyndon for asking clarification- I was trying to say that ASON does not require supporting multiple address formats for a E-PC (Protocol Controller) e.g. G7713.1. Similar to NSAP support of IP, IPv6 supports NSAP. Can you clarify your take on the requirements discussion? If I read the email, the discussion was related to the definition of a control domain and support of a non-RSVP domain or legacy (management system). The answer for supporting a non-RSVP domain was the need for an interworking function (which was considered out of scope). This is analogous to ITU's work, both for G7713.1 (PNNI) and G7713.2, the interworking functions are considered out of scope. And support of legacy is via SPC (same as G7713.1) and it is included. Were any other requirements identified as missing? Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 22:20:24 +0000 Message-ID: <3EC306AF.D42A7668@tellabs.com> Date: Wed, 14 May 2003 22:17:03 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Stephen Trowbridge , "Wijnen, Bert (Bert)" , Bart.Rousseau@alcatel.be, ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah - Let me clarify: "Brungard, Deborah A, ALABS" wrote: > G7713.2 as you are noting (and Jonathan's mail) is using a subset of GMPLS signaling. I am unware of making such a statement. If anything, I see G.7713.2 as a superset of GMPLS signaling as it addresses the gaps that exist relative to ASON requirements. > It is not based on GMPLS i.e. it uses a different addressing scheme ( based on OIF addresses, not based on IP). Actually, the issues that I brought up are not based on any addressing implementation offered by the OIF (or any other body), but are based on the implementation-independant requirements stated in G.8080 Amd.1. Lets focus on the requirements, not the solution. > G7713.2 requires an interworking function plus upgrades to a RFC 3473 domain. And as G7713.2 states it "focuses on the UNI and E-NNI.. the I-NNI ..is for further study". G7713.2 is not based on any I-NNI. G7713.2 is a solution that meets the requirements. The extensions are necessary as the base GMPLS signalling protocol specs don't meet the requirements as-is. > The rsvp-te-ason draft provides extensions to RFC3473 to support ASON. It is analogous to G7713.1 (for non-ITU, G7713.1 is ASON PNNI-based E-NNI/I-NNI). No one questioned the need for G7713.1 (or that it only supports NSAP addresses for E-NNI). And no one questioned a potential conflict of G7713.1 and G7713.2. And we (ITU) used G7713.1 and our relationship with the ATM Forum as an example of our expectations for working with IETF. It is really confusing to have ITU participants now questioning the need for IETF's work on a "G7713.1". I'm not certain what your trying to get at here. The ATM Forum certainly did add Information Elements in order to support ASON services -- and they didn't need to write a new requirements document (with "overlooked" requirements) in the process. As for G.7713.1 only supporting NSAP addresses at the E-NNI: NSAPs have an Address Format Identifier (AFI) as the first octet that describes the remaining information in the Address. An AFI exists for IPv6 (AFI 34 -- see ISO/IEC 8348 Amd.1) allowing for IPv6 and IPv4 addresses to be turned in NSAPs. No separate IE Type is necessary to support IPv4 or IPv6 when NSAP support exists. G.7713.2 could have done the same thing as G.7713.1 and only supported NSAP addresses. However, since IPv4, and IPv6 address C-types had already been defined, they were included for backward compatability purposes. > If you think G7713.2 meets the requirements for extending RFC3473, contribute it. draft-lin-ccamp-gmpls-ason-rsvpte-00.txt was originally contributed in June 2002. .01 was contributed in August 2002, and .02 was contributed in Sept 2002... > The problem statement is "use of GMPLS (RFC3471) to provide call and connection management". The problem statement is aligned with G7713.1 on control domain definition, addressing, and functionality. Its interesting to see that: - G7713.1 includes text and pictures defining control domains and how G.7713.1 fits into the definition, - G.7713.1 includes text describing how to support both NSAP and IP addressing while the proposed ASON requirements draft does not... Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 22:03:17 +0000 Date: Wed, 14 May 2003 15:02:34 -0700 (PDT) From: Kireeti Kompella To: Vishal Sharma cc: Ben Mack-Crane , "" Subject: RE: ASON reqts Message-ID: <20030514144455.Y81206@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Vishal, On Wed, 14 May 2003, Vishal Sharma wrote: > I've been following this discussion for some time now, and would > like to second the proposal you've made below. Namely, that > we have a companion document that covers extensions for routing > as well. Okay, noted. > Both documents would then have to be progressed in tandem within > the WG, because, as Ben rightly observed, routing specifications > do influence what is carried in signaling. The progress of GMPLS signaling and routing was always separate, as can be seen even now: signaling has been an RFC for some time now, whereas routing is still in Last Call. In fact, the charter states that signaling and routing be kept separate: - Define signalling and measurement protocols that are independent of each other. This allows applications other than the signalling protocol to use the measurement protocol; it also allows the signalling protocol to use knowledge obtained by means other than the measurement protocol. This is not to say that they must be developed separately, but a too-strong tie between them would hurt the above goal. Finally, there is a need for GMPLS for ASON signaling requirements, whereas there doesn't appear to be such a pressing need for GMPLS for ASON routing requirements. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 21:43:14 +0000 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" , "Ben Mack-Crane" Cc: Subject: RE: ASON reqts Date: Wed, 14 May 2003 17:42:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Kireeti, I've been following this discussion for some time now, and would like to second the proposal you've made below. Namely, that we have a companion document that covers extensions for routing as well. Both documents would then have to be progressed in tandem within the WG, because, as Ben rightly observed, routing specifications do influence what is carried in signaling. Regards, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Wednesday, May 14, 2003 5:03 PM > To: Ben Mack-Crane > Cc: ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Hi Ben, > > On Wed, 14 May 2003, Ben Mack-Crane wrote: > > > CCAMPers, > > > > Having reviewed the proposed requirements draft, and some of the ensuing > > e-mail discussion, I would say that > > > > "I have read this document, and it isn't ready to be a CCAMP doc" > > Thanks for your input (thanks too to all others who've voiced their > opinion). > > > I am principally concerned that routing requirements are not included. > > While draft's title is encompassing "GMPLS Usage and Extensions for > > ASON," the abstract limits this to signaling only. > > You're right -- this document doesn't address routing (and doesn't > profess to). In keeping with other GMPLS work, I think it makes sense > to have separate signaling and routing documents, be they functional > specs, protocol details or requirements. This view appears to be > shared by the ITU-T as well, from what I understand. > > In the light of this, I have a question for you: > - In your opinion, should the document under consideration become a > CCAMP WG _just for signaling_? I.e., if we had a companion doc > that described the routing requirements for ASON, would that meet > your objection? > > Thanks, > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 21:03:19 +0000 Date: Wed, 14 May 2003 14:02:35 -0700 (PDT) From: Kireeti Kompella To: Ben Mack-Crane cc: ccamp@ops.ietf.org Subject: Re: ASON reqts Message-ID: <20030514135322.J79692@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Ben, On Wed, 14 May 2003, Ben Mack-Crane wrote: > CCAMPers, > > Having reviewed the proposed requirements draft, and some of the ensuing > e-mail discussion, I would say that > > "I have read this document, and it isn't ready to be a CCAMP doc" Thanks for your input (thanks too to all others who've voiced their opinion). > I am principally concerned that routing requirements are not included. > While draft's title is encompassing "GMPLS Usage and Extensions for > ASON," the abstract limits this to signaling only. You're right -- this document doesn't address routing (and doesn't profess to). In keeping with other GMPLS work, I think it makes sense to have separate signaling and routing documents, be they functional specs, protocol details or requirements. This view appears to be shared by the ITU-T as well, from what I understand. In the light of this, I have a question for you: - In your opinion, should the document under consideration become a CCAMP WG _just for signaling_? I.e., if we had a companion doc that described the routing requirements for ASON, would that meet your objection? Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 20:48:40 +0000 Date: Wed, 14 May 2003 13:48:11 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org Subject: Re: ASON reqts - Moving on? Message-ID: <20030514115603.H79692@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 May 2003, Adrian Farrel wrote: > Can we back off a bit and just look at the ASON requirements draft? Thanks, Adrian. > Having had a quick chat with a couple of the authors (not all) we are in > agreement that this draft is to state clearly the requirements of the ASON > architecture as applicable to GMPLS signaling within the context of the IETF. Okay. > The motives are to > - make those requirements accessible to the IETF community > in a form and format with which they are familiar I would encourage adding "terminology" to the above, if the document doesn't already do so. > - provide a basis for determining whether current protocol > solutions fully address the requirements. Okay: so this document is _setting the stage_ for a meaningful discussion of solutions. I'll just note that we have a precedent in CCAMP for this: there were no requirements for OLI until there was (vigorous) debate on the relative merits of two different solutions. The emergence of a reqts doc helped clarify issues. > The second point is the one that might give rise to debate in the future. That > is, once the requirements have been exposed in a way we understand, we may > discover that the existing work is exemplary or we may determine there are holes > to be plugged. Sounds fine. > Views on this are premature until the requirements draft is solid > (although the prematurity of views will in no way prevent them from being > expressed). Too true. > Kireeti, what are the next steps? Let's see what the WG says about ASON reqts first. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 20:34:07 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Wed, 14 May 2003 15:32:48 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33F6@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMaOyU5shYaf58hTIOW4ahYJeW0AQAGhU0A From: "Brungard, Deborah A, ALABS" To: "Ong, Lyndon" , "Stephen Trowbridge" Cc: "Wijnen, Bert (Bert)" , , Thanks Lyndon for asking clarification- I was trying to say that ASON does not require supporting multiple = address formats for a E-PC (Protocol Controller) e.g. G7713.1. Similar to NSAP support of IP, IPv6 supports NSAP. Can you clarify your take on the requirements discussion? If I read the = email, the discussion was related to the definition of a control domain = and support of a non-RSVP domain or legacy (management system). The = answer for supporting a non-RSVP domain was the need for an interworking = function (which was considered out of scope). This is analogous to ITU's = work, both for G7713.1 (PNNI) and G7713.2, the interworking functions = are considered out of scope. And support of legacy is via SPC (same as = G7713.1) and it is included. Were any other requirements identified as = missing? Deborah -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Wednesday, May 14, 2003 1:09 PM To: Brungard, Deborah A, ALABS; Stephen Trowbridge Cc: Wijnen, Bert (Bert); Bart.Rousseau@alcatel.be; ccamp@ops.ietf.org Subject: RE: ASON reqts Hi Deborah, Just wanted to clear up a point - 7713.1 supports NSAP format addresses, however there are methods of mapping IPv4 and IPv6 addresses into the NSAP format, so there is no fundamental limitation in this (also, I believe the ATMF has or is working on a document on address format mapping). I think the discussion seems to be pointing out that some ASON requirements just don't fall within the scope of IETF work, so it may not be appropriate to address them in IETF (hmm, sounds like how 3474 was created...) Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 19:52:41 +0000 Message-ID: <3EC29B9F.5050405@tellabs.com> Date: Wed, 14 May 2003 14:40:15 -0500 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit CCAMPers, Having reviewed the proposed requirements draft, and some of the ensuing e-mail discussion, I would say that "I have read this document, and it isn't ready to be a CCAMP doc" I am principally concerned that routing requirements are not included. While draft's title is encompassing "GMPLS Usage and Extensions for ASON," the abstract limits this to signaling only. I do not think addressing signaling in a vacuum is a good idea, as there are requirements in the routing area that have impact on the signaling protocols (in so far as they carry routing information) and other general requirements that impact both signaling and routing (such as not exposing network topology information across untrusted interfaces). I am concerned that if adopted as a WG doc in this state, this would be considered agreement to the limited scope of the draft. Regards, Ben Kireeti Kompella wrote: > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > >>To take things one at a time, it would be very useful to read and comment >>on the ASON reqts draft, as this was deemed tremendously important, and >>a rich source of misunderstanding and cross-talk; and coming to a common >>understanding over this should help get the IETF and the ITU working >>together. > > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. > ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 18:56:07 +0000 Date: Wed, 14 May 2003 11:54:53 -0700 (PDT) From: Kireeti Kompella To: Stephen Trowbridge cc: "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , "" Subject: Re: ASON reqts Message-ID: <20030514105015.K79692@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Steve, On Wed, 14 May 2003, Stephen Trowbridge wrote: > I have a growing sense of unease that we could be headed > for trouble here because, among those who seem to support that > this becomes a WG document, there seem to be (among those who > indicate a reason) a wide variety of different motivations about > WHY this should be a WG document and what the posters expect > will happen as a result. As I just said in a private email exchange, I've given up trying to infer motivations, intentions and purposes -- I don't have a degree in political science or in psychology (and I'm beginning to wish I had one in psychiatry). Fortunately, that's not my job as a chair; my job as a chair is to progress technically accurate, relevant documents that fall within the CCAMP charter. > Perhaps more helpful than just a Yes/No preference, it would > be more helpful to characterize the reasons so that, if this > becomes a WG document, we know we have a consensus on why we > are doing this and what we are trying to accomplish. Well, thanks, Steve for telling me how to do my job. The IETF progresses (or not) documents based on rough consensus -- raising hands, hums, and their electronic equivalents. Any discussion that accompanies the call for consensus is very useful, but its purpose is (or should be) to persuade others to your point of view. > I think I have detected the following motivations from different > posts in the thread: You may have captured the motivations. It makes interesting reading, in any case. You may then persuade people to decide which of positions A-Z they subscribe to -- but ultimately, whether on the basis of motivations or technical content or political leaning, each one needs to state their preference on progressing, holding back or dumping the requirements document. As a WG chair, I sincerely hope that the basis will be technical merit and relevance. That makes the chairs' job easier. Perhaps it would be useful to emphasize the following: o This is not a call to make the doc an RFC, it's to make the doc a CCAMP WG document. The document doesn't have to be perfect, it doesn't have to satisfy rfc2223bis, references are minor details. o Making a doc a WG doc does not automatically mean it gets published. It is a statement that the WG thinks that this work is useful, and should be pursued. It does give the document a certain legitimacy both within the IETF and with other SDOs, which means that the decision to make a doc a WG doc is not to be taken lightly; on the other hand, there are cases where a WG doc has either been altered drastically, or abandoned as a result of WG deliberations. o Making any one document a WG doc has no direct effect on another doc. So, for those who think that making the reqts doc a WG doc means that a solutions doc (such as draft-dimitri-ccamp-gmpls-rsvp-te-ason) also becomes a WG doc are mistaken. Finally, the above is not to be taken as a deterrent to discussion. I encourage discussion, whether it be on technical content, motivations, or future activity. All I ask is that the discussion be conducted professionally, and the material be relevant to the CCAMP list. I thank you all that this discussion has so far been all of the above. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 17:40:16 +0000 Message-ID: <3EC27F19.4DE564CA@lucent.com> Date: Wed, 14 May 2003 11:38:33 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, "'Kireeti Kompella'" Subject: Re: ASON reqts - Moving on? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, Adrian Farrel wrote: snip > The motives are to > - make those requirements accessible to the IETF community > in a form and format with which they are familiar Two issues here: "accessibility" and "form and format" In terms of accessibility, the "original" ASON requirements (G.8080, G.7713, etc.) have all been sent via liaison from ITU-T to IETF. Those that haven't been translated to html or pdf by the secretariat for direct access from the IETF site are available from the SG15 FTP site. In terms of form and format, give me a break. There have been multiple forms/formats/sets of vocabulary involved with virtually every corner of the telecom field that I have been involved with over the last 25 years. But many of the smartest people I know are also in this field, and as long as people are willing to work together and try to understand, there has never been a problem. For example, SONET and SDH have different names for almost everything, but by now anyone involved with these technologies is bi-lingual and can understand a concept perfectly well no matter which terminology it is described in. SONET people even understand it when Maarten Vissers describes equipment functions using triangles and tapezoids. So I don't think there is a pressing need to "translate" these specifications to ASCII/IETF-ese. Doing translations creates its own set of problems. First of all, one has to worry about the accuracy of the translation. Second, it creates a maintenance problem: once something is documented in two places, which is the controlling document? When a correction or update needs to occur, it now needs to happen in both places. Of course, if people aren't willing to work together and try to understand, no amount of spoon feeding, ASCII translation, etc. will help this. > - provide a basis for determining whether current protocol > solutions fully address the requirements. So we started with requirements documents (not all IETF) and produced protocol solutions, and now we should decide whether the protocol solutions met the requirements by producing a translation of the requirements? It seems like it would be better to do this kind of validation against the ORIGINAL requirements than against a translation: then you don't need to decide whether an apparent mismatch is an unmet requirement or a bad translation. If a problem is found, it can be fixed at its source instead of in some downstream document. To assess the motivation you expressed for embarking on this effort, it kind of sounds like "2 (keep the protocol the same and document everythinig in IETF) unless the editors decide to switch to 3, 4, or 5 later*!?) Regards, Steve Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 17:26:33 +0000 Message-ID: <3EC27A81.A48AE537@ieee.org> Date: Wed, 14 May 2003 13:18:58 -0400 From: Sudheer Dharanikota MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "I have read this document and it is ready to be a CCAMP WG doc" Regards, sudheer Kireeti Kompella wrote: > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to read and comment > > on the ASON reqts draft, as this was deemed tremendously important, and > > a rich source of misunderstanding and cross-talk; and coming to a common > > understanding over this should help get the IETF and the ITU working > > together. > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 17:06:48 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500C8@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Brungard, Deborah A, ALABS'" , Stephen Trowbridge Cc: "Wijnen, Bert (Bert)" , Bart.Rousseau@alcatel.be, ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 10:09:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Deborah, Just wanted to clear up a point - 7713.1 supports NSAP format addresses, however there are methods of mapping IPv4 and IPv6 addresses into the NSAP format, so there is no fundamental limitation in this (also, I believe the ATMF has or is working on a document on address format mapping). I think the discussion seems to be pointing out that some ASON requirements just don't fall within the scope of IETF work, so it may not be appropriate to address them in IETF (hmm, sounds like how 3474 was created...) Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 16:54:17 +0000 Message-ID: <02b401c31a39$4efa2420$681810ac@movaz.com> From: "Adrian Farrel" To: , "'Kireeti Kompella'" Subject: ASON reqts - Moving on? Date: Wed, 14 May 2003 12:53:13 -0400 Can we back off a bit and just look at the ASON requirements draft? Having had a quick chat with a couple of the authors (not all) we are in agreement that this draft is to state clearly the requirements of the ASON architecture as applicable to GMPLS signaling within the context of the IETF. The motives are to - make those requirements accessible to the IETF community in a form and format with which they are familiar - provide a basis for determining whether current protocol solutions fully address the requirements. We believe the former is a necessity notwithstanding the prior work. At the very least it rehashes old ground with which the informed reader should already be familiar. At best it puts added clarity and context on top of the existing work. The second point is the one that might give rise to debate in the future. That is, once the requirements have been exposed in a way we understand, we may discover that the existing work is exemplary or we may determine there are holes to be plugged. Views on this are premature until the requirements draft is solid (although the prematurity of views will in no way prevent them from being expressed). As has been pointed out by several people, there are areas in the current draft which need clarification and extension. There have also been some topics raised which the authors need to examine - prinicpally whether certain requirements *are* requirements and whether they have been omitted. This is good, and why the mailing list exists. My personal view is - the authors need to do more work on the draft - it would help widen the discussion of the draft outside the IETF if it were a WG draft - the material is relevant to the WG - it may be a repeat of work that is already done, but we can't tell until we've done it. Kireeti, what are the next steps? Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 16:00:26 +0000 Message-ID: <3EC267D9.BE27DDD1@lucent.com> Date: Wed, 14 May 2003 09:59:21 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I still think it is better to argue it out now and reach agreement on what problem we are trying to solve. If we accept this as a WG draft without doing this, we seem to be accepting that we do have SOME problem to solve, and then arguing later on what it was. Regards, Steve John Drake wrote: > > Regardless of what we do now, I'm sure there will be lots of arguments > later. > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Wednesday, May 14, 2003 8:24 AM > > To: John Drake > > Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); > > ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > John, > > First, I think there is a big difference between 3 and 4 and > > what should > > be done about it: > > For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need > > to fix RFC 3474 > > by superceding with something aligned with G.7713.2. > > For 4, G.7713.2 is broken (as is, by extension RFC 3474). > > Here we need to > > coordinate with ITU-T to fix both. It seems like a bad > > strategy to try > > to have IETF fly solo and develop a "better" solution to > > ITU-T requirements > > than what ITU-T did. > > JD: Given that G.7713.2 == RFC3474, what does it matter? If it > is broken in one venue, there's a good chance it's broken in the > other. > > > > > Back to why it is important to decide where we are going with > > this first: > > I think that some who support this as a WG document are doing > > so because > > they want to see the base protocol and the ASON extensions > > documented in > > a common place, and NOT because they were intending to open > > the door to > > changing the protocol now. > > JD: I don't buy this at all. Until we get agreement on requirements > how do we know whether a given document supports those requirements? > > > If we can get agreement over why > > we are doing > > this now, I think we can avoid a lot of arguments later. > > JD: I completely disagree. Regardless of what we do now, there will > be plenty of arguments later. > > > Regards, > > Steve > > > > John Drake wrote: > > > > > > Stephen, > > > > > > If this I-D is progressed, it will be used as the basis for > > deciding between > > > 2, 3, and 4, although I don't see any practical difference > > between 3 and 4. > > > I haven't seen 5 expressed by anyone (at least in the > > context of this I-D). > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > Sent: Wednesday, May 14, 2003 6:49 AM > > > > To: Ash, Gerald R (Jerry), ALABS > > > > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > > > > Subject: Re: ASON reqts > > > > > > > > > > > > All, > > > > I have a growing sense of unease that we could be headed > > > > for trouble here because, among those who seem to support that > > > > this becomes a WG document, there seem to be (among those who > > > > indicate a reason) a wide variety of different motivations about > > > > WHY this should be a WG document and what the posters expect > > > > will happen as a result. > > > > > > > > Perhaps more helpful than just a Yes/No preference, it would > > > > be more helpful to characterize the reasons so that, if this > > > > becomes a WG document, we know we have a consensus on why we > > > > are doing this and what we are trying to accomplish. > > > > > > > > I think I have detected the following motivations from different > > > > posts in the thread: > > > > > > > > 1. Those who don't want this to be a WG document (we are done with > > > > this version of the specifications, lets get some experience > > > > with them before considering any further change or evolution). > > > > > > > > 2. Those who think this should be a WG document so that ASON > > > > extensions > > > > currently standardized in ITU-T will get standards > > track status in > > > > IETF (no intent to change the protocol, but document > > the superset > > > > in one place so that we don't get so many GMPLS implementations > > > > that don't support the ASON extensions). > > > > > > > > 3. Those who think there is nothing wrong with the ITU-T > > extensions to > > > > meet the ASON requirements, but believe that RFC 3474 > > > > didn't translate > > > > G.7713.2 properly and this draft is a first step to fixing > > > > RFC 3474. > > > > > > > > 4. Those who think that even the ITU-T extensions don't > > meet the ASON > > > > requirements, so IETF should now take it over and do it > > > > better starting > > > > with this draft. > > > > > > > > 5. Those who think that ITU-T didn't get the requirements > > right, so we > > > > need to look at everything from scratch. > > > > > > > > There may be other motivations which I haven't detected or > > > > characterized, > > > > but these seem to be the main camps. > > > > > > > > So I don't think it is enough to just count how many say > > it should be > > > > a WG document. I think that those in camp #2 above might be > > > > pretty upset > > > > if the result of making this a WG document turns out to be a > > > > rototilling > > > > of the protocol driven by those in camps #4 and #5. We will > > > > have a much > > > > smoother time if we agree on why we are doing this and what > > > > we are trying > > > > to accomplish as a result. > > > > > > > > Once we settle on which of 1-5 we are trying to accomplish: > > > > - If it is 1, 2, or 3, we can handle in IETF. > > > > - If it is 4 or 5, we had better send a liaison to ITU-T. > > > > > > > > Please let me know if I missed any proposed purposes for > > this draft. > > > > Otherwise, for those of you who support this being a WG > > draft, I think > > > > it might be helpful if you would indicate which of (2-5) > > characterizes > > > > why you support this so we can make sure we are on the > > same page as to > > > > what we are trying to accomplish. > > > > > > > > Regards, > > > > Steve > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 15:49:44 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97257F@nimbus> From: John Drake To: 'Stephen Trowbridge' Cc: "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 08:48:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Regardless of what we do now, I'm sure there will be lots of arguments later. > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Wednesday, May 14, 2003 8:24 AM > To: John Drake > Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); > ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > John, > First, I think there is a big difference between 3 and 4 and > what should > be done about it: > For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need > to fix RFC 3474 > by superceding with something aligned with G.7713.2. > For 4, G.7713.2 is broken (as is, by extension RFC 3474). > Here we need to > coordinate with ITU-T to fix both. It seems like a bad > strategy to try > to have IETF fly solo and develop a "better" solution to > ITU-T requirements > than what ITU-T did. JD: Given that G.7713.2 == RFC3474, what does it matter? If it is broken in one venue, there's a good chance it's broken in the other. > > Back to why it is important to decide where we are going with > this first: > I think that some who support this as a WG document are doing > so because > they want to see the base protocol and the ASON extensions > documented in > a common place, and NOT because they were intending to open > the door to > changing the protocol now. JD: I don't buy this at all. Until we get agreement on requirements how do we know whether a given document supports those requirements? > If we can get agreement over why > we are doing > this now, I think we can avoid a lot of arguments later. JD: I completely disagree. Regardless of what we do now, there will be plenty of arguments later. > Regards, > Steve > > John Drake wrote: > > > > Stephen, > > > > If this I-D is progressed, it will be used as the basis for > deciding between > > 2, 3, and 4, although I don't see any practical difference > between 3 and 4. > > I haven't seen 5 expressed by anyone (at least in the > context of this I-D). > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Wednesday, May 14, 2003 6:49 AM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > > > Subject: Re: ASON reqts > > > > > > > > > All, > > > I have a growing sense of unease that we could be headed > > > for trouble here because, among those who seem to support that > > > this becomes a WG document, there seem to be (among those who > > > indicate a reason) a wide variety of different motivations about > > > WHY this should be a WG document and what the posters expect > > > will happen as a result. > > > > > > Perhaps more helpful than just a Yes/No preference, it would > > > be more helpful to characterize the reasons so that, if this > > > becomes a WG document, we know we have a consensus on why we > > > are doing this and what we are trying to accomplish. > > > > > > I think I have detected the following motivations from different > > > posts in the thread: > > > > > > 1. Those who don't want this to be a WG document (we are done with > > > this version of the specifications, lets get some experience > > > with them before considering any further change or evolution). > > > > > > 2. Those who think this should be a WG document so that ASON > > > extensions > > > currently standardized in ITU-T will get standards > track status in > > > IETF (no intent to change the protocol, but document > the superset > > > in one place so that we don't get so many GMPLS implementations > > > that don't support the ASON extensions). > > > > > > 3. Those who think there is nothing wrong with the ITU-T > extensions to > > > meet the ASON requirements, but believe that RFC 3474 > > > didn't translate > > > G.7713.2 properly and this draft is a first step to fixing > > > RFC 3474. > > > > > > 4. Those who think that even the ITU-T extensions don't > meet the ASON > > > requirements, so IETF should now take it over and do it > > > better starting > > > with this draft. > > > > > > 5. Those who think that ITU-T didn't get the requirements > right, so we > > > need to look at everything from scratch. > > > > > > There may be other motivations which I haven't detected or > > > characterized, > > > but these seem to be the main camps. > > > > > > So I don't think it is enough to just count how many say > it should be > > > a WG document. I think that those in camp #2 above might be > > > pretty upset > > > if the result of making this a WG document turns out to be a > > > rototilling > > > of the protocol driven by those in camps #4 and #5. We will > > > have a much > > > smoother time if we agree on why we are doing this and what > > > we are trying > > > to accomplish as a result. > > > > > > Once we settle on which of 1-5 we are trying to accomplish: > > > - If it is 1, 2, or 3, we can handle in IETF. > > > - If it is 4 or 5, we had better send a liaison to ITU-T. > > > > > > Please let me know if I missed any proposed purposes for > this draft. > > > Otherwise, for those of you who support this being a WG > draft, I think > > > it might be helpful if you would indicate which of (2-5) > characterizes > > > why you support this so we can make sure we are on the > same page as to > > > what we are trying to accomplish. > > > > > > Regards, > > > Steve > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 15:25:09 +0000 Message-ID: <3EC25FA9.111085EF@lucent.com> Date: Wed, 14 May 2003 09:24:25 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: "Ash, Gerald R (Jerry), ALABS" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, First, I think there is a big difference between 3 and 4 and what should be done about it: For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need to fix RFC 3474 by superceding with something aligned with G.7713.2. For 4, G.7713.2 is broken (as is, by extension RFC 3474). Here we need to coordinate with ITU-T to fix both. It seems like a bad strategy to try to have IETF fly solo and develop a "better" solution to ITU-T requirements than what ITU-T did. Back to why it is important to decide where we are going with this first: I think that some who support this as a WG document are doing so because they want to see the base protocol and the ASON extensions documented in a common place, and NOT because they were intending to open the door to changing the protocol now. If we can get agreement over why we are doing this now, I think we can avoid a lot of arguments later. Regards, Steve John Drake wrote: > > Stephen, > > If this I-D is progressed, it will be used as the basis for deciding between > 2, 3, and 4, although I don't see any practical difference between 3 and 4. > I haven't seen 5 expressed by anyone (at least in the context of this I-D). > > Thanks, > > John > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Wednesday, May 14, 2003 6:49 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > All, > > I have a growing sense of unease that we could be headed > > for trouble here because, among those who seem to support that > > this becomes a WG document, there seem to be (among those who > > indicate a reason) a wide variety of different motivations about > > WHY this should be a WG document and what the posters expect > > will happen as a result. > > > > Perhaps more helpful than just a Yes/No preference, it would > > be more helpful to characterize the reasons so that, if this > > becomes a WG document, we know we have a consensus on why we > > are doing this and what we are trying to accomplish. > > > > I think I have detected the following motivations from different > > posts in the thread: > > > > 1. Those who don't want this to be a WG document (we are done with > > this version of the specifications, lets get some experience > > with them before considering any further change or evolution). > > > > 2. Those who think this should be a WG document so that ASON > > extensions > > currently standardized in ITU-T will get standards track status in > > IETF (no intent to change the protocol, but document the superset > > in one place so that we don't get so many GMPLS implementations > > that don't support the ASON extensions). > > > > 3. Those who think there is nothing wrong with the ITU-T extensions to > > meet the ASON requirements, but believe that RFC 3474 > > didn't translate > > G.7713.2 properly and this draft is a first step to fixing > > RFC 3474. > > > > 4. Those who think that even the ITU-T extensions don't meet the ASON > > requirements, so IETF should now take it over and do it > > better starting > > with this draft. > > > > 5. Those who think that ITU-T didn't get the requirements right, so we > > need to look at everything from scratch. > > > > There may be other motivations which I haven't detected or > > characterized, > > but these seem to be the main camps. > > > > So I don't think it is enough to just count how many say it should be > > a WG document. I think that those in camp #2 above might be > > pretty upset > > if the result of making this a WG document turns out to be a > > rototilling > > of the protocol driven by those in camps #4 and #5. We will > > have a much > > smoother time if we agree on why we are doing this and what > > we are trying > > to accomplish as a result. > > > > Once we settle on which of 1-5 we are trying to accomplish: > > - If it is 1, 2, or 3, we can handle in IETF. > > - If it is 4 or 5, we had better send a liaison to ITU-T. > > > > Please let me know if I missed any proposed purposes for this draft. > > Otherwise, for those of you who support this being a WG draft, I think > > it might be helpful if you would indicate which of (2-5) characterizes > > why you support this so we can make sure we are on the same page as to > > what we are trying to accomplish. > > > > Regards, > > Steve > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 15:03:11 +0000 Message-Id: <4.3.2.7.2.20030514110006.01bb17e0@funnel.cisco.com> Date: Wed, 14 May 2003 11:02:32 -0400 To: Manoj Agiwal From: Baktha Muralidharan Subject: Re: FW: LMP Message ID Cc: "'Ccamp (E-mail)" , "'Jonathan.Lang@RinconNetworks.com'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:37 AM 5/13/2003 -0500, Manoj Agiwal wrote: >Hi , > Lmp drafts tells that Message ID should be monotonically increasing . > > Section 7 also tells that "Unacknowledge messages sent with Message_id >object should be retransmitted until the message is > acknowledged or until retry limit is reached." > > Do we have to sent all retransmitted messages with the same Message Id >as sent previously or it should be in monotonically > increasing order. > >Regards , >Manoj Hi Manoj, An unacknowledged message could have been lost; i.e. might not have reached the neighbor. So, the neighbor has no way of determining if a message is a re-transmit and will fail [and nack] a message with out-of-order message-id. So, re-transmit attempts should increase message id. /Baktha Muralidharan Cisco Systems. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 14:51:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Wed, 14 May 2003 09:49:50 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33F4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMaIahP4ojxMrh+QsGH16lH5AWnEQAAX+oA From: "Brungard, Deborah A, ALABS" To: "Stephen Trowbridge" Cc: "Wijnen, Bert (Bert)" , , Hi Steve, Thanks for asking specifically.. RFC3473 is to support multi-layer equipment. IP-subnetworks? Generic = transport networks using ASON extensions? Using G8080 terminology, = RFC3473 supports a control domain (multi-(transport)layer /multi-vendor) = based on GMPLS (i.e. uses IP addressing). G7713.2 as you are noting (and Jonathan's mail) is using a subset of = GMPLS signaling. It is not based on GMPLS i.e. it uses a different = addressing scheme ( based on OIF addresses, not based on IP). G7713.2 = requires an interworking function plus upgrades to a RFC 3473 domain. = And as G7713.2 states it "focuses on the UNI and E-NNI.. the I-NNI ..is = for further study". G7713.2 is not based on any I-NNI. The rsvp-te-ason draft provides extensions to RFC3473 to support ASON. = It is analogous to G7713.1 (for non-ITU, G7713.1 is ASON PNNI-based = E-NNI/I-NNI). No one questioned the need for G7713.1 (or that it only = supports NSAP addresses for E-NNI). And no one questioned a potential = conflict of G7713.1 and G7713.2. And we (ITU) used G7713.1 and our = relationship with the ATM Forum as an example of our expectations for = working with IETF. It is really confusing to have ITU participants now = questioning the need for IETF's work on a "G7713.1". If you think G7713.2 meets the requirements for extending RFC3473, = contribute it. The problem statement is "use of GMPLS (RFC3471) to = provide call and connection management". The problem statement is = aligned with G7713.1 on control domain definition, addressing, and = functionality. Deborah -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Wednesday, May 14, 2003 10:04 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Bart.Rousseau@alcatel.be; ccamp@ops.ietf.org Subject: Re: ASON reqts Deborah, I am a little confused here: We have two versions of the protocol: - Base GMPLS, developed to the requirements for controlling TDM, WDM = layers that are used below the packet layer(s) in IP networks. - GMPLS plus ASON extensions, developed to also address requirements of general (not necessarily IP) transport networks. What I think you are suggesting is to address how these versions of the protocol interwork. The primary case that I can envision is the = following: - IP subnetworks using base GMPLS, interconnected across generic = transport networks using ASON extensions. With the IP subnetworks on the edge = and the generic transport in the middle, I think there is no problem with the current protocols. But what you seem to suggest is the following: - Subnetworks using ASON extensions interconnected across a core using only base GMPLS. This case seems a little farfetched - that you would interconnect = subnetworks that support a combination of circuit and packet traffic across a base = GMPLS only (non-circuit traffic aware?) core. Lets make sure this is a real = network configuration before we undertake an effort to change the protocols to = support it. Regards, Steve "Brungard, Deborah A, ALABS" wrote: >=20 > Hi Bert, >=20 > Can you provide clarification on your email? >=20 > - the January ASON email exchange and the previous ITU-T liaisons = clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two = ason drafts submitted are to initiate this work. > - majority of the email supports the reqs draft becoming a WG = document. And hopefully, those concerned will also support as WG = document based on the understanding a WG doc is a work in progress as = posted by one email: > > There are a few issues that I don't quite understand and/or need > > clarification on, but the current vote is WG acceptance, not = last-call. > > I have no issues with it that would keep it out from the WG. >=20 > Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. = This draft addresses a totally different application/solution than = G7713.2. The rsvp-te-ason draft covers the necessary extensions to = RFC-3473 to support ASON for a GMPLS network. The difference of this = draft and G7713.2 is that this draft is backward and forward compatible = for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol = Controller (I-PC)) do not need to be updated. G7713.2 is an E-NNI which = is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not = provide call and connection functional separation because it was not = based on use with an RFC-3473 network. Eve's mail clarifies this = regarding the domain definitions. If the draft is confusing in this = regard, we can work on the wording. >=20 > The draft is on extending RFC-3473 to support ASON. If IETF does not = extend RFC-3473, then GMPLS will not support ASON. This work is totally = independent of the existence of G7713.2. As we discuss the draft, we can = clarify if this is confusing. >=20 > Deborah >=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 13, 2003 10:38 AM > To: Bart.Rousseau@alcatel.be > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts >=20 > AD-hat on. >=20 > Bart writes: > > > > > > Stephen, > > > > I think the point was rather to go back to > > just a single GMPLS spec instead of two (let alone three) = variants... > > > If that is the case, and if we want to do that in IETF CCAMP > (not sure it is part of the current CCAMP charter), > then it seems to me that we (CCAMP) should excercise these steps: >=20 > - send some liason to ITU-T SG 15 to explain that we found that > there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard > - that we think that this is NOT goodness, and that we regret that > we did send the ASON people away a few years back and did not > closely follow their work in ITU > - that we now believe that we should have worked better together, > - that we would like to explore ways to try and mrege the two > solution back into one common solution >=20 > And then await the response and hope ITU will agree and then see > how the work can be organized. >=20 > > > > Bart > > > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 14:15:29 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97257D@nimbus> From: John Drake To: 'Stephen Trowbridge' , "Ash, Gerald R (Jerry), ALABS" Cc: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 07:15:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Stephen, If this I-D is progressed, it will be used as the basis for deciding between 2, 3, and 4, although I don't see any practical difference between 3 and 4. I haven't seen 5 expressed by anyone (at least in the context of this I-D). Thanks, John > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Wednesday, May 14, 2003 6:49 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > All, > I have a growing sense of unease that we could be headed > for trouble here because, among those who seem to support that > this becomes a WG document, there seem to be (among those who > indicate a reason) a wide variety of different motivations about > WHY this should be a WG document and what the posters expect > will happen as a result. > > Perhaps more helpful than just a Yes/No preference, it would > be more helpful to characterize the reasons so that, if this > becomes a WG document, we know we have a consensus on why we > are doing this and what we are trying to accomplish. > > I think I have detected the following motivations from different > posts in the thread: > > 1. Those who don't want this to be a WG document (we are done with > this version of the specifications, lets get some experience > with them before considering any further change or evolution). > > 2. Those who think this should be a WG document so that ASON > extensions > currently standardized in ITU-T will get standards track status in > IETF (no intent to change the protocol, but document the superset > in one place so that we don't get so many GMPLS implementations > that don't support the ASON extensions). > > 3. Those who think there is nothing wrong with the ITU-T extensions to > meet the ASON requirements, but believe that RFC 3474 > didn't translate > G.7713.2 properly and this draft is a first step to fixing > RFC 3474. > > 4. Those who think that even the ITU-T extensions don't meet the ASON > requirements, so IETF should now take it over and do it > better starting > with this draft. > > 5. Those who think that ITU-T didn't get the requirements right, so we > need to look at everything from scratch. > > There may be other motivations which I haven't detected or > characterized, > but these seem to be the main camps. > > So I don't think it is enough to just count how many say it should be > a WG document. I think that those in camp #2 above might be > pretty upset > if the result of making this a WG document turns out to be a > rototilling > of the protocol driven by those in camps #4 and #5. We will > have a much > smoother time if we agree on why we are doing this and what > we are trying > to accomplish as a result. > > Once we settle on which of 1-5 we are trying to accomplish: > - If it is 1, 2, or 3, we can handle in IETF. > - If it is 4 or 5, we had better send a liaison to ITU-T. > > Please let me know if I missed any proposed purposes for this draft. > Otherwise, for those of you who support this being a WG draft, I think > it might be helpful if you would indicate which of (2-5) characterizes > why you support this so we can make sure we are on the same page as to > what we are trying to accomplish. > > Regards, > Steve > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 14:14:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Wed, 14 May 2003 09:13:14 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33F3@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMaIBxxloD7AWwfTL6lF1gPfKvBngAAKpHg From: "Brungard, Deborah A, ALABS" To: "Stephen Trowbridge" , "Ash, Gerald R (Jerry), ALABS" Cc: "Wijnen, Bert (Bert)" , Steve, Your mail is recommending "we break out a couple dozen eggs and continue = to throw them between the ITU and the IETF" as one email suggested;-) We are discussing specific comments on the draft which are serious = enough to prevent it from being a WG document. We are not discussing = personal/company motivations. And we are discussing the reqs draft, not the rsvp draft, and not = G7713.2. The count is going. If you have specific comments on the problem = statement, please provide. Personal motivations and egg throwing are = off-line discussion. Deborah -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Wednesday, May 14, 2003 9:49 AM To: Ash, Gerald R (Jerry), ALABS Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org Subject: Re: ASON reqts All, I have a growing sense of unease that we could be headed for trouble here because, among those who seem to support that this becomes a WG document, there seem to be (among those who indicate a reason) a wide variety of different motivations about WHY this should be a WG document and what the posters expect will happen as a result. Perhaps more helpful than just a Yes/No preference, it would be more helpful to characterize the reasons so that, if this becomes a WG document, we know we have a consensus on why we are doing this and what we are trying to accomplish. I think I have detected the following motivations from different posts in the thread: 1. Those who don't want this to be a WG document (we are done with this version of the specifications, lets get some experience with them before considering any further change or evolution). 2. Those who think this should be a WG document so that ASON extensions currently standardized in ITU-T will get standards track status in IETF (no intent to change the protocol, but document the superset in one place so that we don't get so many GMPLS implementations that don't support the ASON extensions). 3. Those who think there is nothing wrong with the ITU-T extensions to meet the ASON requirements, but believe that RFC 3474 didn't = translate G.7713.2 properly and this draft is a first step to fixing RFC 3474. 4. Those who think that even the ITU-T extensions don't meet the ASON requirements, so IETF should now take it over and do it better = starting with this draft. 5. Those who think that ITU-T didn't get the requirements right, so we need to look at everything from scratch. There may be other motivations which I haven't detected or = characterized, but these seem to be the main camps. So I don't think it is enough to just count how many say it should be a WG document. I think that those in camp #2 above might be pretty upset if the result of making this a WG document turns out to be a rototilling of the protocol driven by those in camps #4 and #5. We will have a much smoother time if we agree on why we are doing this and what we are = trying to accomplish as a result. Once we settle on which of 1-5 we are trying to accomplish: - If it is 1, 2, or 3, we can handle in IETF. - If it is 4 or 5, we had better send a liaison to ITU-T. Please let me know if I missed any proposed purposes for this draft. Otherwise, for those of you who support this being a WG draft, I think it might be helpful if you would indicate which of (2-5) characterizes why you support this so we can make sure we are on the same page as to what we are trying to accomplish. Regards, Steve Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 14:06:14 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97257B@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 07:03:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eve, I read Steve's e-mail very carefully, but I didn't see 'domain' mentioned once. Thanks, John > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Wednesday, May 14, 2003 6:59 AM > To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel'; > Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Please see Steve's email. > > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, May 14, 2003 9:56 AM > To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan > Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Eve, > > I am having trouble parsing your e-mail. > > I thought my previous e-mail was stating what was, to use > Yakov's phrase, "obvious to the informed reader". > > Thanks, > > John > > > -----Original Message----- > > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > > Sent: Wednesday, May 14, 2003 6:47 AM > > To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel'; > > Jonathan Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Hi, > > > > Then the purpose of the reqts. draft is not explaining ITU-T > > requirements for > > ASON in an IETF friendly way. > > > > Eve > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Wednesday, May 14, 2003 9:42 AM > > To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan > > Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Eve, > > > > Let me try again. We are talking about the support of ASON in GMPLS > > networks, and > > we are trying to identify the ASON requirements on GMPLS signalling > > (RSVP-TE). By > > definition, the E-NNI/I-NNI in a GMPLS network will be > > RSVP-TE (with IP > > addressing). > > If the signalling protocol within a domain is also RSVP-TE > > then the only > > thing a > > domain boundary node will do is modify the RSVP signalling > > messages subject > > to local > > policy. > > > > If the signalling protocol within a domain is not RSVP-TE, > > then a domain > > boundary > > node for such a domain will have to build an interworking > > function between > > its > > signalling protocol and RSVP-TE. This is not within the > > scope of this work. > > > > Thanks, > > > > John > > > > > > > -----Original Message----- > > > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > > > Sent: Wednesday, May 14, 2003 5:27 AM > > > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > Hi, > > > > > > I strongly disagree. The concept of control domains is > one of the > > > key elements of G.8080 Am. 1, and support for such is part of the > > > requirements. This makes no statement re proprietary protocols. > > > > > > Eve > > > > > > -----Original Message----- > > > From: John Drake [mailto:jdrake@calient.net] > > > Sent: Tuesday, May 13, 2003 5:36 PM > > > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > Lyndon, > > > > > > I think it is out of scope. The only requirement is that a > > > group of one or > > > more nodes running a proprietary control plane (e.g., OSRP) > > > must appear to > > > be one or more GMPLS nodes, and this is a requirement on > the vendor > > > implementing the proprietary control plane. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > > > Sent: Tuesday, May 13, 2003 2:03 PM > > > > To: 'Adrian Farrel'; Jonathan Sadler > > > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > > > Subject: RE: ASON reqts > > > > > > > > > > > > Hi Folks, > > > > > > > > I think one aspect that may not come out clearly in the draft > > > > is that ASON defines a concept of "control domains" (which is > > > > included in the terminology section of the draft) and in the > > > > amendment goes on to say that the structure and protocols used > > > > in each domain may be different (e.g., centralized control in > > > > one domain and distributed in another, RSVP in one and non-RSVP > > > > in another). > > > > > > > > I suggested that this be added to the draft, but we did not > > > > get agreement on this before we decided to send it out, perhaps > > > > because it was considered to be out of scope (?). > > > > > > > > Cheers, > > > > > > > > Lyndon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 14:05:40 +0000 Message-ID: <3EC24CB5.345B8F21@lucent.com> Date: Wed, 14 May 2003 08:03:33 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: "Wijnen, Bert (Bert)" , Bart.Rousseau@alcatel.be, ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah, I am a little confused here: We have two versions of the protocol: - Base GMPLS, developed to the requirements for controlling TDM, WDM layers that are used below the packet layer(s) in IP networks. - GMPLS plus ASON extensions, developed to also address requirements of general (not necessarily IP) transport networks. What I think you are suggesting is to address how these versions of the protocol interwork. The primary case that I can envision is the following: - IP subnetworks using base GMPLS, interconnected across generic transport networks using ASON extensions. With the IP subnetworks on the edge and the generic transport in the middle, I think there is no problem with the current protocols. But what you seem to suggest is the following: - Subnetworks using ASON extensions interconnected across a core using only base GMPLS. This case seems a little farfetched - that you would interconnect subnetworks that support a combination of circuit and packet traffic across a base GMPLS only (non-circuit traffic aware?) core. Lets make sure this is a real network configuration before we undertake an effort to change the protocols to support it. Regards, Steve "Brungard, Deborah A, ALABS" wrote: > > Hi Bert, > > Can you provide clarification on your email? > > - the January ASON email exchange and the previous ITU-T liaisons clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two ason drafts submitted are to initiate this work. > - majority of the email supports the reqs draft becoming a WG document. And hopefully, those concerned will also support as WG document based on the understanding a WG doc is a work in progress as posted by one email: > > There are a few issues that I don't quite understand and/or need > > clarification on, but the current vote is WG acceptance, not last-call. > > I have no issues with it that would keep it out from the WG. > > Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. This draft addresses a totally different application/solution than G7713.2. The rsvp-te-ason draft covers the necessary extensions to RFC-3473 to support ASON for a GMPLS network. The difference of this draft and G7713.2 is that this draft is backward and forward compatible for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol Controller (I-PC)) do not need to be updated. G7713.2 is an E-NNI which is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not provide call and connection functional separation because it was not based on use with an RFC-3473 network. Eve's mail clarifies this regarding the domain definitions. If the draft is confusing in this regard, we can work on the wording. > > The draft is on extending RFC-3473 to support ASON. If IETF does not extend RFC-3473, then GMPLS will not support ASON. This work is totally independent of the existence of G7713.2. As we discuss the draft, we can clarify if this is confusing. > > Deborah > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 13, 2003 10:38 AM > To: Bart.Rousseau@alcatel.be > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > AD-hat on. > > Bart writes: > > > > > > Stephen, > > > > I think the point was rather to go back to > > just a single GMPLS spec instead of two (let alone three) variants... > > > If that is the case, and if we want to do that in IETF CCAMP > (not sure it is part of the current CCAMP charter), > then it seems to me that we (CCAMP) should excercise these steps: > > - send some liason to ITU-T SG 15 to explain that we found that > there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard > - that we think that this is NOT goodness, and that we regret that > we did send the ASON people away a few years back and did not > closely follow their work in ITU > - that we now believe that we should have worked better together, > - that we would like to explore ways to try and mrege the two > solution back into one common solution > > And then await the response and hope ITU will agree and then see > how the work can be organized. > > > > > Bart > > > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 13:59:27 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143E8@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'John Drake'" , "Varma, Eve L (Eve)" , "'Ong, Lyndon'" , "'Adrian Farrel'" , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 09:47:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Then the purpose of the reqts. draft is not explaining ITU-T requirements for ASON in an IETF friendly way. Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 14, 2003 9:42 AM To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Eve, Let me try again. We are talking about the support of ASON in GMPLS networks, and we are trying to identify the ASON requirements on GMPLS signalling (RSVP-TE). By definition, the E-NNI/I-NNI in a GMPLS network will be RSVP-TE (with IP addressing). If the signalling protocol within a domain is also RSVP-TE then the only thing a domain boundary node will do is modify the RSVP signalling messages subject to local policy. If the signalling protocol within a domain is not RSVP-TE, then a domain boundary node for such a domain will have to build an interworking function between its signalling protocol and RSVP-TE. This is not within the scope of this work. Thanks, John > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Wednesday, May 14, 2003 5:27 AM > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Hi, > > I strongly disagree. The concept of control domains is one of the > key elements of G.8080 Am. 1, and support for such is part of the > requirements. This makes no statement re proprietary protocols. > > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Tuesday, May 13, 2003 5:36 PM > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Lyndon, > > I think it is out of scope. The only requirement is that a > group of one or > more nodes running a proprietary control plane (e.g., OSRP) > must appear to > be one or more GMPLS nodes, and this is a requirement on the vendor > implementing the proprietary control plane. > > Thanks, > > John > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > Sent: Tuesday, May 13, 2003 2:03 PM > > To: 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > Subject: RE: ASON reqts > > > > > > Hi Folks, > > > > I think one aspect that may not come out clearly in the draft > > is that ASON defines a concept of "control domains" (which is > > included in the terminology section of the draft) and in the > > amendment goes on to say that the structure and protocols used > > in each domain may be different (e.g., centralized control in > > one domain and distributed in another, RSVP in one and non-RSVP > > in another). > > > > I suggested that this be added to the draft, but we did not > > get agreement on this before we decided to send it out, perhaps > > because it was considered to be out of scope (?). > > > > Cheers, > > > > Lyndon > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 13:59:22 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143E9@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'John Drake'" , "Varma, Eve L (Eve)" , "'Ong, Lyndon'" , "'Adrian Farrel'" , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 09:58:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Please see Steve's email. Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Wednesday, May 14, 2003 9:56 AM To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Eve, I am having trouble parsing your e-mail. I thought my previous e-mail was stating what was, to use Yakov's phrase, "obvious to the informed reader". Thanks, John > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Wednesday, May 14, 2003 6:47 AM > To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel'; > Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Hi, > > Then the purpose of the reqts. draft is not explaining ITU-T > requirements for > ASON in an IETF friendly way. > > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, May 14, 2003 9:42 AM > To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan > Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Eve, > > Let me try again. We are talking about the support of ASON in GMPLS > networks, and > we are trying to identify the ASON requirements on GMPLS signalling > (RSVP-TE). By > definition, the E-NNI/I-NNI in a GMPLS network will be > RSVP-TE (with IP > addressing). > If the signalling protocol within a domain is also RSVP-TE > then the only > thing a > domain boundary node will do is modify the RSVP signalling > messages subject > to local > policy. > > If the signalling protocol within a domain is not RSVP-TE, > then a domain > boundary > node for such a domain will have to build an interworking > function between > its > signalling protocol and RSVP-TE. This is not within the > scope of this work. > > Thanks, > > John > > > > -----Original Message----- > > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > > Sent: Wednesday, May 14, 2003 5:27 AM > > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Hi, > > > > I strongly disagree. The concept of control domains is one of the > > key elements of G.8080 Am. 1, and support for such is part of the > > requirements. This makes no statement re proprietary protocols. > > > > Eve > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Tuesday, May 13, 2003 5:36 PM > > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Lyndon, > > > > I think it is out of scope. The only requirement is that a > > group of one or > > more nodes running a proprietary control plane (e.g., OSRP) > > must appear to > > be one or more GMPLS nodes, and this is a requirement on the vendor > > implementing the proprietary control plane. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > > Sent: Tuesday, May 13, 2003 2:03 PM > > > To: 'Adrian Farrel'; Jonathan Sadler > > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > > Subject: RE: ASON reqts > > > > > > > > > Hi Folks, > > > > > > I think one aspect that may not come out clearly in the draft > > > is that ASON defines a concept of "control domains" (which is > > > included in the terminology section of the draft) and in the > > > amendment goes on to say that the structure and protocols used > > > in each domain may be different (e.g., centralized control in > > > one domain and distributed in another, RSVP in one and non-RSVP > > > in another). > > > > > > I suggested that this be added to the draft, but we did not > > > get agreement on this before we decided to send it out, perhaps > > > because it was considered to be out of scope (?). > > > > > > Cheers, > > > > > > Lyndon > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 13:56:58 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97257A@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 06:56:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eve, I am having trouble parsing your e-mail. I thought my previous e-mail was stating what was, to use Yakov's phrase, "obvious to the informed reader". Thanks, John > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Wednesday, May 14, 2003 6:47 AM > To: John Drake; Varma, Eve L (Eve); 'Ong, Lyndon'; 'Adrian Farrel'; > Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Hi, > > Then the purpose of the reqts. draft is not explaining ITU-T > requirements for > ASON in an IETF friendly way. > > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, May 14, 2003 9:42 AM > To: 'Varma, Eve L (Eve)'; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan > Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Eve, > > Let me try again. We are talking about the support of ASON in GMPLS > networks, and > we are trying to identify the ASON requirements on GMPLS signalling > (RSVP-TE). By > definition, the E-NNI/I-NNI in a GMPLS network will be > RSVP-TE (with IP > addressing). > If the signalling protocol within a domain is also RSVP-TE > then the only > thing a > domain boundary node will do is modify the RSVP signalling > messages subject > to local > policy. > > If the signalling protocol within a domain is not RSVP-TE, > then a domain > boundary > node for such a domain will have to build an interworking > function between > its > signalling protocol and RSVP-TE. This is not within the > scope of this work. > > Thanks, > > John > > > > -----Original Message----- > > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > > Sent: Wednesday, May 14, 2003 5:27 AM > > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Hi, > > > > I strongly disagree. The concept of control domains is one of the > > key elements of G.8080 Am. 1, and support for such is part of the > > requirements. This makes no statement re proprietary protocols. > > > > Eve > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Tuesday, May 13, 2003 5:36 PM > > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Lyndon, > > > > I think it is out of scope. The only requirement is that a > > group of one or > > more nodes running a proprietary control plane (e.g., OSRP) > > must appear to > > be one or more GMPLS nodes, and this is a requirement on the vendor > > implementing the proprietary control plane. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > > Sent: Tuesday, May 13, 2003 2:03 PM > > > To: 'Adrian Farrel'; Jonathan Sadler > > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > > Subject: RE: ASON reqts > > > > > > > > > Hi Folks, > > > > > > I think one aspect that may not come out clearly in the draft > > > is that ASON defines a concept of "control domains" (which is > > > included in the terminology section of the draft) and in the > > > amendment goes on to say that the structure and protocols used > > > in each domain may be different (e.g., centralized control in > > > one domain and distributed in another, RSVP in one and non-RSVP > > > in another). > > > > > > I suggested that this be added to the draft, but we did not > > > get agreement on this before we decided to send it out, perhaps > > > because it was considered to be out of scope (?). > > > > > > Cheers, > > > > > > Lyndon > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 13:49:45 +0000 Message-ID: <3EC2495B.D255A06C@lucent.com> Date: Wed, 14 May 2003 07:49:15 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" CC: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I have a growing sense of unease that we could be headed for trouble here because, among those who seem to support that this becomes a WG document, there seem to be (among those who indicate a reason) a wide variety of different motivations about WHY this should be a WG document and what the posters expect will happen as a result. Perhaps more helpful than just a Yes/No preference, it would be more helpful to characterize the reasons so that, if this becomes a WG document, we know we have a consensus on why we are doing this and what we are trying to accomplish. I think I have detected the following motivations from different posts in the thread: 1. Those who don't want this to be a WG document (we are done with this version of the specifications, lets get some experience with them before considering any further change or evolution). 2. Those who think this should be a WG document so that ASON extensions currently standardized in ITU-T will get standards track status in IETF (no intent to change the protocol, but document the superset in one place so that we don't get so many GMPLS implementations that don't support the ASON extensions). 3. Those who think there is nothing wrong with the ITU-T extensions to meet the ASON requirements, but believe that RFC 3474 didn't translate G.7713.2 properly and this draft is a first step to fixing RFC 3474. 4. Those who think that even the ITU-T extensions don't meet the ASON requirements, so IETF should now take it over and do it better starting with this draft. 5. Those who think that ITU-T didn't get the requirements right, so we need to look at everything from scratch. There may be other motivations which I haven't detected or characterized, but these seem to be the main camps. So I don't think it is enough to just count how many say it should be a WG document. I think that those in camp #2 above might be pretty upset if the result of making this a WG document turns out to be a rototilling of the protocol driven by those in camps #4 and #5. We will have a much smoother time if we agree on why we are doing this and what we are trying to accomplish as a result. Once we settle on which of 1-5 we are trying to accomplish: - If it is 1, 2, or 3, we can handle in IETF. - If it is 4 or 5, we had better send a liaison to ITU-T. Please let me know if I missed any proposed purposes for this draft. Otherwise, for those of you who support this being a WG draft, I think it might be helpful if you would indicate which of (2-5) characterizes why you support this so we can make sure we are on the same page as to what we are trying to accomplish. Regards, Steve Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 13:43:30 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972579@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 06:42:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eve, Let me try again. We are talking about the support of ASON in GMPLS networks, and we are trying to identify the ASON requirements on GMPLS signalling (RSVP-TE). By definition, the E-NNI/I-NNI in a GMPLS network will be RSVP-TE (with IP addressing). If the signalling protocol within a domain is also RSVP-TE then the only thing a domain boundary node will do is modify the RSVP signalling messages subject to local policy. If the signalling protocol within a domain is not RSVP-TE, then a domain boundary node for such a domain will have to build an interworking function between its signalling protocol and RSVP-TE. This is not within the scope of this work. Thanks, John > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Wednesday, May 14, 2003 5:27 AM > To: John Drake; 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Hi, > > I strongly disagree. The concept of control domains is one of the > key elements of G.8080 Am. 1, and support for such is part of the > requirements. This makes no statement re proprietary protocols. > > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Tuesday, May 13, 2003 5:36 PM > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Lyndon, > > I think it is out of scope. The only requirement is that a > group of one or > more nodes running a proprietary control plane (e.g., OSRP) > must appear to > be one or more GMPLS nodes, and this is a requirement on the vendor > implementing the proprietary control plane. > > Thanks, > > John > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > Sent: Tuesday, May 13, 2003 2:03 PM > > To: 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > Subject: RE: ASON reqts > > > > > > Hi Folks, > > > > I think one aspect that may not come out clearly in the draft > > is that ASON defines a concept of "control domains" (which is > > included in the terminology section of the draft) and in the > > amendment goes on to say that the structure and protocols used > > in each domain may be different (e.g., centralized control in > > one domain and distributed in another, RSVP in one and non-RSVP > > in another). > > > > I suggested that this be added to the draft, but we did not > > get agreement on this before we decided to send it out, perhaps > > because it was considered to be out of scope (?). > > > > Cheers, > > > > Lyndon > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 12:29:43 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143E2@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'John Drake'" , "'Ong, Lyndon'" , "'Adrian Farrel'" , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Wed, 14 May 2003 08:27:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I strongly disagree. The concept of control domains is one of the key elements of G.8080 Am. 1, and support for such is part of the requirements. This makes no statement re proprietary protocols. Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, May 13, 2003 5:36 PM To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Lyndon, I think it is out of scope. The only requirement is that a group of one or more nodes running a proprietary control plane (e.g., OSRP) must appear to be one or more GMPLS nodes, and this is a requirement on the vendor implementing the proprietary control plane. Thanks, John > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Tuesday, May 13, 2003 2:03 PM > To: 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org; Ong, Lyndon > Subject: RE: ASON reqts > > > Hi Folks, > > I think one aspect that may not come out clearly in the draft > is that ASON defines a concept of "control domains" (which is > included in the terminology section of the draft) and in the > amendment goes on to say that the structure and protocols used > in each domain may be different (e.g., centralized control in > one domain and distributed in another, RSVP in one and non-RSVP > in another). > > I suggested that this be added to the draft, but we did not > get agreement on this before we decided to send it out, perhaps > because it was considered to be out of scope (?). > > Cheers, > > Lyndon > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 06:36:04 +0000 Message-ID: <3EC1E4F9.7010107@alcatel.be> Date: Wed, 14 May 2003 08:40:57 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Lou Berger Cc: Kireeti Kompella , "Brungard, Deborah A, ALABS" , ccamp@ops.ietf.org, Bert Wijnen Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed "I have read this document and it is ready to be a CCAMP WG doc" Lou Berger wrote: > > > At 12:39 PM 5/13/2003, Brungard, Deborah A, ALABS wrote: > >> - majority of the email supports the reqs draft becoming a WG >> document. And hopefully, those concerned will also support as WG >> document based on the understanding a WG doc is a work in progress as >> posted by one email: > > > I think Deborah has a good point here. Yes, there are some point > discussions and proposed additions to the draft (it is a rev -00 after > all!) but it seems the general tenor of the conversation is that this > document is a good foundation for the WG to start with. > > Oh WG chair(s), > Can you give us your read of the "humm" level of the list? Can > we "officially" move on from the question of draft's filename to how it > should be modified? > > Thanks, > Lou > > PS "I have read this document and it is ready to be a CCAMP WG doc" > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 May 2003 01:38:45 +0000 Message-ID: <3EC19DD7.80003@acm.org> Date: Tue, 13 May 2003 21:37:27 -0400 From: Matt Squire Reply-To: mattsquire@acm.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 MIME-Version: 1.0 To: John Drake CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ditto the "I have read the document and it is ready to be a CCAMP doc". Either that or we break out a couple dozen eggs and continue to throw them between the ITU and the IETF. I can go either way. - Matt John Drake wrote: > "I have read this document and it is ready to be a CCAMP WG doc" > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: Monday, May 12, 2003 8:25 AM >>To: ccamp@ops.ietf.org >>Subject: Re: ASON reqts >> >> >>I'd like to get a reading on whether this doc is ready to be a >>CCAMP WG document. Please respond (preferably publicly) with one of: >> - "I have read this document and it is ready to be a CCAMP WG doc" OR >> - "I have read this document, and it isn't ready to be a CCAMP doc". >> Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 23:50:54 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500C1@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "Ong, Lyndon" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 16:53:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, The smart vendor will do what they know works, first and foremost ;o) But we're straying off topic... Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, May 13, 2003 2:59 PM To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts JD: But the smart vendor does it in such a way that it is interoperable Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 23:46:01 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Tue, 13 May 2003 18:44:51 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A7104@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMZXocFalZRLg5YTganI9Vrpa8LXAAN+y8g From: "Ash, Gerald R (Jerry), ALABS" To: "Wijnen, Bert (Bert)" Cc: "Ash, Gerald R (Jerry), ALABS" , Bert, I think much of this discussion between ITU-T and IETF, and what you are = proposing, has already occurred, some time ago: dimitri> as of today we have two flavors "ASON/GMPLS" and "GMPLS" steve> Can we please avoid creating a third variant of the protocol? bart> I think the point was rather to go back to just a single bart> GMPLS spec instead of two (let alone three) variants... bert> If that is the case, and if we want to do that in IETF CCAMP=20 bert> (not sure it is part of the current CCAMP charter), bert> then it seems to me that we (CCAMP) should exercise these steps: bert>=20 bert> - send some liaison to ITU-T SG 15 to explain that we found that bert> there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard bert> - that we think that this is NOT goodness, and that we regret that bert> we did send the ASON people away a few years back and did not bert> closely follow their work in ITU bert> - that we now believe that we should have worked better together, bert> - that we would like to explore ways to try and merge the two bert> solution back into one common solution bert>=20 bert> And then await the response and hope ITU will agree and then see bert> how the work can be organized. Recall that we had extended discussions last January regarding the = ASON-GMPLS issues, wherein many of the same points were made, and = conclusions reached: 1. Brief History of ASON-GMPLS extensions: In February 2002, ITU-T sent IETF/CCAMP a liaison statement identifying = the 'gaps' between the ITU-T ASON requirements (sent 7 months earlier) = and GMPLS protocols, which included: a. call & connection separation,=20 b. additional error codes/values,=20 c. restart mechanisms, d. support of crankback capability. The liaison was presented to IETF/CCAMP at IETF-53/Minneapolis (March = 2002), and requested assistance in closing the gaps and invited input = from IETF. IETF/CCAMP proposed to 'close the gaps' and CCAMP charter = extensions to address same were suggested at IETF-54/Yokohama, but were = not made. This caused frustration within ITU-T in not getting attention = to the needed ASON requirements in IETF/CCAMP. =20 ITU decided to extend GMPLS protocols themselves, leading to the present = interoperability concerns with ITU-GMPLS and GMPLS. At the April/May = 2002 ITU-T meeting, draft Recommendations were put forward to close the = gaps, namely, draft Recommendations G.7713.2 (RSVP-TE ITU-GMPLS = extensions) and G.7713.3 (CR-LDP ITU-GMPLS extensions). =20 ITU-T sent a liaison in May 2002 to ask for comments on the draft = Recommendations, and to request alignment with GMPLS, as follows: = "Please consider including the proposed solutions provided in G.7713.2 = and G.7713.3 to update the existing GMPLS signaling work in support of = ASON requirements." This request shows that the intent was to have = extensions made by CCAMP to GMPLS protocols based on the ASON = requirements and thus close the 'gaps'. Steve Trowbridge noted that "After some private communication with the = Area directors, we received some advice that one tool that might be used = to finally get the IANA codepoint assignment complete would be to = publish what we were doing in ITU-T as informational RFCs. This is the = stage we are at today." In summary, ITU-T kept the IETF informed of its work, invited help to = address the ITU-T ASON requirements, invited alignment of the base GMPLS = protocols, but there was no response or interest from the IETF to do = this. The unfortunate outcome of this is to be standardizing 2 versions = of GMPLS: ITU-GMPLS and GMPLS. 2. Several concerns were raised to this outcome, such as: a. "I'm concerned with non-IETF groups like ITU-T deciding to develop = their own incompatible extensions. Groups like these should not be = extending IETF protocols without consulting with the relevant IETF = working groups. Otherwise we end up with extensions that duplicate = existing IETF functionality, don't coexist gracefully, and/or break = interoperability." b. "Which spec does a vendor implement and an operator use, given = interoperability needs, etc.? It would be analogous to the IETF = specifying their version of G.709." c. "The ITU has developed protocol extensions for GMPLS, something = outside the charter of the ITU." 3. A resolution to the problem was proposed and got some agreement: "It would be worthwhile to package the needed ASON extensions into a = proposed GMPLS upgrade and presented to CCAMP as such: bring the = requirements to CCAMP as a requirements draft, thrash them out, and get = the necessary extensions adopted in CCAMP." There were many who agreed with this approach, that is, to extend GMPLS = (as originally proposed by the ITU-T) to meet the ITU-T ASON = requirements. Several of us joined the current effort with the intent = that this is the direction we were taking. IMO, you have proposed something that is quite consistent with all of = the above. However, much of what you propose has already transpired = (perhaps 'unofficially') between the IETF and ITU-T. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 22:14:37 +0000 Message-Id: <4.3.2.7.2.20030513171025.03d619c8@mo-ex1> Date: Tue, 13 May 2003 18:13:10 -0400 To: Kireeti Kompella From: Lou Berger Subject: RE: ASON reqts Cc: "Brungard, Deborah A, ALABS" , , Bert Wijnen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:39 PM 5/13/2003, Brungard, Deborah A, ALABS wrote: >- majority of the email supports the reqs draft becoming a WG document. >And hopefully, those concerned will also support as WG document based on >the understanding a WG doc is a work in progress as posted by one email: I think Deborah has a good point here. Yes, there are some point discussions and proposed additions to the draft (it is a rev -00 after all!) but it seems the general tenor of the conversation is that this document is a good foundation for the WG to start with. Oh WG chair(s), Can you give us your read of the "humm" level of the list? Can we "officially" move on from the question of draft's filename to how it should be modified? Thanks, Lou PS "I have read this document and it is ready to be a CCAMP WG doc" Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:59:51 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972572@nimbus> From: John Drake To: "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:59:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Tuesday, May 13, 2003 2:54 PM > To: John Drake; Ong, Lyndon; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Hi John, > > I think it's not just an issue of non-RSVP domains, but > also how to interwork legacy systems that are centrally > controlled, and maybe variants in-between. It's reasonable > to see if extensions or changes are needed in the protocols > to support this, given that carriers are not building > networks from scratch anymore. JD: You can always put a GMPLS front end on a centralized NMS system without changing GMPLS in any way > > BTW, in order to deploy distributed control on large > networks today you necessarily have to go beyond the > standards in order to provide the set of functions a > carrier needs. That's just that state of things at this > point in time. JD: But the smart vendor does it in such a way that it is interoperable > > Cheers, > > Lyndon > > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Tuesday, May 13, 2003 2:36 PM > To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Lyndon, > > I think it is out of scope. The only requirement is that a > group of one or > more nodes running a proprietary control plane (e.g., OSRP) > must appear to > be one or more GMPLS nodes, and this is a requirement on the vendor > implementing the proprietary control plane. > > Thanks, > > John > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > Sent: Tuesday, May 13, 2003 2:03 PM > > To: 'Adrian Farrel'; Jonathan Sadler > > Cc: ccamp@ops.ietf.org; Ong, Lyndon > > Subject: RE: ASON reqts > > > > > > Hi Folks, > > > > I think one aspect that may not come out clearly in the draft > > is that ASON defines a concept of "control domains" (which is > > included in the terminology section of the draft) and in the > > amendment goes on to say that the structure and protocols used > > in each domain may be different (e.g., centralized control in > > one domain and distributed in another, RSVP in one and non-RSVP > > in another). > > > > I suggested that this be added to the draft, but we did not > > get agreement on this before we decided to send it out, perhaps > > because it was considered to be out of scope (?). > > > > Cheers, > > > > Lyndon > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:51:27 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500BF@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "Ong, Lyndon" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:54:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, I think it's not just an issue of non-RSVP domains, but also how to interwork legacy systems that are centrally controlled, and maybe variants in-between. It's reasonable to see if extensions or changes are needed in the protocols to support this, given that carriers are not building networks from scratch anymore. BTW, in order to deploy distributed control on large networks today you necessarily have to go beyond the standards in order to provide the set of functions a carrier needs. That's just that state of things at this point in time. Cheers, Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, May 13, 2003 2:36 PM To: 'Ong, Lyndon'; 'Adrian Farrel'; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Lyndon, I think it is out of scope. The only requirement is that a group of one or more nodes running a proprietary control plane (e.g., OSRP) must appear to be one or more GMPLS nodes, and this is a requirement on the vendor implementing the proprietary control plane. Thanks, John > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Tuesday, May 13, 2003 2:03 PM > To: 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org; Ong, Lyndon > Subject: RE: ASON reqts > > > Hi Folks, > > I think one aspect that may not come out clearly in the draft > is that ASON defines a concept of "control domains" (which is > included in the terminology section of the draft) and in the > amendment goes on to say that the structure and protocols used > in each domain may be different (e.g., centralized control in > one domain and distributed in another, RSVP in one and non-RSVP > in another). > > I suggested that this be added to the draft, but we did not > get agreement on this before we decided to send it out, perhaps > because it was considered to be out of scope (?). > > Cheers, > > Lyndon > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:45:10 +0000 From: "jvluciani" To: "'Osama Aboul-Magd'" , "'Adrian Farrel'" , "'Jonathan Sadler'" Cc: Subject: RE: ASON reqts Date: Tue, 13 May 2003 17:44:39 -0400 Message-ID: <005a01c31998$dc198810$3a14000a@DD22NQ21> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C31977.5507E810" This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C31977.5507E810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Actually this is not factual. I emailed Osama several times to ask for status and to have the draft updated and there was no reply. Whether there is interest outside of the authors is less clear, however it was most certainly not dropped without several attempts to urge progress onward. IPO is shutting down. The draft would more likely be appropriate as an individual contribution draft at this point. --Jim -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Osama Aboul-Magd Sent: Tuesday, May 13, 2003 5:06 PM To: Adrian Farrel; Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts The IPO-ASON draft was dropped unceremoniously from the IPO WG drafts some time ago. It probably is a victim to the current state of the IPO WG and the level of interest in its activities. The fact that the draft expired doesn't explain why it was removed from the WG drafts. Other expired drafts are still sitting their. If there is interest, a new revision could be worked out to include the latest ASON related work as per the ITU meeting in January 2003. However I don't think IPO is the right place for it. Regards; >Ah, OK. No new references. Just a query about whether IPO-ASON is ood. >It may be ood but it also provides relevant IETF b/g. >So it stays for the moment and either it gets republished, or the ref gets >dropped later. >Thanks, >Adrian ------=_NextPart_000_005B_01C31977.5507E810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: ASON reqts

Actually this is not factual.  = I emailed Osama several times to ask for status and to have the draft = updated and there was no reply.  Whether there is interest outside of the = authors is less clear, however it was most certainly not dropped without several = attempts to urge progress onward.

 

IPO is shutting down.  The = draft would more likely be appropriate as an individual contribution draft at = this point.

 

--Jim

 

-----Original = Message-----
From: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Osama Aboul-Magd
Sent: Tuesday, May 13, = 2003 5:06 PM
To: Adrian Farrel; = Jonathan Sadler
Cc: = ccamp@ops.ietf.org
Subject: RE: ASON = reqts

 



The IPO-ASON draft was dropped = unceremoniously from the IPO WG drafts some time ago. It probably is a victim to the current = state of the IPO WG and the level of interest in its activities. The fact that = the draft expired doesn't explain why it was removed from the WG drafts. = Other expired drafts are still sitting their.

If there is interest, a new revision could be = worked out to include the latest ASON related work as per the ITU meeting in = January 2003. However I don't think IPO is the right place for it. =

Regards;

 

>Ah, OK. No new references. Just a query = about whether IPO-ASON is ood.
>It may be ood but it = also provides relevant IETF b/g.
>So it stays for the = moment and either it gets republished, or the ref gets
>dropped = later.

 

>Thanks,
>Adrian =

------=_NextPart_000_005B_01C31977.5507E810-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:36:36 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972570@nimbus> From: John Drake To: "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:35:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lyndon, I think it is out of scope. The only requirement is that a group of one or more nodes running a proprietary control plane (e.g., OSRP) must appear to be one or more GMPLS nodes, and this is a requirement on the vendor implementing the proprietary control plane. Thanks, John > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Tuesday, May 13, 2003 2:03 PM > To: 'Adrian Farrel'; Jonathan Sadler > Cc: ccamp@ops.ietf.org; Ong, Lyndon > Subject: RE: ASON reqts > > > Hi Folks, > > I think one aspect that may not come out clearly in the draft > is that ASON defines a concept of "control domains" (which is > included in the terminology section of the draft) and in the > amendment goes on to say that the structure and protocols used > in each domain may be different (e.g., centralized control in > one domain and distributed in another, RSVP in one and non-RSVP > in another). > > I suggested that this be added to the draft, but we did not > get agreement on this before we decided to send it out, perhaps > because it was considered to be out of scope (?). > > Cheers, > > Lyndon > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:06:54 +0000 Message-ID: <710197BD5AF9D4119E4400508BCFA136078B9D79@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: Adrian Farrel , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 17:05:32 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31993.63E8917E" 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_01C31993.63E8917E Content-Type: text/plain The IPO-ASON draft was dropped unceremoniously from the IPO WG drafts some time ago. It probably is a victim to the current state of the IPO WG and the level of interest in its activities. The fact that the draft expired doesn't explain why it was removed from the WG drafts. Other expired drafts are still sitting their. If there is interest, a new revision could be worked out to include the latest ASON related work as per the ITU meeting in January 2003. However I don't think IPO is the right place for it. Regards; >Ah, OK. No new references. Just a query about whether IPO-ASON is ood. >It may be ood but it also provides relevant IETF b/g. >So it stays for the moment and either it gets republished, or the ref gets >dropped later. >Thanks, >Adrian ------_=_NextPart_001_01C31993.63E8917E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ASON reqts


The IPO-ASON draft was dropped unceremoniously from = the IPO WG drafts some time ago. It probably is a victim to the current = state of the IPO WG and the level of interest in its activities. The = fact that the draft expired doesn't explain why it was removed from the = WG drafts. Other expired drafts are still sitting their.

If there is interest, a new revision could be worked = out to include the latest ASON related work as per the ITU meeting in = January 2003. However I don't think IPO is the right place for it. =

Regards;


>Ah, OK. No new references. Just a query about = whether IPO-ASON is ood.
>It may be ood but it also provides relevant IETF = b/g.
>So it stays for the moment and either it gets = republished, or the ref gets
>dropped later.


>Thanks,
>Adrian

------_=_NextPart_001_01C31993.63E8917E-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:04:14 +0000 Message-ID: <3EC1A331.C39E8A77@tellabs.com> Date: Tue, 13 May 2003 21:00:17 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: Adrian Farrel CC: "Brungard, Deborah A, ALABS" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian - Some more information on the issues raised previously, and a couple more missing requirements... Jonathan Sadler Adrian Farrel wrote: > Jonathan, > > > Likewise, dropping > > the items handled in RFC 3474 would requires an active decision to > > be made by the authors. The document should include this reasoning. > > Perhaps you have an example or two of things in RFC 3474 that are dropped by > ASON-REQ but are ASON architectural requirements? In addition to the two in my previous email, here are some more: - Explicit support for connection partitioning in different administrative domains. (G.8080 Amd.1) - Use of transport plane names instead of DCN addresses when refering to transport plane resources. (G.8080 Amd.1) Again, I'm interested in why these and the previously mentioned two items which were covered in RFC 3474 have not been included in the ASON-REQ draft. > > For those unfamiliar with some of the differences, a cursorary review > > of the G.7713 reveals: > > - Discussion of required behavior at E-NNI and UNI reference points > > I should say that this is covered in the Problem Statement in section 3 > > The ASON control plane specification is meant to be applicable to > different transport technologies (e.g., SDH/SONET, OTN) in various > networking environments (e.g., inter-carrier, intra-carrier). Also, > ASON model distinguishes reference points (representing points of > protocol information exchange) defined (1) between an administrative > domain and a user (2) between administrative domains and (3) between > areas of the same administrative domain and when needed between > control components (or simply controllers) within areas. A full > description of the ASON terms and relationship between ASON model > and GMPLS protocol suite may be found in [IPO-ASON]. > > Further in section 4 > > Note: support of the above functions is independent of any user-to- > network interface and is therefore not constrained nor restricted by > its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713]) However, the text above is not a discussion of required behavior -- its just an acknowledgement that the reference points exist. For example, G.8080 defines separation of the address spaces used by the Network and used by Users. RFC 3474 provides for this separation in defining new UNI and E-NNI Address C-types. The requirements document is remarkably silent on this issue. > > - Support for complete Call/Connection separation, including > > 0-connection calls > > Hmmm? > Are you saying that ASON-REQ doesn't include a discussion of complete > call/connection separation? > 4.2 seems to have that covered. Sorry, I wasn't completely clear. G.8080 allows for 0-connection calls -- Section 4.2 of the proposed document does not deal with this. RFC 3474 provides a mechanism that allows nodes that have implemented the CALL_OPS object to handle this case. ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 21:00:20 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500BD@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org, "Ong, Lyndon" Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:02:59 -0700 MIME-Version: 1.0 Content-Type: text/plain Hi Folks, I think one aspect that may not come out clearly in the draft is that ASON defines a concept of "control domains" (which is included in the terminology section of the draft) and in the amendment goes on to say that the structure and protocols used in each domain may be different (e.g., centralized control in one domain and distributed in another, RSVP in one and non-RSVP in another). I suggested that this be added to the draft, but we did not get agreement on this before we decided to send it out, perhaps because it was considered to be out of scope (?). Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:37:13 +0000 Message-ID: <015501c3198f$5748c370$681810ac@movaz.com> From: "Adrian Farrel" To: "Jonathan Sadler" , "Brungard, Deborah A, ALABS" Cc: Subject: Re: ASON reqts Date: Tue, 13 May 2003 16:36:32 -0400 Jonathan, > The authors should provide them, along with their reasoning why. ??? > Stating compliance with the requirements docs requires being > familiar with the material in those documents. Yes, and...? > Likewise, dropping > the items handled in RFC 3474 would requires an active decision to > be made by the authors. The document should include this reasoning. Perhaps you have an example or two of things in RFC 3474 that are dropped by ASON-REQ but are ASON architectural requirements? > For those unfamiliar with some of the differences, a cursorary review > of the G.7713 reveals: > - Discussion of required behavior at E-NNI and UNI reference points I should say that this is covered in the Problem Statement in section 3 The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments (e.g., inter-carrier, intra-carrier). Also, ASON model distinguishes reference points (representing points of protocol information exchange) defined (1) between an administrative domain and a user (2) between administrative domains and (3) between areas of the same administrative domain and when needed between control components (or simply controllers) within areas. A full description of the ASON terms and relationship between ASON model and GMPLS protocol suite may be found in [IPO-ASON]. Further in section 4 Note: support of the above functions is independent of any user-to- network interface and is therefore not constrained nor restricted by its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713]) Was there something more specific you were after? > - Support for complete Call/Connection separation, including > 0-connection calls Hmmm? Are you saying that ASON-REQ doesn't include a discussion of complete call/connection separation? 4.2 seems to have that covered. I can see how there may be benefit in adding text to clarify the separation options. Perhpas you could suggest some. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:24:08 +0000 Message-ID: <014d01c3198d$8d2262f0$681810ac@movaz.com> From: "Adrian Farrel" To: "Jonathan Sadler" Cc: Subject: Re: ASON reqts Date: Tue, 13 May 2003 16:23:44 -0400 > > > Currently, the document excludes a number of requirements specified in G.8080, > > > and G.7713 that are handled by RFC 3474. No information is provided in the > > > document or on the CCAMP list why these were dropped. > > > > Pointers please. > > There was no intention to drop any requirement so please let us know what is > > missing. > > See my previous email to Deborah, as well as G.7713, G.8080, and G.8080 Amd. 1. > > NB: All of these documents have been liaised to the IETF. The liaison statements > including the documents can be found under the CCAMP link at: > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/in dex.html Will respond to you email to Deborah separately. With regards to your comments here... This isn't an accademic guessing game - if you have specific constructive comments along the lines of "requirement xyz as specificed in dogument G.1234 section a.b.c is missing" then please say so. The authors are trying to do their best and are asking for helpful input. > > > I would also like to know why it is referencing outdated documents (ex. > > > [IPO-ASON] was published in March 2002) when more recent > > > requirements/architecture material is available. > > > > Well, there is no reason not to reference this material at this stage. Indeed, > > someone just asked for it to be referenced, I think. > > Unfortunately, the IPO-ASON draft referenced doesn't include a number of the > conceptual items developed after the consent of G.8080 in Oct. 2001. Many of these > items were added in G.8080 Amd. 1 and G.7713.2, both of which were consented in > January of 2003. > > > With regard to other material, again please provide pointers and we will happily > > read and reference is as appropriate. > > G.8080 as updated by G.8080 Amd. 1, and G.7713.2 are more up to date. Ah, OK. No new references. Just a query about whether IPO-ASON is ood. It may be ood but it also provides relevant IETF b/g. So it stays for the moment and either it gets republished, or the ref gets dropped later. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:20:17 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143DE@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Ong, Lyndon'" , "'Brungard, Deborah A, ALABS'" , "Varma, Eve L (Eve)" , John Drake , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 16:19:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, In terms of requirements, these come from G.807, G.8080 & Am. 1, and G.7713. The IPO-ASON draft elaborated on a number of these (though some of the material re domains was outdated vis-a-vis G.8080 Am. 1). As Lyndon mentioned, the ITU-T reqts. work was influenced by contributions from companies that sent representatives to the meetings, as well as from material from other standards and industry fora that was liaised to these meetings. Many of these companies sent representatives to IETF as well. Eve -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Tuesday, May 13, 2003 4:14 PM To: 'Brungard, Deborah A, ALABS'; Varma, Eve L (Eve); John Drake; Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org; Ong, Lyndon Subject: RE: ASON reqts Hi Deborah, I kind of agree and disagree... The requirements draft attempts to summarize 8080 specifically regarding its impacts on signaling, so it does not repeat 8080 but may of course not be complete. Regarding the IETF GMPLS experts, that seems a bit unfair, the ITU work was naturally influenced by who was there at the meeting; this included a number of folks who are also very active at IETF and implemented GMPLS protocols. I still think the issue that most people had with RFC 3474 was that process-wise they would rather that it had gone through the ccamp group or alternatively asked for FCFS codepoints... Cheers, Lyndon -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Tuesday, May 13, 2003 12:20 PM To: Varma, Eve L (Eve); John Drake; Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts The intention of gmpls-ason-reqs is not to repeat G8080. And it is not about G7713.2. It is to address GMPLS support of G8080. If it becomes a WG document, any/all comments are welcome. Individuals' participation will depend on company interests. We can not "require" anyone to participate. This is not a hobby for most of us;-) This email is more appropriate as a private exchange - naming of individuals severely lacks in recognition of the many who contribute in the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many years, including the birth of ASON, I wish I could say, that I was too young too remember, but I was there, actually Malcolm could say he was too young;-). And I am not the primary player for T1X1.5 work, there are no primary players, it is a committee representing companies. One could ask, why were none of the IETF GMPLS experts asked to participate in the ITU work? We are trying to progress an IETF draft on GMPLS support of ASON. I am a carrier interested in GMPLS. None of us are writing resumes. Let's progress with specific comments on the drafts. Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:15:52 +0000 Message-ID: <3EC197E0.87D232DB@tellabs.com> Date: Tue, 13 May 2003 20:12:01 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian - See inline... Jonathan Sadler Adrian Farrel wrote: > > Currently, the document excludes a number of requirements specified in G.8080, > > and G.7713 that are handled by RFC 3474. No information is provided in the > > document or on the CCAMP list why these were dropped. > > Pointers please. > There was no intention to drop any requirement so please let us know what is > missing. See my previous email to Deborah, as well as G.7713, G.8080, and G.8080 Amd. 1. NB: All of these documents have been liaised to the IETF. The liaison statements including the documents can be found under the CCAMP link at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html > > I would also like to know why it is referencing outdated documents (ex. > > [IPO-ASON] was published in March 2002) when more recent > > requirements/architecture material is available. > > Well, there is no reason not to reference this material at this stage. Indeed, > someone just asked for it to be referenced, I think. Unfortunately, the IPO-ASON draft referenced doesn't include a number of the conceptual items developed after the consent of G.8080 in Oct. 2001. Many of these items were added in G.8080 Amd. 1 and G.7713.2, both of which were consented in January of 2003. > With regard to other material, again please provide pointers and we will happily > read and reference is as appropriate. G.8080 as updated by G.8080 Amd. 1, and G.7713.2 are more up to date. ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:11:13 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500B9@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Brungard, Deborah A, ALABS'" , "Varma, Eve L (Eve)" , John Drake , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, "Ong, Lyndon" Subject: RE: ASON reqts Date: Tue, 13 May 2003 13:14:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Deborah, I kind of agree and disagree... The requirements draft attempts to summarize 8080 specifically regarding its impacts on signaling, so it does not repeat 8080 but may of course not be complete. Regarding the IETF GMPLS experts, that seems a bit unfair, the ITU work was naturally influenced by who was there at the meeting; this included a number of folks who are also very active at IETF and implemented GMPLS protocols. I still think the issue that most people had with RFC 3474 was that process-wise they would rather that it had gone through the ccamp group or alternatively asked for FCFS codepoints... Cheers, Lyndon -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Tuesday, May 13, 2003 12:20 PM To: Varma, Eve L (Eve); John Drake; Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts The intention of gmpls-ason-reqs is not to repeat G8080. And it is not about G7713.2. It is to address GMPLS support of G8080. If it becomes a WG document, any/all comments are welcome. Individuals' participation will depend on company interests. We can not "require" anyone to participate. This is not a hobby for most of us;-) This email is more appropriate as a private exchange - naming of individuals severely lacks in recognition of the many who contribute in the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many years, including the birth of ASON, I wish I could say, that I was too young too remember, but I was there, actually Malcolm could say he was too young;-). And I am not the primary player for T1X1.5 work, there are no primary players, it is a committee representing companies. One could ask, why were none of the IETF GMPLS experts asked to participate in the ITU work? We are trying to progress an IETF draft on GMPLS support of ASON. I am a carrier interested in GMPLS. None of us are writing resumes. Let's progress with specific comments on the drafts. Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:05:15 +0000 Message-ID: <3EC19453.322F97BB@tellabs.com> Date: Tue, 13 May 2003 19:56:51 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah - The authors should provide them, along with their reasoning why. Stating compliance with the requirements docs requires being familiar with the material in those documents. Likewise, dropping the items handled in RFC 3474 would requires an active decision to be made by the authors. The document should include this reasoning. For those unfamiliar with some of the differences, a cursorary review of the G.7713 reveals: - Discussion of required behavior at E-NNI and UNI reference points - Support for complete Call/Connection separation, including 0-connection calls These are documented by RFC 3474. Others can be found by looking at G.8080, and G.8080 Amd. 1. Jonathan Sadler "Brungard, Deborah A, ALABS" wrote: > Hi Jonathan, > > We need specifics- > Deborah > > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, May 13, 2003 7:57 PM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: ASON reqts > > Kireeti - > > "I have read this document, and it isn't ready to be a CCAMP doc". > > Currently, the document excludes a number of requirements specified in G.8080, > and G.7713 that are handled by RFC 3474. No information is provided in the > document or on the CCAMP list why these were dropped. > > I would also like to know why it is referencing outdated documents (ex. > [IPO-ASON] was published in March 2002) when more recent > requirements/architecture material is available. > > Jonathan Sadler > > Kireeti Kompella wrote: > > > Hi All, > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > To take things one at a time, it would be very useful to read and comment > > > on the ASON reqts draft, as this was deemed tremendously important, and > > > a rich source of misunderstanding and cross-talk; and coming to a common > > > understanding over this should help get the IETF and the ITU working > > > together. > > > > I haven't seen many comments, so the assumption is either that no > > one cares, or that folks have read it and have no issues. > > > > I'd like to get a reading on whether this doc is ready to be a > > CCAMP WG document. Please respond (preferably publicly) with one of: > > - "I have read this document and it is ready to be a CCAMP WG doc" OR > > - "I have read this document, and it isn't ready to be a CCAMP doc". > > > > Note that if there aren't enough responses, the default assumption is > > that the document is either not of interest or not ready, and in > > either case will not become a CCAMP WG doc. Note too that this doc > > is an attempt to bridge some gaps between the IETF and the ITU-T, > > and as such is fairly important. It would be useful to give an > > update on its status at the interim T1X1 meeting in June. > > > > Please get your responses in by COB Friday May 16th. > > > > Thanks, > > Kireeti. > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 20:02:45 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97256B@nimbus> From: John Drake To: 'Jonathan Sadler' Cc: 'Stephen Trowbridge' , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 13:02:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" We've been through all of this before many times. Because the call, even in complete separation mode, is established using Path/Resv, intermediate nodes that don't understand what is going on will instantiate state and allocate resources as if a connection is being established. > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, May 13, 2003 4:59 PM > To: John Drake > Cc: 'Stephen Trowbridge'; 'Wijnen, Bert (Bert)'; Kireeti Kompella; > ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > John - > > What does section 9.2 of RFC 3474 accomplish then? (For > those unaware, Sect. > 9.2 is titled "Complete Separation of Call and Connection") > > Jonathan Sadler > > John Drake wrote: > > > I think that the problem is that RFC 3474, in addition to > its technical > > issues, doesn't address all of the ASON requirements. For > example, it does > > not address full call/connection separation. So we're > following the post > > 3474 procees of documenting the ASON requirements relevant to GMPLS > > signalling in order to have a common understanding of what > problem is to be > > solved. > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Monday, May 12, 2003 2:27 PM > > > To: John Drake > > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: ASON reqts > > > > > > > > > Bert & John, > > > I think this document has nothing to do with the issue Bert > > > mentioned. This was a protocol issue, not a requirements issue. > > > A decision was made to leave the message out of 3474 with the > > > belief that: > > > - The protocol works without it; and > > > - The presence of the message violates the protocol. > > > The appropriate next step here would be a liaison back to ITU-T > > > explaining what was done and why, and if the ITU-T agrees with > > > the reasoning, they can align their protocol document (in this > > > case, G.7713.2). > > > > > > Back to Bert's original questions: > > > > > > > - is there or do we see any conflict? > > > - As Zhi said, this is not (yet) fully aligned with ITU-T > requirements > > > and should not be advanced to a WG document until it is. > > > However, before > > > we do, I think we need to understand why this is necessary > > > - see below. > > > > > > > > > > - are we duplicating some work? > > > - Almost certainly. If we take the kind of alignment with ITU-T > > > requirements that Zhi mentions as a "gate" for progressing > > > this, then > > > what is in this document that is different from G.8080 and > > > G.7713 and > > > why do we need this in place of a normative reference? > > > > > > > > > > - what is the purpose of this draft? > > > Excellent question. > > > > > > > - is it after the fact documenting of requirements? > > > If it is, why bother? Also, we already have the requirements > > > (developed > > > before the protocol) in G.8080 and G.7713. > > > > > > > > > > - is it getting ITU-T documented requirements > in RFC form? > > > This could be a reasonable goal, if this document is to be an info > > > track requirements document characterizing G.8080 and G.7713 for > > > IETF folks in the same way that RFC 3474 does for G.7713.2 and > > > RFC 3475 does for G.7713.3. But it is hard to understand > why producing > > > an IETF translation of the ITU-T question would be very > high priority > > > when we already have an IETF translation of the answer, but > > > fundamentally > > > there would be no problem if this were the objective. > > > > > > > > > > - is it extending ITU-T documented requirements? > > > I don't think so. If it is, I hope we start with a liaison rather > > > than trying to extend ITU-T requirements without talking to > > > ITU-T first. > > > > > > > > > > - is it contrdicting them? > > > This is my biggest worry. I don't think we should start > the process > > > over again and open the door that we come up with yet another > > > protocol solution to address the same requirements. Vendors are > > > already building to G.7713.2, G.7713.3 (and by extension, to > > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > > > start a new work item with an objective to develop a new protocol > > > solution to the same problem. > > > > > > > > > > - is it meant to be used as communication to ITU? > > > I haven't seen this proposed, but I think that if the goal is > > > to capture ITU-T requirements in RFC form, it would be a good > > > idea to ask ITU-T whether the proposed document accurately > > > captures their requirements. > > > > > > /Steve > > > > > > > > > John Drake wrote: > > > > > > > > Bert, > > > > > > > > I think so. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Monday, May 12, 2003 1:27 PM > > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > I know that some people had issues with the way that ITU-T > > > > > had defined the RSVP-TE extensions for ASON. In fact there > > > > > was/is a claim that it is broken. So we removed the offending > > > > > text from the RFC3474. > > > > > > > > > > The next thing we were going to do (as far as I understood it) > > > > > is to document why we (or some of us in IETF) think that the > > > > > ITU-T solution is broken, potentially with suggested fixes. > > > > > That we would send to ITU-T SG15. > > > > > > > > > > Is this the first step of that process? > > > > > > > > > > Thanks, > > > > > Bert > > > > > > > > > > > -----Original Message----- > > > > > > From: John Drake [mailto:jdrake@calient.net] > > > > > > Sent: maandag 12 mei 2003 22:24 > > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; > ccamp@ops.ietf.org > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > > > I thought that the post 3474/3475 process started with a > > > > > requirements > > > > > > document. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > > > that those 2 RFCs point to, then I wonder: > > > > > > > - is there or do we see any conflict? > > > > > > > - are we duplicating some work? > > > > > > > - what is the purpose of this draft? > > > > > > > - is it after the fact documenting of requirements? > > > > > > > - is it getting ITU-T documented requirements > in RFC form? > > > > > > > - is it extending ITU-T documented requirements? > > > > > > > - is it contrdicting them? > > > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > > > > > Thanks, > > > > > > > Bert > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > > > > > To take things one at a time, it would be > very useful to > > > > > > > > read and comment > > > > > > > > > on the ASON reqts draft, as this was deemed > tremendously > > > > > > > > important, and > > > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > > > coming to a common > > > > > > > > > understanding over this should help get the > IETF and the > > > > > > > ITU working > > > > > > > > > together. > > > > > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > > > either that no > > > > > > > > one cares, or that folks have read it and have > no issues. > > > > > > > > > > > > > > > > I'd like to get a reading on whether this doc is > > > ready to be a > > > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > > > with one of: > > > > > > > > - "I have read this document and it is ready > to be a CCAMP > > > > > > > WG doc" OR > > > > > > > > - "I have read this document, and it isn't > ready to be a > > > > > > > CCAMP doc". > > > > > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > > > assumption is > > > > > > > > that the document is either not of interest or not > > > ready, and in > > > > > > > > either case will not become a CCAMP WG doc. Note too > > > > > > that this doc > > > > > > > > is an attempt to bridge some gaps between the IETF and > > > > > the ITU-T, > > > > > > > > and as such is fairly important. It would be > > > useful to give an > > > > > > > > update on its status at the interim T1X1 > meeting in June. > > > > > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 19:45:49 +0000 Message-ID: <012b01c31988$23b97830$681810ac@movaz.com> From: "Adrian Farrel" To: "Jonathan Sadler" Cc: Subject: Re: ASON reqts Date: Tue, 13 May 2003 15:44:59 -0400 > Currently, the document excludes a number of requirements specified in G.8080, > and G.7713 that are handled by RFC 3474. No information is provided in the > document or on the CCAMP list why these were dropped. Pointers please. There was no intention to drop any requirement so please let us know what is missing. Thanks. > I would also like to know why it is referencing outdated documents (ex. > [IPO-ASON] was published in March 2002) when more recent > requirements/architecture material is available. Well, there is no reason not to reference this material at this stage. Indeed, someone just asked for it to be referenced, I think. With regard to other material, again please provide pointers and we will happily read and reference is as appropriate. This is what the review process is all about (and it is orthogonal to whether the WG adopts the draft IMHO) Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 19:23:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:22:33 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109A0F106@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMZg6Rpd8p5m2g0RIyuvz8xUId0KQAAUp1w From: "Brungard, Deborah A, ALABS" To: "Jonathan Sadler" , "Kireeti Kompella" Cc: Hi Jonathan, We need specifics- Deborah -----Original Message----- From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] Sent: Tuesday, May 13, 2003 7:57 PM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON reqts Kireeti - "I have read this document, and it isn't ready to be a CCAMP doc". Currently, the document excludes a number of requirements specified in = G.8080, and G.7713 that are handled by RFC 3474. No information is provided in = the document or on the CCAMP list why these were dropped. I would also like to know why it is referencing outdated documents (ex. [IPO-ASON] was published in March 2002) when more recent requirements/architecture material is available. Jonathan Sadler Kireeti Kompella wrote: > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to read and = comment > > on the ASON reqts draft, as this was deemed tremendously important, = and > > a rich source of misunderstanding and cross-talk; and coming to a = common > > understanding over this should help get the IETF and the ITU working > > together. > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. =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 The information contained in this message may be privileged=20 and confidential and protected from disclosure. If the=20 reader of this message is not the intended recipient, or an=20 employee or agent responsible for delivering this message to=20 the intended recipient, you are hereby notified that any=20 reproduction, dissemination or distribution of this=20 communication is strictly prohibited. If you have received=20 this communication in error, please notify us immediately by=20 replying to the message and deleting it from your computer. Thank you. Tellabs =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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 19:20:46 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Tue, 13 May 2003 14:19:52 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33EA@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMZdkgOKsZwvks7T+ChZdEPhKvIKwABNQoA From: "Brungard, Deborah A, ALABS" To: "Varma, Eve L (Eve)" , "John Drake" , "Wijnen, Bert (Bert)" Cc: The intention of gmpls-ason-reqs is not to repeat G8080. And it is not = about G7713.2. It is to address GMPLS support of G8080. If it becomes a = WG document, any/all comments are welcome. Individuals' participation = will depend on company interests. We can not "require" anyone to = participate. This is not a hobby for most of us;-) This email is more appropriate as a private exchange - naming of = individuals severely lacks in recognition of the many who contribute in = the T1X1/ITU and the IETF work. As T1X1.5 chair/vice chair for many = years, including the birth of ASON, I wish I could say, that I was too = young too remember, but I was there, actually Malcolm could say he was = too young;-). And I am not the primary player for T1X1.5 work, there are = no primary players, it is a committee representing companies. One could = ask, why were none of the IETF GMPLS experts asked to participate in the = ITU work? We are trying to progress an IETF draft on GMPLS support of ASON. I am a = carrier interested in GMPLS. None of us are writing resumes. Let's = progress with specific comments on the drafts. Deborah -----Original Message----- From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] Sent: Tuesday, May 13, 2003 1:30 PM To: 'John Drake'; Wijnen, Bert (Bert) Cc: 'ccamp@ops.ietf.org' Subject: RE: ASON reqts Hi John, If you want to work with the primary contributors to the development of = G.8080, then it is essential you be engaged in conversations with Alan = McGuire, George Newsome, Malcolm Betts, Mike Mayer at least (my = apologies to other contributors of text that I have not acknowledged). = In terms of RSVP extensions aspects, direct engagement with the editor = of G.7713.2 (Dimitrios Penderakis) and the former editor of G.7713, who = worked through early Feb. '03 on this document (Zhi-Wei Lin) would be = advisable as well. Your constructive interaction with these players = would do much to improve the relationship. Deborah's involvement is = more recent, as I'm sure she would acknowledge. With best regards, Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, May 13, 2003 12:18 PM To: John Drake; 'Wijnen, Bert (Bert)' Cc: 'ccamp@ops.ietf.org' Subject: RE: ASON reqts Bert, Also, I don't know if you noticed but Deborah Brungard, who was a major contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D (http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-as= on- 00.txt). So we really are trying to make the ITU/IETF working relationship = better. Thanks, John=20 > -----Original Message----- > From: John Drake=20 > Sent: Tuesday, May 13, 2003 9:09 AM > To: 'Wijnen, Bert (Bert)' > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts >=20 >=20 > Bert, >=20 > We're discussing submitting the two drafts=20 > (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp > -gmpls-ason-reqts-00.txt,=20 > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls- > rsvp-te-ason-00.txt) as contributions to the ITU meeting in=20 > Chicago next month. >=20 > The intention is to work closely with T1X1 and ITU in order=20 > to get them a satisfactory GMPLS solution, but we still need=20 > to follow the IETF process for work done in the IETF. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, May 13, 2003 8:56 AM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > >=20 > >=20 > > >=20 > > >=20 > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn > > g-proc-00.txt. > > > (It's the one you co-authored.) > > >=20 > > Aha... OK, that doc still needs approval. > > We have sort of agreed that we would test-run a document from MPLS > > WG through the process to see how/if it works. > >=20 > > But more to the point, that document is on how we control=20 > work brought > > to the IETF. It does not control how we interact as decent=20 > > human beings > > and decent organisations with our counterparts. > >=20 > > The ASON specs (including how to do GMPLS for ASON) were done=20 > > by ITU-T. > > So we cannot just assume that we need to take over. I do not believe > > that tha above change-control-procedures are intended to specify > > how we take away or steal or whatever-term-you-want-use work from > > other organisations. > >=20 > > That is why I suggested the decent communication path in my earlier > > posting. > >=20 > > Bert > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Tuesday, May 13, 2003 8:11 AM > > > > To: John Drake > > > > Cc: ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > >=20 > > > >=20 > > > > >=20 > > > > > Bert, > > > > >=20 > > > > > I thought that we had a process - the post RFC3474 process. =20 > > > >=20 > > > > I guess I must have missed that.=20 > > > > Where is that or what are you referring to? > > > >=20 > > > > I also know that some of you do not believe we did send the ASON > > > > people away... but for me that it what it boiled down to. > > > > YMMV > > > >=20 > > > > Bert > > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 19:07:23 +0000 Message-ID: <3EC186DF.7D110B79@tellabs.com> Date: Tue, 13 May 2003 18:59:27 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "'Stephen Trowbridge'" , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John - What does section 9.2 of RFC 3474 accomplish then? (For those unaware, Sect. 9.2 is titled "Complete Separation of Call and Connection") Jonathan Sadler John Drake wrote: > I think that the problem is that RFC 3474, in addition to its technical > issues, doesn't address all of the ASON requirements. For example, it does > not address full call/connection separation. So we're following the post > 3474 procees of documenting the ASON requirements relevant to GMPLS > signalling in order to have a common understanding of what problem is to be > solved. > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Monday, May 12, 2003 2:27 PM > > To: John Drake > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > Bert & John, > > I think this document has nothing to do with the issue Bert > > mentioned. This was a protocol issue, not a requirements issue. > > A decision was made to leave the message out of 3474 with the > > belief that: > > - The protocol works without it; and > > - The presence of the message violates the protocol. > > The appropriate next step here would be a liaison back to ITU-T > > explaining what was done and why, and if the ITU-T agrees with > > the reasoning, they can align their protocol document (in this > > case, G.7713.2). > > > > Back to Bert's original questions: > > > > > > - is there or do we see any conflict? > > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > > and should not be advanced to a WG document until it is. > > However, before > > we do, I think we need to understand why this is necessary > > - see below. > > > > > > > > - are we duplicating some work? > > - Almost certainly. If we take the kind of alignment with ITU-T > > requirements that Zhi mentions as a "gate" for progressing > > this, then > > what is in this document that is different from G.8080 and > > G.7713 and > > why do we need this in place of a normative reference? > > > > > > > > - what is the purpose of this draft? > > Excellent question. > > > > > > - is it after the fact documenting of requirements? > > If it is, why bother? Also, we already have the requirements > > (developed > > before the protocol) in G.8080 and G.7713. > > > > > > > > - is it getting ITU-T documented requirements in RFC form? > > This could be a reasonable goal, if this document is to be an info > > track requirements document characterizing G.8080 and G.7713 for > > IETF folks in the same way that RFC 3474 does for G.7713.2 and > > RFC 3475 does for G.7713.3. But it is hard to understand why producing > > an IETF translation of the ITU-T question would be very high priority > > when we already have an IETF translation of the answer, but > > fundamentally > > there would be no problem if this were the objective. > > > > > > > > - is it extending ITU-T documented requirements? > > I don't think so. If it is, I hope we start with a liaison rather > > than trying to extend ITU-T requirements without talking to > > ITU-T first. > > > > > > > > - is it contrdicting them? > > This is my biggest worry. I don't think we should start the process > > over again and open the door that we come up with yet another > > protocol solution to address the same requirements. Vendors are > > already building to G.7713.2, G.7713.3 (and by extension, to > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > > start a new work item with an objective to develop a new protocol > > solution to the same problem. > > > > > > > > - is it meant to be used as communication to ITU? > > I haven't seen this proposed, but I think that if the goal is > > to capture ITU-T requirements in RFC form, it would be a good > > idea to ask ITU-T whether the proposed document accurately > > captures their requirements. > > > > /Steve > > > > > > John Drake wrote: > > > > > > Bert, > > > > > > I think so. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Monday, May 12, 2003 1:27 PM > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > I know that some people had issues with the way that ITU-T > > > > had defined the RSVP-TE extensions for ASON. In fact there > > > > was/is a claim that it is broken. So we removed the offending > > > > text from the RFC3474. > > > > > > > > The next thing we were going to do (as far as I understood it) > > > > is to document why we (or some of us in IETF) think that the > > > > ITU-T solution is broken, potentially with suggested fixes. > > > > That we would send to ITU-T SG15. > > > > > > > > Is this the first step of that process? > > > > > > > > Thanks, > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: John Drake [mailto:jdrake@calient.net] > > > > > Sent: maandag 12 mei 2003 22:24 > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > Bert, > > > > > > > > > > I thought that the post 3474/3475 process started with a > > > > requirements > > > > > document. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > > that those 2 RFCs point to, then I wonder: > > > > > > - is there or do we see any conflict? > > > > > > - are we duplicating some work? > > > > > > - what is the purpose of this draft? > > > > > > - is it after the fact documenting of requirements? > > > > > > - is it getting ITU-T documented requirements in RFC form? > > > > > > - is it extending ITU-T documented requirements? > > > > > > - is it contrdicting them? > > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > > > Thanks, > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > > To: ccamp@ops.ietf.org > > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > > > To take things one at a time, it would be very useful to > > > > > > > read and comment > > > > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > > > > important, and > > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > > coming to a common > > > > > > > > understanding over this should help get the IETF and the > > > > > > ITU working > > > > > > > > together. > > > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > > either that no > > > > > > > one cares, or that folks have read it and have no issues. > > > > > > > > > > > > > > I'd like to get a reading on whether this doc is > > ready to be a > > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > > with one of: > > > > > > > - "I have read this document and it is ready to be a CCAMP > > > > > > WG doc" OR > > > > > > > - "I have read this document, and it isn't ready to be a > > > > > > CCAMP doc". > > > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > > assumption is > > > > > > > that the document is either not of interest or not > > ready, and in > > > > > > > either case will not become a CCAMP WG doc. Note too > > > > > that this doc > > > > > > > is an attempt to bridge some gaps between the IETF and > > > > the ITU-T, > > > > > > > and as such is fairly important. It would be > > useful to give an > > > > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > > > Thanks, > > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > > > > > > ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 19:04:26 +0000 Message-ID: <3EC18648.9EA7B269@tellabs.com> Date: Tue, 13 May 2003 18:56:56 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti - "I have read this document, and it isn't ready to be a CCAMP doc". Currently, the document excludes a number of requirements specified in G.8080, and G.7713 that are handled by RFC 3474. No information is provided in the document or on the CCAMP list why these were dropped. I would also like to know why it is referencing outdated documents (ex. [IPO-ASON] was published in March 2002) when more recent requirements/architecture material is available. Jonathan Sadler Kireeti Kompella wrote: > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to read and comment > > on the ASON reqts draft, as this was deemed tremendously important, and > > a rich source of misunderstanding and cross-talk; and coming to a common > > understanding over this should help get the IETF and the ITU working > > together. > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 17:32:37 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97256A@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , "Wijnen, Bert (Bert)" Cc: "'ccamp@ops.ietf.org'" Subject: RE: ASON reqts Date: Tue, 13 May 2003 10:32:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Great, thanks > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Tuesday, May 13, 2003 10:30 AM > To: John Drake; Wijnen, Bert (Bert) > Cc: 'ccamp@ops.ietf.org' > Subject: RE: ASON reqts > > > Hi John, > > If you want to work with the primary contributors to the > development of G.8080, then it is essential you be engaged in > conversations with Alan McGuire, George Newsome, Malcolm > Betts, Mike Mayer at least (my apologies to other > contributors of text that I have not acknowledged). In terms > of RSVP extensions aspects, direct engagement with the editor > of G.7713.2 (Dimitrios Penderakis) and the former editor of > G.7713, who worked through early Feb. '03 on this document > (Zhi-Wei Lin) would be advisable as well. Your constructive > interaction with these players would do much to improve the > relationship. Deborah's involvement is more recent, as I'm > sure she would acknowledge. > > With best regards, > Eve > > > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Tuesday, May 13, 2003 12:18 PM > To: John Drake; 'Wijnen, Bert (Bert)' > Cc: 'ccamp@ops.ietf.org' > Subject: RE: ASON reqts > > > Bert, > > Also, I don't know if you noticed but Deborah Brungard, who > was a major > contributor to G.8080 (ASON), helped us out with the RSVP > extensions I-D > (http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls > -rsvp-te-ason- > 00.txt). > > So we really are trying to make the ITU/IETF working > relationship better. > > Thanks, > > John > > > -----Original Message----- > > From: John Drake > > Sent: Tuesday, May 13, 2003 9:09 AM > > To: 'Wijnen, Bert (Bert)' > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Bert, > > > > We're discussing submitting the two drafts > > (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp > > -gmpls-ason-reqts-00.txt, > > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls- > > rsvp-te-ason-00.txt) as contributions to the ITU meeting in > > Chicago next month. > > > > The intention is to work closely with T1X1 and ITU in order > > to get them a satisfactory GMPLS solution, but we still need > > to follow the IETF process for work done in the IETF. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Tuesday, May 13, 2003 8:56 AM > > > To: John Drake > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn > > > g-proc-00.txt. > > > > (It's the one you co-authored.) > > > > > > > Aha... OK, that doc still needs approval. > > > We have sort of agreed that we would test-run a document from MPLS > > > WG through the process to see how/if it works. > > > > > > But more to the point, that document is on how we control > > work brought > > > to the IETF. It does not control how we interact as decent > > > human beings > > > and decent organisations with our counterparts. > > > > > > The ASON specs (including how to do GMPLS for ASON) were done > > > by ITU-T. > > > So we cannot just assume that we need to take over. I do > not believe > > > that tha above change-control-procedures are intended to specify > > > how we take away or steal or whatever-term-you-want-use work from > > > other organisations. > > > > > > That is why I suggested the decent communication path in > my earlier > > > posting. > > > > > > Bert > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Tuesday, May 13, 2003 8:11 AM > > > > > To: John Drake > > > > > Cc: ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > > > I thought that we had a process - the post RFC3474 > process. > > > > > > > > > > I guess I must have missed that. > > > > > Where is that or what are you referring to? > > > > > > > > > > I also know that some of you do not believe we did > send the ASON > > > > > people away... but for me that it what it boiled down to. > > > > > YMMV > > > > > > > > > > Bert > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 17:30:57 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143D9@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'John Drake'" , "Wijnen, Bert (Bert)" Cc: "'ccamp@ops.ietf.org'" Subject: RE: ASON reqts Date: Tue, 13 May 2003 13:30:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, If you want to work with the primary contributors to the development of G.8080, then it is essential you be engaged in conversations with Alan McGuire, George Newsome, Malcolm Betts, Mike Mayer at least (my apologies to other contributors of text that I have not acknowledged). In terms of RSVP extensions aspects, direct engagement with the editor of G.7713.2 (Dimitrios Penderakis) and the former editor of G.7713, who worked through early Feb. '03 on this document (Zhi-Wei Lin) would be advisable as well. Your constructive interaction with these players would do much to improve the relationship. Deborah's involvement is more recent, as I'm sure she would acknowledge. With best regards, Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, May 13, 2003 12:18 PM To: John Drake; 'Wijnen, Bert (Bert)' Cc: 'ccamp@ops.ietf.org' Subject: RE: ASON reqts Bert, Also, I don't know if you noticed but Deborah Brungard, who was a major contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D (http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason- 00.txt). So we really are trying to make the ITU/IETF working relationship better. Thanks, John > -----Original Message----- > From: John Drake > Sent: Tuesday, May 13, 2003 9:09 AM > To: 'Wijnen, Bert (Bert)' > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Bert, > > We're discussing submitting the two drafts > (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp > -gmpls-ason-reqts-00.txt, > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls- > rsvp-te-ason-00.txt) as contributions to the ITU meeting in > Chicago next month. > > The intention is to work closely with T1X1 and ITU in order > to get them a satisfactory GMPLS solution, but we still need > to follow the IETF process for work done in the IETF. > > Thanks, > > John > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, May 13, 2003 8:56 AM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn > > g-proc-00.txt. > > > (It's the one you co-authored.) > > > > > Aha... OK, that doc still needs approval. > > We have sort of agreed that we would test-run a document from MPLS > > WG through the process to see how/if it works. > > > > But more to the point, that document is on how we control > work brought > > to the IETF. It does not control how we interact as decent > > human beings > > and decent organisations with our counterparts. > > > > The ASON specs (including how to do GMPLS for ASON) were done > > by ITU-T. > > So we cannot just assume that we need to take over. I do not believe > > that tha above change-control-procedures are intended to specify > > how we take away or steal or whatever-term-you-want-use work from > > other organisations. > > > > That is why I suggested the decent communication path in my earlier > > posting. > > > > Bert > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Tuesday, May 13, 2003 8:11 AM > > > > To: John Drake > > > > Cc: ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > I thought that we had a process - the post RFC3474 process. > > > > > > > > I guess I must have missed that. > > > > Where is that or what are you referring to? > > > > > > > > I also know that some of you do not believe we did send the ASON > > > > people away... but for me that it what it boiled down to. > > > > YMMV > > > > > > > > Bert > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:59:21 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC925BCF@nimbus> From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Tue, 13 May 2003 09:58:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, Fine, send it as is. -Ayan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, May 11, 2003 11:23 PM > To: ccamp@ops.ietf.org > Cc: sob@harvard.edu; Wijnen, Bert (Bert); Ron Bonica > (E-mail); zinin@psg.com > Subject: RE: Proposed response to the Liaison Statement on > LMP Link Verifi cation > > > Hi All, > > On Tue, 29 Apr 2003, Kireeti Kompella wrote: > > > I will formulate a liaison statement in reply to T1X1 regarding > > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. > > Sorry for the tardy follow-up. Here is the proposed response. > > Please send your replies to the list (if you wish to reply > privately, include the Liaison Coordinator and the ADs in your reply). > > Ideally, your reply should say one of: > - "Fine, send it as is"; OR > - "Please make the following changes", with _specific text_; OR > - "Do not send this response". > > Please respond by COB Friday, May 16th. > > Kireeti. > ============================================================== > ========= > > Dear Mr. Biholar, > > Regarding the following liaison: > > TITLE: Liaison from T1X1 to IETF ccamp regarding > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt > TO: IETF ccamp Working Group > CC: ITU-T Q.14/15 (for information) > SOURCE*: T1X1 > FOR: Action > DEADLINE: 9 June 2003 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic > Interconnection > > We thank the T1X1 and the ITU-T for their review and the > incorporation of the LMP Test procedure into G.7714.1. > > Based on information contained in the ITU and T1X1 liaison, > as well as subsequent e-mail exchanges on the CCAMP mailing > list, and in order to ensure proper interoperability in > legacy SDH/SONET networks as well as networks in which > G.7714.1 is deployed, it will be recommended by the editors > to the CCAMP community to support only the Jx trace > correlation procedure and not the in-band Jx procedure. > Pending agreement, the draft will be updated. > > See inline for more detailed responses to specific points. > > > Context of Application Space > > > > > It is currently our understanding that the use case > > scenario for which this procedure is applied encompasses > > both transport plane connectivity verification as well as > correlation > > of these entities with the control plane. ITU-T G.7714.1 is > focused on > > discovering the transport plane link connection end point > > relationships and verifying their connectivity. > > This Recommendation defines two procedures for performing > > the connectivity verification function, one of which > > utilizes either the Jx or the DCC bytes of the server > > signal (termed "in-service"). The other approach in > > G.7714.1, termed as "out of service", corresponds to > > inserting a test signal in the payload of the server > > signal. Based on an analysis of the data link state > > definitions in draft-ietf-ccamp-lmp-08.txt, we understand > > that the approach defined in the LMP test for physical > > connectivity occurs in the context of the "out of service" > > state (as described in G.7714.1). > > > > Please confirm this. > > The subject document uses the Jx or DCC bytes to perform the > LMP Test procedure, but the The LMP Test procedure is done as > part of GMPLS link intialization, prior to the link being > available to carry user traffic. > > > Usage of Jx Bytes > > > > In defining the Jx bytes within G.7714.1, the following > > was taken into account: > > 1. One consideration involved the case where the Discovery Agent is > > located in an external system, and an external interface is used by > > the Network Element to provision and receive the Trail > Trace message. > > As an existing text- oriented Man-Machine Language, such as > TL1, may > > be reused to provide this interface, it was decided that the > > discovery message be limited to printable characters. > > Specifically, the TTI characters should be limited to > > printable characters as per T.50 with trailing NULLs or > > SPACEs. Use of arbitrary bit patterns in the lower 7 bits > > of each byte could prematurely terminate the pattern or > > trigger fault notification for certain hardware or > > software implementations. The strategy chosen in G.7714.1 > > avoids the danger by limiting the information content of > > each byte to 6 bits (84 bits total) and uses a base 64 > > coding according to RFC2045 to place the information in > > the available bits. > > The LMP test procedure described in the subject document > defines two usages of the Jx bytes. The first is termed the > 'trace correlation transport mechanism' and it treats the Jx > bytes as an opaque bit stream. > > This usage is completely consistent with the above. GMPLS > identifiers are typically 32 bit numbers and as such are not > printable characters. In networks that do not require that > the Jx bytes be printable, it is also possible to carry the > GMPLS identifiers directly in the Jx bytes. This is termed > the 'Jx transport mechanism'. > > > 2. Another consideration involved providing a means for > distinguishing > > this use of the Jx bytes from the traditional use for Trail Trace > > identifiers in new equipments. As a result, G.7714.1 includes a > > distinguishing character ("+") as the first non-CRC byte > > that will never appear as the first character of a TTI. > > This requires modification of the trail termination > > functions to prevent the raising of TTI mismatch > > alarms during the connectivity verification process. > > The selection of which LMP transport mechanism use in the LMP > Test procedure for a given link as well as the time at which > the Jx bytes are to be used for the LMP Test procedure is > under control of the GMPLS nodes at either end of the link, > so it is well understood by those nodes. It is our > understanding, per G.806 section 6.1, that the LMP Test > procedure would be performed when the link is in the NMON > (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > > > While the context for testing the transport plane connectivity is > > different between the two documents, they both use the Jx > bytes of the > > server signal, and we invite the IETF to determine the > appropriateness > > of the above aspects in their test signal definitions. > > The trace correlation transport mechanism is completely > consistent with this. The JX transport mechanism requires > additional identifiers (i.e., the Verify ID). > > > Even if these considerations are not relevant to this > context, it will > > be necessary to augment G.783 equipment functions to recognize this > > new usage of Jx messages. > > We would be happy to provide assistance to T1X1/ITU-T in > augmenting G.783 equipment functions to recognize the > additional capability for supporting GMPLS networking elements. > > > Required Updates to SDH Equipment Specifications > > > > SDH equipment specifications as they currently exist > reflect the usage > > of the Jx bytes prior to the development of G.7714.1. ITU-T Study > > Group 15 has as a work item to revise these equipment functions to > > include support for these new functions. Specifically, this will > > involve updates to trail termination functions to generate and > > receive the new messages and to avoid unnecessary alarms in > > the case where the new messages are received. In addition, > > non-intrusive monitoring functions will need to be revised > > so that unnecessary alarms are not raised when the > > messages are observed en-route. Whether or not there is > > further alignment between the message formats used in > > G.7714.1 and the subject draft, the new functions to > > support the subject draft will also need to be reflected > > in the atomic functions in G.783. The sending and > > receiving of these messages can be reflected in the trail > > termination functions in a similar way to what we plan to > > do for support of G.7714.1 functions. > > We would be happy to provide assistance to T1X1/ITU-T in > augmenting G.783 equipment functions to recognize the > additional capability for supporting GMPLS networking elements. > > > Terminology Differences > > > > > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > > the "up/free (in-service)" data link state appears to > correspond with > > what G.7714.1 refers to as "out-of- service". This difference in > > terminology has resulted in different interpretations of > the context. > > Explaining the scenarios further in the lmp test document would be > > beneficial in establishing a translation between the > > differing uses of the same terms. Within ITU-T, work is > > being initiated of draft Rec. G.fame, Framework for ASON > > Management, where control plane/management plane > > interactions will be addressed. > > We agree that terminology differences between IETF and ITU-T > wrt GMPLS have been confusing. There is an ongoing effort > within CCAMP to work together with T1X1/ITU-T on bridging the > terminology gaps. For example, there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered > in CCAMP to do this mapping for LMP. > > > Further Study Items > > > > Following are some areas where further contributions are > > requested: > > 1. For SDH equipment functions in G.783, it needs to > > be understood whether the application of the lmp test > > message requires revision of NIM (non-intrusive > > monitoring) functions. The reason for this is that the > > test procedure is initiated between control entities at > > the end-points of the trail, and intermediate points are > > not necessarily aware that the test is taking place. For > G.7714.1, it > > was felt important for any termination or NIM function to easily > > distinguish between the various uses of the Jx bytes. It may be > > necessary for the subject draft to use a similarly easily > recognizable > > format. If no revision to NIM functions is required for > the context > > of this draft, the architecture of the context for this > > application (demonstrating why the NIM functions are not > > required) should be reflected in G.803 and/or G.807/G.8080. > > It is our understanding, per G.806 section 6.1, that > the LMP Test procedure would be performed when the link is in > the NMON (not monitored state), and therefore intermediate > SDH/SONET equipment would not be performing non-intrusive > monitoring. As described, the trace correlation procedure use > of Jx bytes is consistent with the current standards. > > > 2.Determination of whether it would be possible to use the > identical > > message formats in the subject draft as in G.7714.1 for the > > connectivity verification function. > > The trace correlation transport mechanism is completely > consistent with this. The Jx transport mechanism requires > additional identifiers (i.e., the Verify ID). > > > 3.Determination of whether it would be possible to use the same > > overall structure (distinguishing character, 4 bit message type, 80 > > bit message body) if a different message format or > information content > > is required. > > This is certainly possible (not applicable for the trace > correlation procedure). > > > 4.Work is needed to clarify under what > > configurations/states (for example: no VC-n signals > > carrying client traffic) the lmp test message is > > applicable over J0. If the signal can be framed and J0 > > can be recovered, the Regenerator Section is considered > > as "in service" from a transport plane perspective. So unlike the > > J1/J2 case, the application of the lmp test message at the > Regenerator > > Section does not occur in an "out of service" state (from a > transport > > plane perspective). > > Section 6.1 of G.806 refers to a "termination function part > of a trail, which is in the process of set-up" as in the NMON > state. LMP link verification is based on pre-service testing. > Please let us know if we can be of any assistance in > updating the appropriate Recommendations to support the GMPLS > network element LMP capability. This is not applicable for > the trace correlation procedure. > > > 5. Clarification of the usage of transport and control > > names for transport resources in the subject draft, as described in > > G.8080 Amendment > > The trace correlation transport mechanism supports a > separation of the transport and control plane identifiers. > > > 6. Consideration of the ANSI 64-byte J1. > > This was mistakenly deleted from the latest version of the > draft. This will be included in the next version. > > Sincerely, > Kireeti Kompella and Ron Bonica, > Chairs of the CCAMP WG/IETF. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:40:42 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Tue, 13 May 2003 11:39:19 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33E9@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMZXoWeR58zuV4pQbaE1n9WeWlkLQAAsuug From: "Brungard, Deborah A, ALABS" To: "Wijnen, Bert (Bert)" , Cc: Hi Bert, Can you provide clarification on your email? - the January ASON email exchange and the previous ITU-T liaisons = clearly identified RFC-3471 and RFC-3473 lacked ASON support. The two = ason drafts submitted are to initiate this work. - majority of the email supports the reqs draft becoming a WG document. = And hopefully, those concerned will also support as WG document based on = the understanding a WG doc is a work in progress as posted by one email: > There are a few issues that I don't quite understand and/or need > clarification on, but the current vote is WG acceptance, not = last-call. > I have no issues with it that would keep it out from the WG. Most of the email is on clarifying G7713.2 and the rsvp-te-ason draft. = This draft addresses a totally different application/solution than = G7713.2. The rsvp-te-ason draft covers the necessary extensions to = RFC-3473 to support ASON for a GMPLS network. The difference of this = draft and G7713.2 is that this draft is backward and forward compatible = for GMPLS networks; i.e. transit nodes (ITU term: Internal Protocol = Controller (I-PC)) do not need to be updated. G7713.2 is an E-NNI which = is using GMPLS but it is not based on GMPLS e.g. G7713.2 does not = provide call and connection functional separation because it was not = based on use with an RFC-3473 network. Eve's mail clarifies this = regarding the domain definitions. If the draft is confusing in this = regard, we can work on the wording. The draft is on extending RFC-3473 to support ASON. If IETF does not = extend RFC-3473, then GMPLS will not support ASON. This work is totally = independent of the existence of G7713.2. As we discuss the draft, we can = clarify if this is confusing. Deborah -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, May 13, 2003 10:38 AM To: Bart.Rousseau@alcatel.be Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts AD-hat on. Bart writes: >=20 >=20 > Stephen, >=20 > I think the point was rather to go back to > just a single GMPLS spec instead of two (let alone three) variants... >=20 If that is the case, and if we want to do that in IETF CCAMP=20 (not sure it is part of the current CCAMP charter), then it seems to me that we (CCAMP) should excercise these steps: - send some liason to ITU-T SG 15 to explain that we found that there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard - that we think that this is NOT goodness, and that we regret that we did send the ASON people away a few years back and did not closely follow their work in ITU - that we now believe that we should have worked better together, - that we would like to explore ways to try and mrege the two solution back into one common solution And then await the response and hope ITU will agree and then see how the work can be organized. >=20 > Bart >=20 Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:35:23 +0000 Message-ID: <3EC11E8F.70604@alcatel.de> Date: Tue, 13 May 2003 18:34:23 +0200 From: Dieter Beller Organization: Alcatel SEL AG, OND Stuttgart, Germany User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kireeti and all, Fine, send it as is Dieter Kireeti Kompella wrote: > Hi All, > > On Tue, 29 Apr 2003, Kireeti Kompella wrote: > > >>I will formulate a liaison statement in reply to T1X1 regarding >>draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. > > > Sorry for the tardy follow-up. Here is the proposed response. > > Please send your replies to the list (if you wish to reply privately, > include the Liaison Coordinator and the ADs in your reply). > > Ideally, your reply should say one of: > - "Fine, send it as is"; OR > - "Please make the following changes", with _specific text_; OR > - "Do not send this response". > > Please respond by COB Friday, May 16th. > > Kireeti. > ======================================================================= > > Dear Mr. Biholar, > > Regarding the following liaison: > > TITLE: Liaison from T1X1 to IETF ccamp regarding > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt > TO: IETF ccamp Working Group > CC: ITU-T Q.14/15 (for information) > SOURCE*: T1X1 > FOR: Action > DEADLINE: 9 June 2003 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection > > We thank the T1X1 and the ITU-T for their review and the incorporation > of the LMP Test procedure into G.7714.1. > > Based on information contained in the ITU and T1X1 liaison, as well as > subsequent e-mail exchanges on the CCAMP mailing list, and in order to > ensure proper interoperability in legacy SDH/SONET networks as well as > networks in which G.7714.1 is deployed, it will be recommended by the > editors to the CCAMP community to support only the Jx trace correlation > procedure and not the in-band Jx procedure. Pending agreement, the > draft will be updated. > > See inline for more detailed responses to specific points. > > >>Context of Application Space > > > > >>It is currently our understanding that the use case >>scenario for which this procedure is applied encompasses >>both transport plane connectivity verification as well as >>correlation of these entities with the control plane. >>ITU-T G.7714.1 is focused on discovering the transport >>plane link connection end point relationships and >>verifying their connectivity. >>This Recommendation defines two procedures for performing >>the connectivity verification function, one of which >>utilizes either the Jx or the DCC bytes of the server >>signal (termed "in-service"). The other approach in >>G.7714.1, termed as "out of service", corresponds to >>inserting a test signal in the payload of the server >>signal. Based on an analysis of the data link state >>definitions in draft-ietf-ccamp-lmp-08.txt, we understand >>that the approach defined in the LMP test for physical >>connectivity occurs in the context of the "out of service" >>state (as described in G.7714.1). >> >>Please confirm this. > > > The subject document uses the Jx or DCC bytes to perform the LMP > Test procedure, but the The LMP Test procedure is done as part of > GMPLS link intialization, prior to the link being available to > carry user traffic. > > >>Usage of Jx Bytes >> >>In defining the Jx bytes within G.7714.1, the following >>was taken into account: >>1. One consideration involved the case where the Discovery >>Agent is located in an external system, and an external >>interface is used by the Network Element to provision and >>receive the Trail Trace message. As an existing text- >>oriented Man-Machine Language, such as TL1, may be reused >>to provide this interface, it was decided that the >>discovery message be limited to printable characters. >>Specifically, the TTI characters should be limited to >>printable characters as per T.50 with trailing NULLs or >>SPACEs. Use of arbitrary bit patterns in the lower 7 bits >>of each byte could prematurely terminate the pattern or >>trigger fault notification for certain hardware or >>software implementations. The strategy chosen in G.7714.1 >>avoids the danger by limiting the information content of >>each byte to 6 bits (84 bits total) and uses a base 64 >>coding according to RFC2045 to place the information in >>the available bits. > > > The LMP test procedure described in the subject document defines > two usages of the Jx bytes. The first is termed the 'trace > correlation transport mechanism' and it treats the Jx bytes as > an opaque bit stream. > > This usage is completely consistent with the above. GMPLS > identifiers are typically 32 bit numbers and as such are not > printable characters. In networks that do not require that the > Jx bytes be printable, it is also possible to carry the GMPLS > identifiers directly in the Jx bytes. This is termed the 'Jx > transport mechanism'. > > >>2. Another consideration involved providing a means for >>distinguishing this use of the Jx bytes from the >>traditional use for Trail Trace identifiers in new >>equipments. As a result, G.7714.1 includes a >>distinguishing character ("+") as the first non-CRC byte >>that will never appear as the first character of a TTI. >>This requires modification of the trail termination >>functions to prevent the raising of TTI mismatch >>alarms during the connectivity verification process. > > > The selection of which LMP transport mechanism use in the LMP Test > procedure for a given link as well as the time at which the Jx > bytes are to be used for the LMP Test procedure is under control of > the GMPLS nodes at either end of the link, so it is well understood > by those nodes. It is our understanding, per G.806 section 6.1, > that the LMP Test procedure would be performed when the link is in > the NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > > >>While the context for testing the transport plane >>connectivity is different between the two documents, they >>both use the Jx bytes of the server signal, and we invite >>the IETF to determine the appropriateness of the above >>aspects in their test signal definitions. > > > The trace correlation transport mechanism is completely consistent > with this. The JX transport mechanism requires additional > identifiers (i.e., the Verify ID). > > >>Even if these considerations are not relevant to this >>context, it will be necessary to augment G.783 equipment >>functions to recognize this new usage of Jx messages. > > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > >>Required Updates to SDH Equipment Specifications >> >>SDH equipment specifications as they currently exist reflect >>the usage of the Jx bytes prior to the development of >>G.7714.1. ITU-T Study Group 15 has as a work item to >>revise these equipment functions to include support for >>these new functions. Specifically, this will involve >>updates to trail termination functions to generate and >>receive the new messages and to avoid unnecessary alarms in >>the case where the new messages are received. In addition, >>non-intrusive monitoring functions will need to be revised >>so that unnecessary alarms are not raised when the >>messages are observed en-route. Whether or not there is >>further alignment between the message formats used in >>G.7714.1 and the subject draft, the new functions to >>support the subject draft will also need to be reflected >>in the atomic functions in G.783. The sending and >>receiving of these messages can be reflected in the trail >>termination functions in a similar way to what we plan to >>do for support of G.7714.1 functions. > > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > >>Terminology Differences > > > > >>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, >>the "up/free (in-service)" data link state appears to >>correspond with what G.7714.1 refers to as "out-of- >>service". This difference in terminology has resulted in >>different interpretations of the context. Explaining the >>scenarios further in the lmp test document would be >>beneficial in establishing a translation between the >>differing uses of the same terms. Within ITU-T, work is >>being initiated of draft Rec. G.fame, Framework for ASON >>Management, where control plane/management plane >>interactions will be addressed. > > > We agree that terminology differences between IETF and ITU-T wrt > GMPLS have been confusing. There is an ongoing effort within > CCAMP to work together with T1X1/ITU-T on bridging the terminology > gaps. For example, there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in > CCAMP to do this mapping for LMP. > > >>Further Study Items >> >>Following are some areas where further contributions are >>requested: >>1. For SDH equipment functions in G.783, it needs to >>be understood whether the application of the lmp test >>message requires revision of NIM (non-intrusive >>monitoring) functions. The reason for this is that the >>test procedure is initiated between control entities at >>the end-points of the trail, and intermediate points are >>not necessarily aware that the test is taking place. For >>G.7714.1, it was felt important for any termination or NIM >>function to easily distinguish between the various uses of >>the Jx bytes. It may be necessary for the subject draft >>to use a similarly easily recognizable format. If no >>revision to NIM functions is required for the context of >>this draft, the architecture of the context for this >>application (demonstrating why the NIM functions are not >>required) should be reflected in G.803 and/or G.807/G.8080. > > > It is our understanding, per G.806 section 6.1, that > the LMP Test procedure would be performed when the link is in the > NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > As described, the trace correlation procedure use of Jx bytes is > consistent with the current standards. > > >>2.Determination of whether it would be possible to use the >>identical message formats in the subject draft as in >>G.7714.1 for the connectivity verification function. > > > The trace correlation transport mechanism is completely consistent > with this. The Jx transport mechanism requires additional > identifiers (i.e., the Verify ID). > > >>3.Determination of whether it would be possible to use the >>same overall structure (distinguishing character, 4 bit >>message type, 80 bit message body) if a different message >>format or information content is required. > > > This is certainly possible (not applicable for the trace correlation > procedure). > > >>4.Work is needed to clarify under what >>configurations/states (for example: no VC-n signals >>carrying client traffic) the lmp test message is >>applicable over J0. If the signal can be framed and J0 >>can be recovered, the Regenerator Section is considered >>as "in service" from a transport plane perspective. So >>unlike the J1/J2 case, the application of the lmp test >>message at the Regenerator Section does not occur in an >>"out of service" state (from a transport plane >>perspective). > > > Section 6.1 of G.806 refers to a "termination function part of a > trail, which is in the process of set-up" as in the NMON state. > LMP link verification is based on pre-service testing. Please let > us know if we can be of any assistance in updating the appropriate > Recommendations to support the GMPLS network element LMP capability. > This is not applicable for the trace correlation procedure. > > >>5. Clarification of the usage of transport and control >>names for transport resources in the subject draft, as >>described in G.8080 Amendment > > > The trace correlation transport mechanism supports a separation of > the transport and control plane identifiers. > > >>6. Consideration of the ANSI 64-byte J1. > > > This was mistakenly deleted from the latest version of the draft. > This will be included in the next version. > > Sincerely, > Kireeti Kompella and Ron Bonica, > Chairs of the CCAMP WG/IETF. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:31:56 +0000 Message-ID: <3EC11DBD.4030907@alcatel.de> Date: Tue, 13 May 2003 18:30:53 +0200 From: Dieter Beller Organization: Alcatel SEL AG, OND Stuttgart, Germany User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Proposed change to LMP Link Verification draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kireeti and all, I agree with the proposed change. Dieter Kireeti Kompella wrote: > Hi All, > > | Based on information contained in the ITU and T1X1 liaison, as well as > | subsequent e-mail exchanges on the CCAMP mailing list, and in order to > | ensure proper interoperability in legacy SDH/SONET networks as well as > | networks in which G.7714.1 is deployed, it will be recommended by the > | editors to the CCAMP community to support only the Jx trace correlation > | procedure and not the in-band Jx procedure. > > Please respond with one of the following: > - Agree with above change; OR > - Don't agree with above change [i.e., keep in-band Jx procedure as is]. > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:23:44 +0000 From: "zafar ali" To: "'Kireeti Kompella'" , Subject: RE: Proposed change to LMP Link Verification draft Date: Tue, 13 May 2003 12:23:02 -0400 Message-ID: <001101c3196b$ed50b3b0$6fd76540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Monday, May 12, 2003 2:28 AM > To: ccamp@ops.ietf.org > Subject: Proposed change to LMP Link Verification draft > > > Hi All, > > | Based on information contained in the ITU and T1X1 liaison, > as well as > | subsequent e-mail exchanges on the CCAMP mailing list, and > in order to > | ensure proper interoperability in legacy SDH/SONET networks > as well as > | networks in which G.7714.1 is deployed, it will be > recommended by the > | editors to the CCAMP community to support only the Jx trace > | correlation procedure and not the in-band Jx procedure. > > Please respond with one of the following: > - Agree with above change; OR I agree with the above change; Thanks Regards... Zafar > - Don't agree with above change [i.e., keep in-band Jx > procedure as is]. > > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:19:07 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972568@nimbus> From: John Drake To: John Drake , "'Wijnen, Bert (Bert)'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: ASON reqts Date: Tue, 13 May 2003 09:18:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Also, I don't know if you noticed but Deborah Brungard, who was a major contributor to G.8080 (ASON), helped us out with the RSVP extensions I-D (http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason- 00.txt). So we really are trying to make the ITU/IETF working relationship better. Thanks, John > -----Original Message----- > From: John Drake > Sent: Tuesday, May 13, 2003 9:09 AM > To: 'Wijnen, Bert (Bert)' > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Bert, > > We're discussing submitting the two drafts > (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp > -gmpls-ason-reqts-00.txt, > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls- > rsvp-te-ason-00.txt) as contributions to the ITU meeting in > Chicago next month. > > The intention is to work closely with T1X1 and ITU in order > to get them a satisfactory GMPLS solution, but we still need > to follow the IETF process for work done in the IETF. > > Thanks, > > John > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, May 13, 2003 8:56 AM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn > > g-proc-00.txt. > > > (It's the one you co-authored.) > > > > > Aha... OK, that doc still needs approval. > > We have sort of agreed that we would test-run a document from MPLS > > WG through the process to see how/if it works. > > > > But more to the point, that document is on how we control > work brought > > to the IETF. It does not control how we interact as decent > > human beings > > and decent organisations with our counterparts. > > > > The ASON specs (including how to do GMPLS for ASON) were done > > by ITU-T. > > So we cannot just assume that we need to take over. I do not believe > > that tha above change-control-procedures are intended to specify > > how we take away or steal or whatever-term-you-want-use work from > > other organisations. > > > > That is why I suggested the decent communication path in my earlier > > posting. > > > > Bert > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Tuesday, May 13, 2003 8:11 AM > > > > To: John Drake > > > > Cc: ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > I thought that we had a process - the post RFC3474 process. > > > > > > > > I guess I must have missed that. > > > > Where is that or what are you referring to? > > > > > > > > I also know that some of you do not believe we did send the ASON > > > > people away... but for me that it what it boiled down to. > > > > YMMV > > > > > > > > Bert > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:09:36 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972567@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 09:09:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, We're discussing submitting the two drafts (http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-re qts-00.txt, http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-0 0.txt) as contributions to the ITU meeting in Chicago next month. The intention is to work closely with T1X1 and ITU in order to get them a satisfactory GMPLS solution, but we still need to follow the IETF process for work done in the IETF. Thanks, John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 13, 2003 8:56 AM > To: John Drake > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > > > > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chn > g-proc-00.txt. > > (It's the one you co-authored.) > > > Aha... OK, that doc still needs approval. > We have sort of agreed that we would test-run a document from MPLS > WG through the process to see how/if it works. > > But more to the point, that document is on how we control work brought > to the IETF. It does not control how we interact as decent > human beings > and decent organisations with our counterparts. > > The ASON specs (including how to do GMPLS for ASON) were done > by ITU-T. > So we cannot just assume that we need to take over. I do not believe > that tha above change-control-procedures are intended to specify > how we take away or steal or whatever-term-you-want-use work from > other organisations. > > That is why I suggested the decent communication path in my earlier > posting. > > Bert > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Tuesday, May 13, 2003 8:11 AM > > > To: John Drake > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > Bert, > > > > > > > > I thought that we had a process - the post RFC3474 process. > > > > > > I guess I must have missed that. > > > Where is that or what are you referring to? > > > > > > I also know that some of you do not believe we did send the ASON > > > people away... but for me that it what it boiled down to. > > > YMMV > > > > > > Bert > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:07:53 +0000 From: "Jonathan Lang" To: "'Kireeti Kompella'" , Subject: RE: Proposed change to LMP Link Verification draft Date: Tue, 13 May 2003 09:07:24 -0700 Message-ID: <000901c31969$be1b3360$6801000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kireeti, Agree with above change. -Jonathan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, May 11, 2003 11:28 PM > To: ccamp@ops.ietf.org > Subject: Proposed change to LMP Link Verification draft > > > Hi All, > > | Based on information contained in the ITU and T1X1 liaison, > as well as > | subsequent e-mail exchanges on the CCAMP mailing list, and > in order to > | ensure proper interoperability in legacy SDH/SONET networks > as well as > | networks in which G.7714.1 is deployed, it will be > recommended by the > | editors to the CCAMP community to support only the Jx trace > | correlation procedure and not the in-band Jx procedure. > > Please respond with one of the following: > - Agree with above change; OR > - Don't agree with above change [i.e., keep in-band Jx > procedure as is]. > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 16:07:44 +0000 From: "Jonathan Lang" To: "'Kireeti Kompella'" , Cc: , "'Wijnen, Bert \(Bert\)'" , "'Ron Bonica \(E-mail\)'" , Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Tue, 13 May 2003 09:06:54 -0700 Message-ID: <000801c31969$aca39cd0$6801000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kireeti, Fine, send it as is. -Jonathan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, May 11, 2003 11:23 PM > To: ccamp@ops.ietf.org > Cc: sob@harvard.edu; Wijnen, Bert (Bert); Ron Bonica > (E-mail); zinin@psg.com > Subject: RE: Proposed response to the Liaison Statement on > LMP Link Verifi cation > > > Hi All, > > On Tue, 29 Apr 2003, Kireeti Kompella wrote: > > > I will formulate a liaison statement in reply to T1X1 regarding > > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. > > Sorry for the tardy follow-up. Here is the proposed response. > > Please send your replies to the list (if you wish to reply > privately, include the Liaison Coordinator and the ADs in your reply). > > Ideally, your reply should say one of: > - "Fine, send it as is"; OR > - "Please make the following changes", with _specific text_; OR > - "Do not send this response". > > Please respond by COB Friday, May 16th. > > Kireeti. > ============================================================== > ========= > > Dear Mr. Biholar, > > Regarding the following liaison: > > TITLE: Liaison from T1X1 to IETF ccamp regarding > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt > TO: IETF ccamp Working Group > CC: ITU-T Q.14/15 (for information) > SOURCE*: T1X1 > FOR: Action > DEADLINE: 9 June 2003 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic > Interconnection > > We thank the T1X1 and the ITU-T for their review and the > incorporation of the LMP Test procedure into G.7714.1. > > Based on information contained in the ITU and T1X1 liaison, > as well as subsequent e-mail exchanges on the CCAMP mailing > list, and in order to ensure proper interoperability in > legacy SDH/SONET networks as well as networks in which > G.7714.1 is deployed, it will be recommended by the editors > to the CCAMP community to support only the Jx trace > correlation procedure and not the in-band Jx procedure. > Pending agreement, the draft will be updated. > > See inline for more detailed responses to specific points. > > > Context of Application Space > > > > > It is currently our understanding that the use case > > scenario for which this procedure is applied encompasses > > both transport plane connectivity verification as well as > correlation > > of these entities with the control plane. ITU-T G.7714.1 is > focused on > > discovering the transport plane link connection end point > > relationships and verifying their connectivity. > > This Recommendation defines two procedures for performing > > the connectivity verification function, one of which > > utilizes either the Jx or the DCC bytes of the server > > signal (termed "in-service"). The other approach in > > G.7714.1, termed as "out of service", corresponds to > > inserting a test signal in the payload of the server > > signal. Based on an analysis of the data link state > > definitions in draft-ietf-ccamp-lmp-08.txt, we understand > > that the approach defined in the LMP test for physical > > connectivity occurs in the context of the "out of service" > > state (as described in G.7714.1). > > > > Please confirm this. > > The subject document uses the Jx or DCC bytes to perform the > LMP Test procedure, but the The LMP Test procedure is done as > part of GMPLS link intialization, prior to the link being > available to carry user traffic. > > > Usage of Jx Bytes > > > > In defining the Jx bytes within G.7714.1, the following > > was taken into account: > > 1. One consideration involved the case where the Discovery Agent is > > located in an external system, and an external interface is used by > > the Network Element to provision and receive the Trail > Trace message. > > As an existing text- oriented Man-Machine Language, such as > TL1, may > > be reused to provide this interface, it was decided that the > > discovery message be limited to printable characters. > > Specifically, the TTI characters should be limited to > > printable characters as per T.50 with trailing NULLs or > > SPACEs. Use of arbitrary bit patterns in the lower 7 bits > > of each byte could prematurely terminate the pattern or > > trigger fault notification for certain hardware or > > software implementations. The strategy chosen in G.7714.1 > > avoids the danger by limiting the information content of > > each byte to 6 bits (84 bits total) and uses a base 64 > > coding according to RFC2045 to place the information in > > the available bits. > > The LMP test procedure described in the subject document > defines two usages of the Jx bytes. The first is termed the > 'trace correlation transport mechanism' and it treats the Jx > bytes as an opaque bit stream. > > This usage is completely consistent with the above. GMPLS > identifiers are typically 32 bit numbers and as such are not > printable characters. In networks that do not require that > the Jx bytes be printable, it is also possible to carry the > GMPLS identifiers directly in the Jx bytes. This is termed > the 'Jx transport mechanism'. > > > 2. Another consideration involved providing a means for > distinguishing > > this use of the Jx bytes from the traditional use for Trail Trace > > identifiers in new equipments. As a result, G.7714.1 includes a > > distinguishing character ("+") as the first non-CRC byte > > that will never appear as the first character of a TTI. > > This requires modification of the trail termination > > functions to prevent the raising of TTI mismatch > > alarms during the connectivity verification process. > > The selection of which LMP transport mechanism use in the LMP > Test procedure for a given link as well as the time at which > the Jx bytes are to be used for the LMP Test procedure is > under control of the GMPLS nodes at either end of the link, > so it is well understood by those nodes. It is our > understanding, per G.806 section 6.1, that the LMP Test > procedure would be performed when the link is in the NMON > (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > > > While the context for testing the transport plane connectivity is > > different between the two documents, they both use the Jx > bytes of the > > server signal, and we invite the IETF to determine the > appropriateness > > of the above aspects in their test signal definitions. > > The trace correlation transport mechanism is completely > consistent with this. The JX transport mechanism requires > additional identifiers (i.e., the Verify ID). > > > Even if these considerations are not relevant to this > context, it will > > be necessary to augment G.783 equipment functions to recognize this > > new usage of Jx messages. > > We would be happy to provide assistance to T1X1/ITU-T in > augmenting G.783 equipment functions to recognize the > additional capability for supporting GMPLS networking elements. > > > Required Updates to SDH Equipment Specifications > > > > SDH equipment specifications as they currently exist > reflect the usage > > of the Jx bytes prior to the development of G.7714.1. ITU-T Study > > Group 15 has as a work item to revise these equipment functions to > > include support for these new functions. Specifically, this will > > involve updates to trail termination functions to generate and > > receive the new messages and to avoid unnecessary alarms in > > the case where the new messages are received. In addition, > > non-intrusive monitoring functions will need to be revised > > so that unnecessary alarms are not raised when the > > messages are observed en-route. Whether or not there is > > further alignment between the message formats used in > > G.7714.1 and the subject draft, the new functions to > > support the subject draft will also need to be reflected > > in the atomic functions in G.783. The sending and > > receiving of these messages can be reflected in the trail > > termination functions in a similar way to what we plan to > > do for support of G.7714.1 functions. > > We would be happy to provide assistance to T1X1/ITU-T in > augmenting G.783 equipment functions to recognize the > additional capability for supporting GMPLS networking elements. > > > Terminology Differences > > > > > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > > the "up/free (in-service)" data link state appears to > correspond with > > what G.7714.1 refers to as "out-of- service". This difference in > > terminology has resulted in different interpretations of > the context. > > Explaining the scenarios further in the lmp test document would be > > beneficial in establishing a translation between the > > differing uses of the same terms. Within ITU-T, work is > > being initiated of draft Rec. G.fame, Framework for ASON > > Management, where control plane/management plane > > interactions will be addressed. > > We agree that terminology differences between IETF and ITU-T > wrt GMPLS have been confusing. There is an ongoing effort > within CCAMP to work together with T1X1/ITU-T on bridging the > terminology gaps. For example, there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered > in CCAMP to do this mapping for LMP. > > > Further Study Items > > > > Following are some areas where further contributions are > > requested: > > 1. For SDH equipment functions in G.783, it needs to > > be understood whether the application of the lmp test > > message requires revision of NIM (non-intrusive > > monitoring) functions. The reason for this is that the > > test procedure is initiated between control entities at > > the end-points of the trail, and intermediate points are > > not necessarily aware that the test is taking place. For > G.7714.1, it > > was felt important for any termination or NIM function to easily > > distinguish between the various uses of the Jx bytes. It may be > > necessary for the subject draft to use a similarly easily > recognizable > > format. If no revision to NIM functions is required for > the context > > of this draft, the architecture of the context for this > > application (demonstrating why the NIM functions are not > > required) should be reflected in G.803 and/or G.807/G.8080. > > It is our understanding, per G.806 section 6.1, that > the LMP Test procedure would be performed when the link is in > the NMON (not monitored state), and therefore intermediate > SDH/SONET equipment would not be performing non-intrusive > monitoring. As described, the trace correlation procedure use > of Jx bytes is consistent with the current standards. > > > 2.Determination of whether it would be possible to use the > identical > > message formats in the subject draft as in G.7714.1 for the > > connectivity verification function. > > The trace correlation transport mechanism is completely > consistent with this. The Jx transport mechanism requires > additional identifiers (i.e., the Verify ID). > > > 3.Determination of whether it would be possible to use the same > > overall structure (distinguishing character, 4 bit message type, 80 > > bit message body) if a different message format or > information content > > is required. > > This is certainly possible (not applicable for the trace > correlation procedure). > > > 4.Work is needed to clarify under what > > configurations/states (for example: no VC-n signals > > carrying client traffic) the lmp test message is > > applicable over J0. If the signal can be framed and J0 > > can be recovered, the Regenerator Section is considered > > as "in service" from a transport plane perspective. So unlike the > > J1/J2 case, the application of the lmp test message at the > Regenerator > > Section does not occur in an "out of service" state (from a > transport > > plane perspective). > > Section 6.1 of G.806 refers to a "termination function part > of a trail, which is in the process of set-up" as in the NMON > state. LMP link verification is based on pre-service testing. > Please let us know if we can be of any assistance in > updating the appropriate Recommendations to support the GMPLS > network element LMP capability. This is not applicable for > the trace correlation procedure. > > > 5. Clarification of the usage of transport and control > > names for transport resources in the subject draft, as described in > > G.8080 Amendment > > The trace correlation transport mechanism supports a > separation of the transport and control plane identifiers. > > > 6. Consideration of the ANSI 64-byte J1. > > This was mistakenly deleted from the latest version of the > draft. This will be included in the next version. > > Sincerely, > Kireeti Kompella and Ron Bonica, > Chairs of the CCAMP WG/IETF. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 15:57:59 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B94DA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Drake Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 17:56:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt. > (It's the one you co-authored.) > Aha... OK, that doc still needs approval. We have sort of agreed that we would test-run a document from MPLS WG through the process to see how/if it works. But more to the point, that document is on how we control work brought to the IETF. It does not control how we interact as decent human beings and decent organisations with our counterparts. The ASON specs (including how to do GMPLS for ASON) were done by ITU-T. So we cannot just assume that we need to take over. I do not believe that tha above change-control-procedures are intended to specify how we take away or steal or whatever-term-you-want-use work from other organisations. That is why I suggested the decent communication path in my earlier posting. Bert > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, May 13, 2003 8:11 AM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > > > > > Bert, > > > > > > I thought that we had a process - the post RFC3474 process. > > > > I guess I must have missed that. > > Where is that or what are you referring to? > > > > I also know that some of you do not believe we did send the ASON > > people away... but for me that it what it boiled down to. > > YMMV > > > > Bert > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 15:14:08 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972563@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 08:13:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt. (It's the one you co-authored.) > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 13, 2003 8:11 AM > To: John Drake > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > > > > Bert, > > > > I thought that we had a process - the post RFC3474 process. > > I guess I must have missed that. > Where is that or what are you referring to? > > I also know that some of you do not believe we did send the ASON > people away... but for me that it what it boiled down to. > YMMV > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 15:11:35 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B94A8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Drake Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 17:10:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > Bert, > > I thought that we had a process - the post RFC3474 process. I guess I must have missed that. Where is that or what are you referring to? I also know that some of you do not believe we did send the ASON people away... but for me that it what it boiled down to. YMMV Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:58:07 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972562@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" , Bart.Rousseau@alcatel.be Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 07:57:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, I thought that we had a process - the post RFC3474 process. Why are you inventing another process on the fly? Comments inline. Thanks, John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 13, 2003 7:38 AM > To: Bart.Rousseau@alcatel.be > Cc: ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > AD-hat on. > > Bart writes: > > > > > > Stephen, > > > > I think the point was rather to go back to > > just a single GMPLS spec instead of two (let alone three) > variants... > > > If that is the case, and if we want to do that in IETF CCAMP > (not sure it is part of the current CCAMP charter), > then it seems to me that we (CCAMP) should excercise these steps: > > - send some liason to ITU-T SG 15 to explain that we found that > there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard Based upon Stephen's e-mails, I think the ITU is well aware of this. > - that we think that this is NOT goodness, and that we regret that > we did send the ASON people away a few years back and did not > closely follow their work in ITU This isn't correct. Please review the ccamp minutes from Yokohama. > - that we now believe that we should have worked better together, > - that we would like to explore ways to try and mrege the two > solution back into one common solution See above. > > And then await the response and hope ITU will agree and then see > how the work can be organized. > > > > > Bart > > > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:39:38 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B9484@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bart.Rousseau@alcatel.be Cc: ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 16:38:27 +0200 MIME-Version: 1.0 Content-Type: text/plain AD-hat on. Bart writes: > > > Stephen, > > I think the point was rather to go back to > just a single GMPLS spec instead of two (let alone three) variants... > If that is the case, and if we want to do that in IETF CCAMP (not sure it is part of the current CCAMP charter), then it seems to me that we (CCAMP) should excercise these steps: - send some liason to ITU-T SG 15 to explain that we found that there seems to be a GMPLS (for IETF) and a GMPLS-ASON standard - that we think that this is NOT goodness, and that we regret that we did send the ASON people away a few years back and did not closely follow their work in ITU - that we now believe that we should have worked better together, - that we would like to explore ways to try and mrege the two solution back into one common solution And then await the response and hope ITU will agree and then see how the work can be organized. > > Bart > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:20:01 +0000 From: Bart.Rousseau@alcatel.be Sensitivity: Subject: Re: ASON reqts To: Stephen Trowbridge Cc: Dimitri.Papadimitriou@alcatel.be, John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Message-ID: Date: Tue, 13 May 2003 16:19:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Stephen, I think the point was rather to go back to just a single GMPLS spec instead of two (let alone three) variants... Bart Stephen Trowbridge @ops.ietf.org on 13/05/2003 15:51:54 Sent by: owner-ccamp@ops.ietf.org To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: > as of today we have two flavors "ASON/GMPLS" and "GMPLS" And these two flavors were developed to two sets of requirements. Base GMPLS comes from the requirements of IP networks that happen to use TDM, WDM technologies at the lower layers. The ASON extensions come from the additional requirements of (not necessarily IP) transport networks. I do not believe we have a third set of requirements. Can we please avoid creating a third variant of the protocol? Steve Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:18:27 +0000 Message-ID: <3EC1001C.9070600@alcatel.be> Date: Tue, 13 May 2003 16:24:28 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Varma, Eve L (Eve)" Cc: "'Adrian Farrel'" , Stephen Trowbridge , John Drake , "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed eve, first a clarification that should be made here, a wg item = an item to be work out by the working group (the ccamp wg, in this case) this does not mean that the document ready to become an rfc (or to be reviewed by the iesg or by ad's) i want also to recap here that the scope of this i-d is clearly about the *delta* requirements required from the so-called "gmpls toolbox" in support of ason networks, it does not intend to be a repetition of the architectural document and its amendments as being worked out by the itu-t (see also deborah comment on this) - it is also the intent to generate the interest from the reader in consulting the appropriate references - these principles should be maintained if we want to achieve the expected result a single set of gmpls spec's covering the user community needs thanks for your suggestion (also please take a look at the terminology section) - dimitri. Varma, Eve L (Eve) wrote: > Hi, > > I'll give you one example - clarifications related to the discussion > of domains, interfaces, and reference points, which has been at the > heart of many a discussion. This clarification comes from G.8080 > Amendment 1, and is extremely helpful in understanding the concept > and its applicability. > > Specifically, some additional text is needed to expand upon the > discussion of reference points & domains in the second paragraph of > "Problem Statement", reproduced below: "The ASON control plane > specification is meant to be applicable to different transport > technologies (e.g., SDH/SONET, OTN) in various networking > environments (e.g., inter-carrier, intra-carrier). Also, ASON model > distinguishes reference points (representing points of protocol > information exchange) defined (1) between an administrative domain > and a user (2) between administrative domains and (3) between areas > of the same administrative domain and when needed between control > components (or simply controllers) within areas. A full description > of the ASON terms and relationship between ASON model and GMPLS > protocol suite may be found in [IPO-ASON]." > > The proposed expanded text is as follows: > > "The ASON control plane specification is meant to be applicable to > different transport technologies (e.g., SDH/SONET, OTN) in various > networking environments, and to support a range of business models. > As Automatically Switched Optical Networks (ASONs) are deployed into > new and existing networks, it cannot be assumed that such networks > will be homogeneous (e.g., with respect to transport technologies, > vendors, approach to management/control). This is true even within a > single carrier's network. In order to support deployment of an > optical control plane into a heterogeneous environment, the ASON > model introduces the concept of control domains and associated inter- > and intra-domain reference points. > > A control domain is an architectural construct that provides for > encapsulation and information hiding, with the characteristics of the > control domain identical to those of its constituent architectural > components. The UNI and E-NNI reference points are defined to exist > between control domains, while the I-NNI reference point is defined > as existing within a control domain. The nature of the information > exchanged between control domains across the E-NNI reference point > captures the common semantics of the information exchanged amongst > its constituent components, while allowing for different > representations inside each control domain. The reference points are > realized as interfaces when instantiated by signaling and routing > protocols as appropriate (i.e., no routing information is exchanged > over the UNI reference point). Further description of the ASON model > and GMPLS protocol suite may be found in [IPO-ASON]". > > Eve > > -----Original Message----- From: Adrian Farrel > [mailto:afarrel@movaz.com] Sent: Monday, May 12, 2003 7:09 PM To: > Stephen Trowbridge; John Drake Cc: 'Wijnen, Bert (Bert)'; Kireeti > Kompella; ccamp@ops.ietf.org Subject: Re: ASON reqts > > > >> Back to Bert's original questions: >> >>>>>> - is there or do we see any conflict? >>>>> >> - As Zhi said, this is not (yet) fully aligned with ITU-T >> requirements and should not be advanced to a WG document until it >> is. However, before we do, I think we need to understand why this >> is necessary - see below. > > > Notwithstanding the immediate future of this document (WG or not WG) > I would greatly appreciate a summary of the areas that are deficient. > > > Thanks, Adrian > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:12:00 +0000 Message-ID: <3EC0FE96.4030909@alcatel.be> Date: Tue, 13 May 2003 16:17:58 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Stephen Trowbridge Cc: John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed stephen, john already responded to that question. in brief, RFC3474 beside its technical issues, does not entirely cover all the ason requirements thanks, - dimitri Stephen Trowbridge wrote: > Dimitri, > > Dimitri.Papadimitriou@alcatel.be wrote: > >>as of today we have two flavors "ASON/GMPLS" and "GMPLS" > > > And these two flavors were developed to two sets of requirements. > Base GMPLS comes from the requirements of IP networks that happen > to use TDM, WDM technologies at the lower layers. The ASON > extensions come from the additional requirements of (not necessarily > IP) transport networks. > > I do not believe we have a third set of requirements. Can we please > avoid creating a third variant of the protocol? > > Steve > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 14:06:43 +0000 Message-ID: <3EC0FC38.4000908@marconi.com> Date: Tue, 13 May 2003 10:07:52 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030430 MIME-Version: 1.0 To: IETF CCAMP List Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Oops. Sent this to the wrong list... ----- Original Message ----- From: "David Charlap" To: "IETF PPVPN List" Sent: Monday, May 12, 2003 5:55 PM Subject: Re: ASON reqts > "I have read this document and it is ready to be a CCAMP WG doc" > > There are a few issues that I don't quite understand and/or need > clarification on, but the current vote is WG acceptance, not last-call. > I have no issues with it that would keep it out from the WG. > > -- David Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 13:52:52 +0000 Message-ID: <3EC0F87A.D03A6DA2@lucent.com> Date: Tue, 13 May 2003 07:51:54 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: > as of today we have two flavors "ASON/GMPLS" and "GMPLS" And these two flavors were developed to two sets of requirements. Base GMPLS comes from the requirements of IP networks that happen to use TDM, WDM technologies at the lower layers. The ASON extensions come from the additional requirements of (not necessarily IP) transport networks. I do not believe we have a third set of requirements. Can we please avoid creating a third variant of the protocol? Steve Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 13:42:29 +0000 Message-ID: <3EC0F610.BC525BF1@alcatel.de> Date: Tue, 13 May 2003 15:41:37 +0200 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org, sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit - "Fine, send it as is" Gert On Tue, 29 Apr 2003, Kireeti Kompella wrote: > > > I will formulate a liaison statement in reply to T1X1 regarding > > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. > > Sorry for the tardy follow-up. Here is the proposed response. > > Please send your replies to the list (if you wish to reply privately, > include the Liaison Coordinator and the ADs in your reply). > > Ideally, your reply should say one of: > - "Fine, send it as is"; OR > - "Please make the following changes", with _specific text_; OR > - "Do not send this response". > > Please respond by COB Friday, May 16th. > > Kireeti. > ======================================================================= > > Dear Mr. Biholar, > > Regarding the following liaison: > > TITLE: Liaison from T1X1 to IETF ccamp regarding > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt > TO: IETF ccamp Working Group > CC: ITU-T Q.14/15 (for information) > SOURCE*: T1X1 > FOR: Action > DEADLINE: 9 June 2003 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection > > We thank the T1X1 and the ITU-T for their review and the incorporation > of the LMP Test procedure into G.7714.1. > > Based on information contained in the ITU and T1X1 liaison, as well as > subsequent e-mail exchanges on the CCAMP mailing list, and in order to > ensure proper interoperability in legacy SDH/SONET networks as well as > networks in which G.7714.1 is deployed, it will be recommended by the > editors to the CCAMP community to support only the Jx trace correlation > procedure and not the in-band Jx procedure. Pending agreement, the > draft will be updated. > > See inline for more detailed responses to specific points. > > > Context of Application Space > > > > > It is currently our understanding that the use case > > scenario for which this procedure is applied encompasses > > both transport plane connectivity verification as well as > > correlation of these entities with the control plane. > > ITU-T G.7714.1 is focused on discovering the transport > > plane link connection end point relationships and > > verifying their connectivity. > > This Recommendation defines two procedures for performing > > the connectivity verification function, one of which > > utilizes either the Jx or the DCC bytes of the server > > signal (termed "in-service"). The other approach in > > G.7714.1, termed as "out of service", corresponds to > > inserting a test signal in the payload of the server > > signal. Based on an analysis of the data link state > > definitions in draft-ietf-ccamp-lmp-08.txt, we understand > > that the approach defined in the LMP test for physical > > connectivity occurs in the context of the "out of service" > > state (as described in G.7714.1). > > > > Please confirm this. > > The subject document uses the Jx or DCC bytes to perform the LMP > Test procedure, but the The LMP Test procedure is done as part of > GMPLS link intialization, prior to the link being available to > carry user traffic. > > > Usage of Jx Bytes > > > > In defining the Jx bytes within G.7714.1, the following > > was taken into account: > > 1. One consideration involved the case where the Discovery > > Agent is located in an external system, and an external > > interface is used by the Network Element to provision and > > receive the Trail Trace message. As an existing text- > > oriented Man-Machine Language, such as TL1, may be reused > > to provide this interface, it was decided that the > > discovery message be limited to printable characters. > > Specifically, the TTI characters should be limited to > > printable characters as per T.50 with trailing NULLs or > > SPACEs. Use of arbitrary bit patterns in the lower 7 bits > > of each byte could prematurely terminate the pattern or > > trigger fault notification for certain hardware or > > software implementations. The strategy chosen in G.7714.1 > > avoids the danger by limiting the information content of > > each byte to 6 bits (84 bits total) and uses a base 64 > > coding according to RFC2045 to place the information in > > the available bits. > > The LMP test procedure described in the subject document defines > two usages of the Jx bytes. The first is termed the 'trace > correlation transport mechanism' and it treats the Jx bytes as > an opaque bit stream. > > This usage is completely consistent with the above. GMPLS > identifiers are typically 32 bit numbers and as such are not > printable characters. In networks that do not require that the > Jx bytes be printable, it is also possible to carry the GMPLS > identifiers directly in the Jx bytes. This is termed the 'Jx > transport mechanism'. > > > 2. Another consideration involved providing a means for > > distinguishing this use of the Jx bytes from the > > traditional use for Trail Trace identifiers in new > > equipments. As a result, G.7714.1 includes a > > distinguishing character ("+") as the first non-CRC byte > > that will never appear as the first character of a TTI. > > This requires modification of the trail termination > > functions to prevent the raising of TTI mismatch > > alarms during the connectivity verification process. > > The selection of which LMP transport mechanism use in the LMP Test > procedure for a given link as well as the time at which the Jx > bytes are to be used for the LMP Test procedure is under control of > the GMPLS nodes at either end of the link, so it is well understood > by those nodes. It is our understanding, per G.806 section 6.1, > that the LMP Test procedure would be performed when the link is in > the NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > > > While the context for testing the transport plane > > connectivity is different between the two documents, they > > both use the Jx bytes of the server signal, and we invite > > the IETF to determine the appropriateness of the above > > aspects in their test signal definitions. > > The trace correlation transport mechanism is completely consistent > with this. The JX transport mechanism requires additional > identifiers (i.e., the Verify ID). > > > Even if these considerations are not relevant to this > > context, it will be necessary to augment G.783 equipment > > functions to recognize this new usage of Jx messages. > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > > Required Updates to SDH Equipment Specifications > > > > SDH equipment specifications as they currently exist reflect > > the usage of the Jx bytes prior to the development of > > G.7714.1. ITU-T Study Group 15 has as a work item to > > revise these equipment functions to include support for > > these new functions. Specifically, this will involve > > updates to trail termination functions to generate and > > receive the new messages and to avoid unnecessary alarms in > > the case where the new messages are received. In addition, > > non-intrusive monitoring functions will need to be revised > > so that unnecessary alarms are not raised when the > > messages are observed en-route. Whether or not there is > > further alignment between the message formats used in > > G.7714.1 and the subject draft, the new functions to > > support the subject draft will also need to be reflected > > in the atomic functions in G.783. The sending and > > receiving of these messages can be reflected in the trail > > termination functions in a similar way to what we plan to > > do for support of G.7714.1 functions. > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > > Terminology Differences > > > > > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > > the "up/free (in-service)" data link state appears to > > correspond with what G.7714.1 refers to as "out-of- > > service". This difference in terminology has resulted in > > different interpretations of the context. Explaining the > > scenarios further in the lmp test document would be > > beneficial in establishing a translation between the > > differing uses of the same terms. Within ITU-T, work is > > being initiated of draft Rec. G.fame, Framework for ASON > > Management, where control plane/management plane > > interactions will be addressed. > > We agree that terminology differences between IETF and ITU-T wrt > GMPLS have been confusing. There is an ongoing effort within > CCAMP to work together with T1X1/ITU-T on bridging the terminology > gaps. For example, there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in > CCAMP to do this mapping for LMP. > > > Further Study Items > > > > Following are some areas where further contributions are > > requested: > > 1. For SDH equipment functions in G.783, it needs to > > be understood whether the application of the lmp test > > message requires revision of NIM (non-intrusive > > monitoring) functions. The reason for this is that the > > test procedure is initiated between control entities at > > the end-points of the trail, and intermediate points are > > not necessarily aware that the test is taking place. For > > G.7714.1, it was felt important for any termination or NIM > > function to easily distinguish between the various uses of > > the Jx bytes. It may be necessary for the subject draft > > to use a similarly easily recognizable format. If no > > revision to NIM functions is required for the context of > > this draft, the architecture of the context for this > > application (demonstrating why the NIM functions are not > > required) should be reflected in G.803 and/or G.807/G.8080. > > It is our understanding, per G.806 section 6.1, that > the LMP Test procedure would be performed when the link is in the > NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > As described, the trace correlation procedure use of Jx bytes is > consistent with the current standards. > > > 2.Determination of whether it would be possible to use the > > identical message formats in the subject draft as in > > G.7714.1 for the connectivity verification function. > > The trace correlation transport mechanism is completely consistent > with this. The Jx transport mechanism requires additional > identifiers (i.e., the Verify ID). > > > 3.Determination of whether it would be possible to use the > > same overall structure (distinguishing character, 4 bit > > message type, 80 bit message body) if a different message > > format or information content is required. > > This is certainly possible (not applicable for the trace correlation > procedure). > > > 4.Work is needed to clarify under what > > configurations/states (for example: no VC-n signals > > carrying client traffic) the lmp test message is > > applicable over J0. If the signal can be framed and J0 > > can be recovered, the Regenerator Section is considered > > as "in service" from a transport plane perspective. So > > unlike the J1/J2 case, the application of the lmp test > > message at the Regenerator Section does not occur in an > > "out of service" state (from a transport plane > > perspective). > > Section 6.1 of G.806 refers to a "termination function part of a > trail, which is in the process of set-up" as in the NMON state. > LMP link verification is based on pre-service testing. Please let > us know if we can be of any assistance in updating the appropriate > Recommendations to support the GMPLS network element LMP capability. > This is not applicable for the trace correlation procedure. > > > 5. Clarification of the usage of transport and control > > names for transport resources in the subject draft, as > > described in G.8080 Amendment > > The trace correlation transport mechanism supports a separation of > the transport and control plane identifiers. > > > 6. Consideration of the ANSI 64-byte J1. > > This was mistakenly deleted from the latest version of the draft. > This will be included in the next version. > > Sincerely, > Kireeti Kompella and Ron Bonica, > Chairs of the CCAMP WG/IETF. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 13:38:11 +0000 Message-ID: <3EC0F51E.7648C181@alcatel.de> Date: Tue, 13 May 2003 15:37:34 +0200 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Proposed change to LMP Link Verification draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit agree Gert Kireeti Kompella wrote: > Hi All, > > | Based on information contained in the ITU and T1X1 liaison, as well as > | subsequent e-mail exchanges on the CCAMP mailing list, and in order to > | ensure proper interoperability in legacy SDH/SONET networks as well as > | networks in which G.7714.1 is deployed, it will be recommended by the > | editors to the CCAMP community to support only the Jx trace correlation > | procedure and not the in-band Jx procedure. > > Please respond with one of the following: > - Agree with above change; OR > - Don't agree with above change [i.e., keep in-band Jx procedure as is]. > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 13:38:03 +0000 Message-ID: <3EC0F4E8.E357B151@alcatel.de> Date: Tue, 13 May 2003 15:36:40 +0200 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: Kireeti Kompella CC: "Brungard, Deborah A, ALABS" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, I have read this document and it is ready to be a CCAMP WG doc Moreover I appreciate the ongoing discussion about this document since it shows that we need it as a starting point to come to a common understanding in order to help get the IETF and the ITU working together. Regards Gert Kireeti Kompella wrote: > On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote: > > > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt > > To take things one at a time, it would be very useful to read and comment > on the ASON reqts draft, as this was deemed tremendously important, and > a rich source of misunderstanding and cross-talk; and coming to a common > understanding over this should help get the IETF and the ITU working > together. > > I think it would be very useful to progress this document in a timely > fashion, so I encourage folks to read and comment on it; and perhaps > in a week or two, to check for consensus to progress it. > > > Good reading material for a weekend - > > Agreed, for both documents. > > Thanks, Deborah! > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:42:30 +0000 Message-Id: <4.3.2.7.2.20030513084126.021edb60@pilgrim.cisco.com> Date: Tue, 13 May 2003 08:41:51 -0400 To: Kireeti Kompella From: "Bradford, Richard" Subject: Re: Proposed change to LMP Link Verification draft Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_435032223==_.ALT" --=====================_435032223==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Agree with change. At 11:27 PM 5/11/2003 -0700, Kireeti Kompella wrote: >Hi All, > >| Based on information contained in the ITU and T1X1 liaison, as well as >| subsequent e-mail exchanges on the CCAMP mailing list, and in order to >| ensure proper interoperability in legacy SDH/SONET networks as well as >| networks in which G.7714.1 is deployed, it will be recommended by the >| editors to the CCAMP community to support only the Jx trace correlation >| procedure and not the in-band Jx procedure. > >Please respond with one of the following: > - Agree with above change; OR > - Don't agree with above change [i.e., keep in-band Jx procedure as is]. > >Kireeti. --=====================_435032223==_.ALT Content-Type: text/html; charset="us-ascii" Agree with change.
At 11:27 PM 5/11/2003 -0700, Kireeti Kompella wrote:
Hi All,

| Based on information contained in the ITU and T1X1 liaison, as well as
| subsequent e-mail exchanges on the CCAMP mailing list, and in order to
| ensure proper interoperability in legacy SDH/SONET networks as well as
| networks in which G.7714.1 is deployed, it will be recommended by the
| editors to the CCAMP community to support only the Jx trace correlation
| procedure and not the in-band Jx procedure.

Please respond with one of the following:
 - Agree with above change; OR
 - Don't agree with above change [i.e., keep in-band Jx procedure as is].

Kireeti.

--=====================_435032223==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:29:14 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Tue, 13 May 2003 07:28:50 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A70FE@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMZRiWcI5C6Iej8RbCPIFreG8fZKwABB/Xg From: "Ash, Gerald R (Jerry), ALABS" To: "Varma, Eve L (Eve)" , Cc: "Ash, Gerald R (Jerry), ALABS" > I concur with Zhi that the document is not yet ready to be a=20 > WG document. Not what Zhi said. He said "I'd like a third option: "I have read this = document, and it's almost ready to be a CCAMP doc""=20 > Regarding the explanation of requirements, I am still extremely = puzzled as > to why the IPO requirements document is not being cited as a source of > explanation for a number of ASON-related items. It's almost=20 > as though it never existed. Actually 2 references are given, although the first seems to have = expired: [IPO-ASON] Aboul-Magd (Editor) et al., "Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols," Work in progress, draft-ietf-ipo-ason- 02.txt, March 2002. [IPO-REQS] Y.Xue (Editor) et al., "Optical Network Service Requirements," Work in progress, draft-ietf-ipo- carrier-requirements-05.txt. Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:26:41 +0000 Message-ID: <3EC0E5F6.3060903@alcatel.be> Date: Tue, 13 May 2003 14:32:54 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Ong, Lyndon" Cc: "'Stephen Trowbridge'" , John Drake , "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed lyndon, also some comments in-line... Ong, Lyndon wrote: > Hi Folks, > > I'm hoping that the requirements draft does not imply that > we will now define an alternative to 3474, that was not my > intention when participating in the draft. > I see no reason to rethink what was done in 3474, well i think there where listed in the signalling proposal (take a close look at section 3.1): http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt i am not sure that trying to "impose" a solution that breaks the gmpls common developments is a *good* solution > which has now been > implemented and tested by a number of participants > It would be good to understand if people in the group are > interested in supporting ASON, i think one of the good things that this document delivers is that it clearly states what "ason support means" from the signalling perspective, the abstract of this i-d seems (since so far) to be very clear for the informed reader: "This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality." > however, which seemed to be > a controversial issue on the mailing list a while back. > Also, as Stephen points out, it would be good to get > feedback from ITU SG 15 on the draft, as it does represent > only the authors' interpretation of ASON requirements and > may not be complete. see the response from an itu participant: "The document is very aligned with the ITU work. From an ITU perspective, the document is easy to read. And considering the author list, it's a balanced list of ITU and IETF participants. Following up on Adrian's request, I would be interested to hear from IETF participants. As Kireeti stated, this document is an attempt to bridge the gaps between the IETF and ITU work. Most important for progressing this work is the understanding level/interest by the IETF community involved in GMPLS." but since you're looking for more formal ITU review, you know very well that such things happen much more easily when the i-d as a WG status. thanks, - dimitri. > > Cheers, > > Lyndon > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Monday, May 12, 2003 3:23 PM > To: John Drake > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > John, > Ahhhh.... > This sounds like a whole new can of worms. The goal therefore does > seem to be to develop yet another protocol solution, and I think > we need to be VERY careful before taking this kind of step. > > Your assertion now seems to be that RFC 3473+3474 does NOT meet the > ASON requirements. If this is the case: > - Does G.7713.2 meet the requirements, and we missed something in > the translation to RFC 3474? If so, then we need to supercede > RFC 3474 with a better translation, not start over. > > - Do you think that even G.7713.2 does not meet the requirements? > If you believe this to be the case, it seems like the obvious > first step would be to inform ITU-T - after all, this is where > the ASON requirements came from and it makes no sense to start > a new protocol without fixing (and aligning) G.7713.2. > > If we made a mistake, lets fix it, but lets NOT start proliferating > ASON extensions take 2; ASON extensions take 3; ... > > Regards, > Steve > > John Drake wrote: > >>I think that the problem is that RFC 3474, in addition to its technical >>issues, doesn't address all of the ASON requirements. For example, it does >>not address full call/connection separation. So we're following the post >>3474 procees of documenting the ASON requirements relevant to GMPLS >>signalling in order to have a common understanding of what problem is to be >>solved. >> >> >>>-----Original Message----- >>>From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] >>>Sent: Monday, May 12, 2003 2:27 PM >>>To: John Drake >>>Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: ASON reqts >>> >>> >>>Bert & John, >>>I think this document has nothing to do with the issue Bert >>>mentioned. This was a protocol issue, not a requirements issue. >>>A decision was made to leave the message out of 3474 with the >>>belief that: >>>- The protocol works without it; and >>>- The presence of the message violates the protocol. >>>The appropriate next step here would be a liaison back to ITU-T >>>explaining what was done and why, and if the ITU-T agrees with >>>the reasoning, they can align their protocol document (in this >>>case, G.7713.2). >>> >>>Back to Bert's original questions: >>> >>>>>>>- is there or do we see any conflict? >>>>>> >>>- As Zhi said, this is not (yet) fully aligned with ITU-T requirements >>> and should not be advanced to a WG document until it is. >>>However, before >>> we do, I think we need to understand why this is necessary >>>- see below. >>> >>> >>>>>>>- are we duplicating some work? >>>>>> >>>- Almost certainly. If we take the kind of alignment with ITU-T >>> requirements that Zhi mentions as a "gate" for progressing >>>this, then >>> what is in this document that is different from G.8080 and >>>G.7713 and >>> why do we need this in place of a normative reference? >>> >>> >>>>>>>- what is the purpose of this draft? >>>>>> >>>Excellent question. >>> >>>>>>> - is it after the fact documenting of requirements? >>>>>> >>>If it is, why bother? Also, we already have the requirements >>>(developed >>>before the protocol) in G.8080 and G.7713. >>> >>> >>>>>>> - is it getting ITU-T documented requirements in RFC form? >>>>>> >>>This could be a reasonable goal, if this document is to be an info >>>track requirements document characterizing G.8080 and G.7713 for >>>IETF folks in the same way that RFC 3474 does for G.7713.2 and >>>RFC 3475 does for G.7713.3. But it is hard to understand why producing >>>an IETF translation of the ITU-T question would be very high priority >>>when we already have an IETF translation of the answer, but >>>fundamentally >>>there would be no problem if this were the objective. >>> >>> >>>>>>> - is it extending ITU-T documented requirements? >>>>>> >>>I don't think so. If it is, I hope we start with a liaison rather >>>than trying to extend ITU-T requirements without talking to >>>ITU-T first. >>> >>> >>>>>>> - is it contrdicting them? >>>>>> >>>This is my biggest worry. I don't think we should start the process >>>over again and open the door that we come up with yet another >>>protocol solution to address the same requirements. Vendors are >>>already building to G.7713.2, G.7713.3 (and by extension, to >>>RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT >>>start a new work item with an objective to develop a new protocol >>>solution to the same problem. >>> >>> >>>>>>> - is it meant to be used as communication to ITU? >>>>>> >>>I haven't seen this proposed, but I think that if the goal is >>>to capture ITU-T requirements in RFC form, it would be a good >>>idea to ask ITU-T whether the proposed document accurately >>>captures their requirements. >>> >>>/Steve >>> >>> >>>John Drake wrote: >>> >>>>Bert, >>>> >>>>I think so. >>>> >>>>Thanks, >>>> >>>>John >>>> >>>> >>>>>-----Original Message----- >>>>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>>>>Sent: Monday, May 12, 2003 1:27 PM >>>>>To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>>>>Subject: RE: ASON reqts >>>>> >>>>> >>>>>I know that some people had issues with the way that ITU-T >>>>>had defined the RSVP-TE extensions for ASON. In fact there >>>>>was/is a claim that it is broken. So we removed the offending >>>>>text from the RFC3474. >>>>> >>>>>The next thing we were going to do (as far as I understood it) >>>>>is to document why we (or some of us in IETF) think that the >>>>>ITU-T solution is broken, potentially with suggested fixes. >>>>>That we would send to ITU-T SG15. >>>>> >>>>>Is this the first step of that process? >>>>> >>>>>Thanks, >>>>>Bert >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: John Drake [mailto:jdrake@calient.net] >>>>>>Sent: maandag 12 mei 2003 22:24 >>>>>>To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org >>>>>>Subject: RE: ASON reqts >>>>>> >>>>>> >>>>>>Bert, >>>>>> >>>>>>I thought that the post 3474/3475 process started with a >>>>> >>>>>requirements >>>>> >>>>>>document. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>John >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>>>>>>Sent: Monday, May 12, 2003 1:14 PM >>>>>>>To: Kireeti Kompella; ccamp@ops.ietf.org >>>>>>>Subject: RE: ASON reqts >>>>>>> >>>>>>> >>>>>>>So if we look at RFCs 3474/3475 and the ITU-T documents >>>>>>>that those 2 RFCs point to, then I wonder: >>>>>>>- is there or do we see any conflict? >>>>>>>- are we duplicating some work? >>>>>>>- what is the purpose of this draft? >>>>>>> - is it after the fact documenting of requirements? >>>>>>> - is it getting ITU-T documented requirements in RFC form? >>>>>>> - is it extending ITU-T documented requirements? >>>>>>> - is it contrdicting them? >>>>>>> - is it meant to be used as communication to ITU? >>>>>>> >>>>>>>Just wondering what is happening here. >>>>>>> >>>>>>>Thanks, >>>>>>>Bert >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>>>>>>>Sent: maandag 12 mei 2003 17:25 >>>>>>>>To: ccamp@ops.ietf.org >>>>>>>>Subject: Re: ASON reqts >>>>>>>> >>>>>>>> >>>>>>>>Hi All, >>>>>>>> >>>>>>>>On Fri, 2 May 2003, Kireeti Kompella wrote: >>>>>>>> >>>>>>>> >>>>>>>>>To take things one at a time, it would be very useful to >>>>>>>> >>>>>>>>read and comment >>>>>>>> >>>>>>>>>on the ASON reqts draft, as this was deemed tremendously >>>>>>>> >>>>>>>>important, and >>>>>>>> >>>>>>>>>a rich source of misunderstanding and cross-talk; and >>>>>>>> >>>>>>>>coming to a common >>>>>>>> >>>>>>>>>understanding over this should help get the IETF and the >>>>>>>> >>>>>>>ITU working >>>>>>> >>>>>>>>>together. >>>>>>>> >>>>>>>>I haven't seen many comments, so the assumption is >>>>>>> >>>>>either that no >>>>> >>>>>>>>one cares, or that folks have read it and have no issues. >>>>>>>> >>>>>>>>I'd like to get a reading on whether this doc is >>>>>>> >>>ready to be a >>> >>>>>>>>CCAMP WG document. Please respond (preferably publicly) >>>>>>> >>>>>>>with one of: >>>>>>> >>>>>>>> - "I have read this document and it is ready to be a CCAMP >>>>>>> >>>>>>>WG doc" OR >>>>>>> >>>>>>>> - "I have read this document, and it isn't ready to be a >>>>>>> >>>>>>>CCAMP doc". >>>>>>> >>>>>>>>Note that if there aren't enough responses, the default >>>>>>> >>>>>>>assumption is >>>>>>> >>>>>>>>that the document is either not of interest or not >>>>>>> >>>ready, and in >>> >>>>>>>>either case will not become a CCAMP WG doc. Note too >>>>>>> >>>>>>that this doc >>>>>> >>>>>>>>is an attempt to bridge some gaps between the IETF and >>>>>>> >>>>>the ITU-T, >>>>> >>>>>>>>and as such is fairly important. It would be >>>>>>> >>>useful to give an >>> >>>>>>>>update on its status at the interim T1X1 meeting in June. >>>>>>>> >>>>>>>>Please get your responses in by COB Friday May 16th. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Kireeti. >>>>>>>> >>>>>>> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:23:12 +0000 Message-ID: <3EC0E4FC.3080201@alcatel.be> Date: Tue, 13 May 2003 14:28:44 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: John Drake Cc: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed bert, definitely this is the reason, as stated by the user community ietf'ers (and more generally "operators" and "carriers") they do not want to see many different gmpls implementations with interoperability problems - as of today we have two flavors "ASON/GMPLS" and "GMPLS" (i refer you to some e-mail exchanges end-of-january'03) having such kind of naming differentiation is already a problem for the whole industry (these have been discussed in the ason-req and signalling i-d's under discussions), and thus i think the whole issue boils down now to: "why keeping this distinction is beneficial for the user and developer community ?" ... i don't see since so far any technical argument at all in favor of this approach thanks, - dimitri. John Drake wrote: > Bert, > > I think so. > > Thanks, > > John > > >>-----Original Message----- >>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>Sent: Monday, May 12, 2003 1:27 PM >>To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org >>Subject: RE: ASON reqts >> >> >>I know that some people had issues with the way that ITU-T >>had defined the RSVP-TE extensions for ASON. In fact there >>was/is a claim that it is broken. So we removed the offending >>text from the RFC3474. >> >>The next thing we were going to do (as far as I understood it) >>is to document why we (or some of us in IETF) think that the >>ITU-T solution is broken, potentially with suggested fixes. >>That we would send to ITU-T SG15. >> >>Is this the first step of that process? >> >>Thanks, >>Bert >> >> >>>-----Original Message----- >>>From: John Drake [mailto:jdrake@calient.net] >>>Sent: maandag 12 mei 2003 22:24 >>>To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: RE: ASON reqts >>> >>> >>>Bert, >>> >>>I thought that the post 3474/3475 process started with a >> >>requirements >> >>>document. >>> >>>Thanks, >>> >>>John >>> >>> >>>>-----Original Message----- >>>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>>>Sent: Monday, May 12, 2003 1:14 PM >>>>To: Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: RE: ASON reqts >>>> >>>> >>>>So if we look at RFCs 3474/3475 and the ITU-T documents >>>>that those 2 RFCs point to, then I wonder: >>>>- is there or do we see any conflict? >>>>- are we duplicating some work? >>>>- what is the purpose of this draft? >>>> - is it after the fact documenting of requirements? >>>> - is it getting ITU-T documented requirements in RFC form? >>>> - is it extending ITU-T documented requirements? >>>> - is it contrdicting them? >>>> - is it meant to be used as communication to ITU? >>>> >>>>Just wondering what is happening here. >>>> >>>>Thanks, >>>>Bert >>>> >>>> >>>>>-----Original Message----- >>>>>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>>>>Sent: maandag 12 mei 2003 17:25 >>>>>To: ccamp@ops.ietf.org >>>>>Subject: Re: ASON reqts >>>>> >>>>> >>>>>Hi All, >>>>> >>>>>On Fri, 2 May 2003, Kireeti Kompella wrote: >>>>> >>>>> >>>>>>To take things one at a time, it would be very useful to >>>>> >>>>>read and comment >>>>> >>>>>>on the ASON reqts draft, as this was deemed tremendously >>>>> >>>>>important, and >>>>> >>>>>>a rich source of misunderstanding and cross-talk; and >>>>> >>>>>coming to a common >>>>> >>>>>>understanding over this should help get the IETF and the >>>>> >>>>ITU working >>>> >>>>>>together. >>>>> >>>>>I haven't seen many comments, so the assumption is >>>> >>either that no >> >>>>>one cares, or that folks have read it and have no issues. >>>>> >>>>>I'd like to get a reading on whether this doc is ready to be a >>>>>CCAMP WG document. Please respond (preferably publicly) >>>> >>>>with one of: >>>> >>>>> - "I have read this document and it is ready to be a CCAMP >>>> >>>>WG doc" OR >>>> >>>>> - "I have read this document, and it isn't ready to be a >>>> >>>>CCAMP doc". >>>> >>>>>Note that if there aren't enough responses, the default >>>> >>>>assumption is >>>> >>>>>that the document is either not of interest or not ready, and in >>>>>either case will not become a CCAMP WG doc. Note too >>>> >>>that this doc >>> >>>>>is an attempt to bridge some gaps between the IETF and >>>> >>the ITU-T, >> >>>>>and as such is fairly important. It would be useful to give an >>>>>update on its status at the interim T1X1 meeting in June. >>>>> >>>>>Please get your responses in by COB Friday May 16th. >>>>> >>>>>Thanks, >>>>>Kireeti. >>>>> >>>> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:23:02 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143CB@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Varma, Eve L (Eve)" Cc: "'Adrian Farrel'" , Stephen Trowbridge , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 08:21:59 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi, Yes, I saw the reference. But that seems to be the extent of it in actual discussions. Best regards, Eve -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, May 13, 2003 8:27 AM To: Varma, Eve L (Eve) Cc: 'Adrian Farrel'; Stephen Trowbridge; ccamp@ops.ietf.org Subject: Re: ASON reqts eve, please take a closer look at the references: "4. Requirements for Extending Applicability of GMPLS to ASON The applicability statements regarding how the GMPLS suite of protocols may be applied to the ASON architecture can be found in [IPO-ASON] and [IPO-REQS]. [...] [IPO-REQS] Y.Xue (Editor) et al., "Optical Network Service Requirements," Work in progress, draft-ietf-ipo- carrier-requirements-05.txt." thanks, - dimitri. Varma, Eve L (Eve) wrote: > Hi all, > > I concur with Zhi that the document is not yet ready to be a WG document. > > Regarding the explanation of requirements, I am still extremely puzzled as > to why the IPO requirements document is not being cited as a source of > explanation for a number of ASON-related items. It's almost as though it never existed. > > Best regards, > Eve > > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Monday, May 12, 2003 6:53 PM > To: Stephen Trowbridge; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > >>John, >>Ahhhh.... >>This sounds like a whole new can of worms. The goal therefore does >>seem to be to develop yet another protocol solution, and I think >>we need to be VERY careful before taking this kind of step. > > > Steve, > As one of the authors this is not my goal. > It may transpire that this is a necessity, but it is not a goal. > I apologise if anything I said gave rise to the false impression you have > garnered. > > One of the problems from an IETF-participant viewpoint is/was that the > requirements were not clear to me. If they weren't clear to me this may because > - they were not readily accessible to me within the IETF > - they were not couched in terms and formats with which I am familiar > - I am a dunderhead. > > Only with the requirements clearly stated (in a form I can grok) is it possible > for me to decide whether existing solutions are adequate. > > So the requirements draft is written and ITU-aware people are asked to comment > on whether this seems to them a fair representation of the requirements coming > out of the ITU. > > OK up to this point? > > The next step, is the analysis of whether the requirements have already been > met. > A subsequent draft has been written to identify how the signaling requirements > are or are not met by existing protocols : > draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt > Where they are already met, the draft simply points out to another draft. > Where they are not met, the draft explains the short-comings and offers > solutions. > > This *second* draft I would expect to be the one that causes heart-burn. It is > with the second draft that we can take issue - does it solve the problems? is it > correct when it says other solutions are broken? etc. But the second draft is > still in an early stage and is not being proposed for WG adoption (although we > would still welcome comments on it). > > >>Your assertion now seems to be that RFC 3473+3474 does NOT meet the >>ASON requirements. If this is the case: >>- Does G.7713.2 meet the requirements, and we missed something in >> the translation to RFC 3474? If so, then we need to supercede >> RFC 3474 with a better translation, not start over. > > > Cannot answer this without an agreement on the requirements. > > >>- Do you think that even G.7713.2 does not meet the requirements? > > > Ditto. > > >> If you believe this to be the case, it seems like the obvious >> first step would be to inform ITU-T - after all, this is where >> the ASON requirements came from and it makes no sense to start >> a new protocol without fixing (and aligning) G.7713.2. > > > It would certainly make sense to take the ASON reqts draft to ITU-T to formally > request that they confirm that it is a full documentation of the requirements. I > don't suppose Kireeti can do this unless the draft is a WG draft. > > >>If we made a mistake, lets fix it, but lets NOT start proliferating >>ASON extensions take 2; ASON extensions take 3; ... > > > Depends on the scale of the mistake? > Can we do the analysis step by step and discover what (if anything) needs to be > done? > First step - check we're all in synch on the requirements. > > Cheers, > Adrian > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:22:13 +0000 From: Bart.Rousseau@alcatel.be Sensitivity: Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation To: Kireeti Kompella Cc: ccamp@ops.ietf.org, sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , zinin@psg.com Message-ID: Date: Tue, 13 May 2003 14:21:02 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Fine, send it as is. Bart. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:21:46 +0000 Message-ID: <3EC0E49D.6010400@alcatel.be> Date: Tue, 13 May 2003 14:27:09 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Varma, Eve L (Eve)" Cc: "'Adrian Farrel'" , Stephen Trowbridge , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed eve, please take a closer look at the references: "4. Requirements for Extending Applicability of GMPLS to ASON The applicability statements regarding how the GMPLS suite of protocols may be applied to the ASON architecture can be found in [IPO-ASON] and [IPO-REQS]. [...] [IPO-REQS] Y.Xue (Editor) et al., "Optical Network Service Requirements," Work in progress, draft-ietf-ipo- carrier-requirements-05.txt." thanks, - dimitri. Varma, Eve L (Eve) wrote: > Hi all, > > I concur with Zhi that the document is not yet ready to be a WG document. > > Regarding the explanation of requirements, I am still extremely puzzled as > to why the IPO requirements document is not being cited as a source of > explanation for a number of ASON-related items. It's almost as though it never existed. > > Best regards, > Eve > > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Monday, May 12, 2003 6:53 PM > To: Stephen Trowbridge; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > >>John, >>Ahhhh.... >>This sounds like a whole new can of worms. The goal therefore does >>seem to be to develop yet another protocol solution, and I think >>we need to be VERY careful before taking this kind of step. > > > Steve, > As one of the authors this is not my goal. > It may transpire that this is a necessity, but it is not a goal. > I apologise if anything I said gave rise to the false impression you have > garnered. > > One of the problems from an IETF-participant viewpoint is/was that the > requirements were not clear to me. If they weren't clear to me this may because > - they were not readily accessible to me within the IETF > - they were not couched in terms and formats with which I am familiar > - I am a dunderhead. > > Only with the requirements clearly stated (in a form I can grok) is it possible > for me to decide whether existing solutions are adequate. > > So the requirements draft is written and ITU-aware people are asked to comment > on whether this seems to them a fair representation of the requirements coming > out of the ITU. > > OK up to this point? > > The next step, is the analysis of whether the requirements have already been > met. > A subsequent draft has been written to identify how the signaling requirements > are or are not met by existing protocols : > draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt > Where they are already met, the draft simply points out to another draft. > Where they are not met, the draft explains the short-comings and offers > solutions. > > This *second* draft I would expect to be the one that causes heart-burn. It is > with the second draft that we can take issue - does it solve the problems? is it > correct when it says other solutions are broken? etc. But the second draft is > still in an early stage and is not being proposed for WG adoption (although we > would still welcome comments on it). > > >>Your assertion now seems to be that RFC 3473+3474 does NOT meet the >>ASON requirements. If this is the case: >>- Does G.7713.2 meet the requirements, and we missed something in >> the translation to RFC 3474? If so, then we need to supercede >> RFC 3474 with a better translation, not start over. > > > Cannot answer this without an agreement on the requirements. > > >>- Do you think that even G.7713.2 does not meet the requirements? > > > Ditto. > > >> If you believe this to be the case, it seems like the obvious >> first step would be to inform ITU-T - after all, this is where >> the ASON requirements came from and it makes no sense to start >> a new protocol without fixing (and aligning) G.7713.2. > > > It would certainly make sense to take the ASON reqts draft to ITU-T to formally > request that they confirm that it is a full documentation of the requirements. I > don't suppose Kireeti can do this unless the draft is a WG draft. > > >>If we made a mistake, lets fix it, but lets NOT start proliferating >>ASON extensions take 2; ASON extensions take 3; ... > > > Depends on the scale of the mistake? > Can we do the analysis step by step and discover what (if anything) needs to be > done? > First step - check we're all in synch on the requirements. > > Cheers, > Adrian > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 12:08:20 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143C8@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Adrian Farrel'" , Stephen Trowbridge , John Drake Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 08:07:24 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi, I'll give you one example - clarifications related to the discussion of domains, interfaces, and reference points, which has been at the heart of many a discussion. This clarification comes from G.8080 Amendment 1, and is extremely helpful in understanding the concept and its applicability. Specifically, some additional text is needed to expand upon the discussion of reference points & domains in the second paragraph of "Problem Statement", reproduced below: "The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments (e.g., inter-carrier, intra-carrier). Also, ASON model distinguishes reference points (representing points of protocol information exchange) defined (1) between an administrative domain and a user (2) between administrative domains and (3) between areas of the same administrative domain and when needed between control components (or simply controllers) within areas. A full description of the ASON terms and relationship between ASON model and GMPLS protocol suite may be found in [IPO-ASON]." The proposed expanded text is as follows: "The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments, and to support a range of business models. As Automatically Switched Optical Networks (ASONs) are deployed into new and existing networks, it cannot be assumed that such networks will be homogeneous (e.g., with respect to transport technologies, vendors, approach to management/control). This is true even within a single carrier's network. In order to support deployment of an optical control plane into a heterogeneous environment, the ASON model introduces the concept of control domains and associated inter- and intra-domain reference points. A control domain is an architectural construct that provides for encapsulation and information hiding, with the characteristics of the control domain identical to those of its constituent architectural components. The UNI and E-NNI reference points are defined to exist between control domains, while the I-NNI reference point is defined as existing within a control domain. The nature of the information exchanged between control domains across the E-NNI reference point captures the common semantics of the information exchanged amongst its constituent components, while allowing for different representations inside each control domain. The reference points are realized as interfaces when instantiated by signaling and routing protocols as appropriate (i.e., no routing information is exchanged over the UNI reference point). Further description of the ASON model and GMPLS protocol suite may be found in [IPO-ASON]". Eve -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Monday, May 12, 2003 7:09 PM To: Stephen Trowbridge; John Drake Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: ASON reqts > Back to Bert's original questions: > > > > > - is there or do we see any conflict? > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > and should not be advanced to a WG document until it is. However, before > we do, I think we need to understand why this is necessary - see below. Notwithstanding the immediate future of this document (WG or not WG) I would greatly appreciate a summary of the areas that are deficient. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 11:51:27 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F143C5@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Adrian Farrel'" , Stephen Trowbridge , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Tue, 13 May 2003 07:50:40 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi all, I concur with Zhi that the document is not yet ready to be a WG document. Regarding the explanation of requirements, I am still extremely puzzled as to why the IPO requirements document is not being cited as a source of explanation for a number of ASON-related items. It's almost as though it never existed. Best regards, Eve -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Monday, May 12, 2003 6:53 PM To: Stephen Trowbridge; ccamp@ops.ietf.org Subject: Re: ASON reqts > John, > Ahhhh.... > This sounds like a whole new can of worms. The goal therefore does > seem to be to develop yet another protocol solution, and I think > we need to be VERY careful before taking this kind of step. Steve, As one of the authors this is not my goal. It may transpire that this is a necessity, but it is not a goal. I apologise if anything I said gave rise to the false impression you have garnered. One of the problems from an IETF-participant viewpoint is/was that the requirements were not clear to me. If they weren't clear to me this may because - they were not readily accessible to me within the IETF - they were not couched in terms and formats with which I am familiar - I am a dunderhead. Only with the requirements clearly stated (in a form I can grok) is it possible for me to decide whether existing solutions are adequate. So the requirements draft is written and ITU-aware people are asked to comment on whether this seems to them a fair representation of the requirements coming out of the ITU. OK up to this point? The next step, is the analysis of whether the requirements have already been met. A subsequent draft has been written to identify how the signaling requirements are or are not met by existing protocols : draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt Where they are already met, the draft simply points out to another draft. Where they are not met, the draft explains the short-comings and offers solutions. This *second* draft I would expect to be the one that causes heart-burn. It is with the second draft that we can take issue - does it solve the problems? is it correct when it says other solutions are broken? etc. But the second draft is still in an early stage and is not being proposed for WG adoption (although we would still welcome comments on it). > Your assertion now seems to be that RFC 3473+3474 does NOT meet the > ASON requirements. If this is the case: > - Does G.7713.2 meet the requirements, and we missed something in > the translation to RFC 3474? If so, then we need to supercede > RFC 3474 with a better translation, not start over. Cannot answer this without an agreement on the requirements. > - Do you think that even G.7713.2 does not meet the requirements? Ditto. > If you believe this to be the case, it seems like the obvious > first step would be to inform ITU-T - after all, this is where > the ASON requirements came from and it makes no sense to start > a new protocol without fixing (and aligning) G.7713.2. It would certainly make sense to take the ASON reqts draft to ITU-T to formally request that they confirm that it is a full documentation of the requirements. I don't suppose Kireeti can do this unless the draft is a WG draft. > If we made a mistake, lets fix it, but lets NOT start proliferating > ASON extensions take 2; ASON extensions take 3; ... Depends on the scale of the mistake? Can we do the analysis step by step and discover what (if anything) needs to be done? First step - check we're all in synch on the requirements. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 10:56:52 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B9372@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ron Bonica , ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-tracereq-01.txt Date: Tue, 13 May 2003 12:55:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Looks good to me. Pls submit to internet-drafts. And I will pick it up for IESG agenda again. Did the WG members check it too? Thanks, Bert > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > Sent: dinsdag 13 mei 2003 4:20 > To: Wijnen, Bert (Bert); ccamp@ops.ietf.org > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Bert, > > Here is the ping that you requested. > > Ron > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, April 28, 2003 11:54 PM > > To: Ron Bonica; ccamp@ops.ietf.org; bwijnen@lucent.com > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Thanks... busy with other things now. Will check early next week. > > Pls ping me if I do not answer by say Wed next week. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > > > Sent: maandag 28 april 2003 18:58 > > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > Bert, > > > > > > I have spun a new version of draft-ietf-ccamp-tracereq. It is > > > available at > > > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. > > > Please take a > > > look. > > > > > > If you think that this version addresses the IESG concerns, I > > > will post send > > > it to the draft editor. > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On > > > > Behalf Of Ron Bonica > > > > Sent: Monday, April 21, 2003 5:51 PM > > > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > > > > Bert, > > > > > > > > Sorry to have taken so long to respond. I have been away on > > > vacation. > > > > > > > > Comments inline..... > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On > > > > > Behalf Of Wijnen, Bert (Bert) > > > > > Sent: Wednesday, April 16, 2003 9:30 AM > > > > > To: Ccamp-wg (E-mail) > > > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > > > > > > > Please consider these comments and let me know if they > > > > > wrrant some additional text in the ID. > > > > > > > > > > Thanks, > > > > > Bert > > > > > > > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > > > > > > > Token: Wijnen, Bert > > > > > > Note: New revision Addresses comments. > > > > > > Now on IESG agenda for April 17th > > > > > > Responsible: Bert > > > > > > > > > > 1. this document looks like it might be the union of all the > > > > > "i want it to do " requests. an important part of > > > > > requirements documents is knowing what to not require. > > > > > do they have any? > > > > > > > > This document specifies requirements for a new protocol. It > > > specifies > > > > requirements, primarily, by detailing the required > capabilities of > > > > applications that will use this protocol. The application > > > may implement > > > > some subset of those capabilities. It may also implement a > > > superset of > > > > the required capabilities. However, protocol designers are > > > not required > > > > to consider the additional capabilities when designing > the protocol. > > > > > > > > I can add some text to this effect. > > > > > > > > > 2. i am concerned about the security stuff that > they've buried in > > > > > their requirements. nothing definite. it seems > unwieldy. but > > > > > then, so many security things do... > > > > > > > > Can you be more specific? Is there any particular > requirement that > > > > you feel cannot be implemented? > > > > > > > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > > > > implementation in mind. requirements documents ought not > > > > > specify solutions (eg, 4.2 talks about udp, why can't i use > > > > > icmp?) > > > > > > > > Section 4 provides a few protocol requirements, stated > as such. In > > > > particular, Section 4.1 states that the new protocol > will consist of > > > > probes and responses, and that each probe/response pair > will reveal > > > > information regarding a network hop. (In this respect, the > > > new protocol > > > > will resemble TRACEROUTE). > > > > > > > > Had I remembered to include an application requirement to > > > support partial > > > > traces through broken paths, this requirement would have > > > made much more > > > > sense! > > > > I will fix this. > > > > > > > > Section 4.2 requires that the protocol be implemented over > > > UDP. I included > > > > this > > > > section primarily to rule out implmentations that were _not_ > > > > acceptable. For > > > > example, > > > > ICMP should not be used, because carrying MPLS information > > > over ICMP would > > > > constitute > > > > a layer violation. TCP should not be used, because this would > > > > conflict with > > > > the protocol's > > > > requirement for statelessness. Tunnel specific mechanisms > > > should not be > > > > used, because > > > > this would conflict with the requirement for generality. > > > > > > > > This leaves UDP and IP as the two most resonable candidates. > > > > > > > > I can add some words indicating how we arrived at this decision. > > > > > > > > > 4. justification of requirements might be nice. > > > > > > > > > > > > > I can add a sentence or two after each requirement. > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 09:23:28 +0000 Message-ID: <000c01c318c3$86373440$6801000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: "Jonathan Lang" To: "'Kireeti Kompella'" , Subject: RE: ASON reqts Date: Mon, 12 May 2003 13:17:33 -0700 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Kireeti, I have read this document and it is ready to be a CCAMP WG doc. Thanks, Jonathan > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Monday, May 12, 2003 8:25 AM > To: ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to read and > > comment on the ASON reqts draft, as this was deemed tremendously > > important, and a rich source of misunderstanding and > cross-talk; and > > coming to a common understanding over this should help get the IETF > > and the ITU working together. > > I haven't seen many comments, so the assumption is either > that no one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be > a CCAMP WG document. Please respond (preferably publicly) > with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default > assumption is that the document is either not of interest or > not ready, and in either case will not become a CCAMP WG doc. > Note too that this doc is an attempt to bridge some gaps > between the IETF and the ITU-T, and as such is fairly > important. It would be useful to give an update on its > status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 06:40:20 +0000 Message-ID: <3EC094A0.70605@alcatel.be> Date: Tue, 13 May 2003 08:45:52 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella Cc: ccamp@ops.ietf.org, sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Fine, send it as is. Kireeti Kompella wrote: > Hi All, > > On Tue, 29 Apr 2003, Kireeti Kompella wrote: > > >>I will formulate a liaison statement in reply to T1X1 regarding >>draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. > > > Sorry for the tardy follow-up. Here is the proposed response. > > Please send your replies to the list (if you wish to reply privately, > include the Liaison Coordinator and the ADs in your reply). > > Ideally, your reply should say one of: > - "Fine, send it as is"; OR > - "Please make the following changes", with _specific text_; OR > - "Do not send this response". > > Please respond by COB Friday, May 16th. > > Kireeti. > ======================================================================= > > Dear Mr. Biholar, > > Regarding the following liaison: > > TITLE: Liaison from T1X1 to IETF ccamp regarding > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt > TO: IETF ccamp Working Group > CC: ITU-T Q.14/15 (for information) > SOURCE*: T1X1 > FOR: Action > DEADLINE: 9 June 2003 > PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection > > We thank the T1X1 and the ITU-T for their review and the incorporation > of the LMP Test procedure into G.7714.1. > > Based on information contained in the ITU and T1X1 liaison, as well as > subsequent e-mail exchanges on the CCAMP mailing list, and in order to > ensure proper interoperability in legacy SDH/SONET networks as well as > networks in which G.7714.1 is deployed, it will be recommended by the > editors to the CCAMP community to support only the Jx trace correlation > procedure and not the in-band Jx procedure. Pending agreement, the > draft will be updated. > > See inline for more detailed responses to specific points. > > >>Context of Application Space > > > > >>It is currently our understanding that the use case >>scenario for which this procedure is applied encompasses >>both transport plane connectivity verification as well as >>correlation of these entities with the control plane. >>ITU-T G.7714.1 is focused on discovering the transport >>plane link connection end point relationships and >>verifying their connectivity. >>This Recommendation defines two procedures for performing >>the connectivity verification function, one of which >>utilizes either the Jx or the DCC bytes of the server >>signal (termed "in-service"). The other approach in >>G.7714.1, termed as "out of service", corresponds to >>inserting a test signal in the payload of the server >>signal. Based on an analysis of the data link state >>definitions in draft-ietf-ccamp-lmp-08.txt, we understand >>that the approach defined in the LMP test for physical >>connectivity occurs in the context of the "out of service" >>state (as described in G.7714.1). >> >>Please confirm this. > > > The subject document uses the Jx or DCC bytes to perform the LMP > Test procedure, but the The LMP Test procedure is done as part of > GMPLS link intialization, prior to the link being available to > carry user traffic. > > >>Usage of Jx Bytes >> >>In defining the Jx bytes within G.7714.1, the following >>was taken into account: >>1. One consideration involved the case where the Discovery >>Agent is located in an external system, and an external >>interface is used by the Network Element to provision and >>receive the Trail Trace message. As an existing text- >>oriented Man-Machine Language, such as TL1, may be reused >>to provide this interface, it was decided that the >>discovery message be limited to printable characters. >>Specifically, the TTI characters should be limited to >>printable characters as per T.50 with trailing NULLs or >>SPACEs. Use of arbitrary bit patterns in the lower 7 bits >>of each byte could prematurely terminate the pattern or >>trigger fault notification for certain hardware or >>software implementations. The strategy chosen in G.7714.1 >>avoids the danger by limiting the information content of >>each byte to 6 bits (84 bits total) and uses a base 64 >>coding according to RFC2045 to place the information in >>the available bits. > > > The LMP test procedure described in the subject document defines > two usages of the Jx bytes. The first is termed the 'trace > correlation transport mechanism' and it treats the Jx bytes as > an opaque bit stream. > > This usage is completely consistent with the above. GMPLS > identifiers are typically 32 bit numbers and as such are not > printable characters. In networks that do not require that the > Jx bytes be printable, it is also possible to carry the GMPLS > identifiers directly in the Jx bytes. This is termed the 'Jx > transport mechanism'. > > >>2. Another consideration involved providing a means for >>distinguishing this use of the Jx bytes from the >>traditional use for Trail Trace identifiers in new >>equipments. As a result, G.7714.1 includes a >>distinguishing character ("+") as the first non-CRC byte >>that will never appear as the first character of a TTI. >>This requires modification of the trail termination >>functions to prevent the raising of TTI mismatch >>alarms during the connectivity verification process. > > > The selection of which LMP transport mechanism use in the LMP Test > procedure for a given link as well as the time at which the Jx > bytes are to be used for the LMP Test procedure is under control of > the GMPLS nodes at either end of the link, so it is well understood > by those nodes. It is our understanding, per G.806 section 6.1, > that the LMP Test procedure would be performed when the link is in > the NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > > >>While the context for testing the transport plane >>connectivity is different between the two documents, they >>both use the Jx bytes of the server signal, and we invite >>the IETF to determine the appropriateness of the above >>aspects in their test signal definitions. > > > The trace correlation transport mechanism is completely consistent > with this. The JX transport mechanism requires additional > identifiers (i.e., the Verify ID). > > >>Even if these considerations are not relevant to this >>context, it will be necessary to augment G.783 equipment >>functions to recognize this new usage of Jx messages. > > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > >>Required Updates to SDH Equipment Specifications >> >>SDH equipment specifications as they currently exist reflect >>the usage of the Jx bytes prior to the development of >>G.7714.1. ITU-T Study Group 15 has as a work item to >>revise these equipment functions to include support for >>these new functions. Specifically, this will involve >>updates to trail termination functions to generate and >>receive the new messages and to avoid unnecessary alarms in >>the case where the new messages are received. In addition, >>non-intrusive monitoring functions will need to be revised >>so that unnecessary alarms are not raised when the >>messages are observed en-route. Whether or not there is >>further alignment between the message formats used in >>G.7714.1 and the subject draft, the new functions to >>support the subject draft will also need to be reflected >>in the atomic functions in G.783. The sending and >>receiving of these messages can be reflected in the trail >>termination functions in a similar way to what we plan to >>do for support of G.7714.1 functions. > > > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability > for supporting GMPLS networking elements. > > >>Terminology Differences > > > > >>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, >>the "up/free (in-service)" data link state appears to >>correspond with what G.7714.1 refers to as "out-of- >>service". This difference in terminology has resulted in >>different interpretations of the context. Explaining the >>scenarios further in the lmp test document would be >>beneficial in establishing a translation between the >>differing uses of the same terms. Within ITU-T, work is >>being initiated of draft Rec. G.fame, Framework for ASON >>Management, where control plane/management plane >>interactions will be addressed. > > > We agree that terminology differences between IETF and ITU-T wrt > GMPLS have been confusing. There is an ongoing effort within > CCAMP to work together with T1X1/ITU-T on bridging the terminology > gaps. For example, there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in > CCAMP to do this mapping for LMP. > > >>Further Study Items >> >>Following are some areas where further contributions are >>requested: >>1. For SDH equipment functions in G.783, it needs to >>be understood whether the application of the lmp test >>message requires revision of NIM (non-intrusive >>monitoring) functions. The reason for this is that the >>test procedure is initiated between control entities at >>the end-points of the trail, and intermediate points are >>not necessarily aware that the test is taking place. For >>G.7714.1, it was felt important for any termination or NIM >>function to easily distinguish between the various uses of >>the Jx bytes. It may be necessary for the subject draft >>to use a similarly easily recognizable format. If no >>revision to NIM functions is required for the context of >>this draft, the architecture of the context for this >>application (demonstrating why the NIM functions are not >>required) should be reflected in G.803 and/or G.807/G.8080. > > > It is our understanding, per G.806 section 6.1, that > the LMP Test procedure would be performed when the link is in the > NMON (not monitored state), and therefore intermediate SDH/SONET > equipment would not be performing non-intrusive monitoring. > As described, the trace correlation procedure use of Jx bytes is > consistent with the current standards. > > >>2.Determination of whether it would be possible to use the >>identical message formats in the subject draft as in >>G.7714.1 for the connectivity verification function. > > > The trace correlation transport mechanism is completely consistent > with this. The Jx transport mechanism requires additional > identifiers (i.e., the Verify ID). > > >>3.Determination of whether it would be possible to use the >>same overall structure (distinguishing character, 4 bit >>message type, 80 bit message body) if a different message >>format or information content is required. > > > This is certainly possible (not applicable for the trace correlation > procedure). > > >>4.Work is needed to clarify under what >>configurations/states (for example: no VC-n signals >>carrying client traffic) the lmp test message is >>applicable over J0. If the signal can be framed and J0 >>can be recovered, the Regenerator Section is considered >>as "in service" from a transport plane perspective. So >>unlike the J1/J2 case, the application of the lmp test >>message at the Regenerator Section does not occur in an >>"out of service" state (from a transport plane >>perspective). > > > Section 6.1 of G.806 refers to a "termination function part of a > trail, which is in the process of set-up" as in the NMON state. > LMP link verification is based on pre-service testing. Please let > us know if we can be of any assistance in updating the appropriate > Recommendations to support the GMPLS network element LMP capability. > This is not applicable for the trace correlation procedure. > > >>5. Clarification of the usage of transport and control >>names for transport resources in the subject draft, as >>described in G.8080 Amendment > > > The trace correlation transport mechanism supports a separation of > the transport and control plane identifiers. > > >>6. Consideration of the ANSI 64-byte J1. > > > This was mistakenly deleted from the latest version of the draft. > This will be included in the next version. > > Sincerely, > Kireeti Kompella and Ron Bonica, > Chairs of the CCAMP WG/IETF. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 06:39:48 +0000 From: Bart.Rousseau@alcatel.be Sensitivity: Subject: Re: ASON reqts To: Kireeti Kompella Cc: ccamp@ops.ietf.org Message-ID: Date: Tue, 13 May 2003 08:37:33 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I have read this document and it is ready to be a CCAMP WG doc Bart. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 06:39:37 +0000 Message-ID: <3EC094AC.70508@alcatel.be> Date: Tue, 13 May 2003 08:46:04 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Proposed change to LMP Link Verification draft Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Agree with the above change. Kireeti Kompella wrote: > Hi All, > > | Based on information contained in the ITU and T1X1 liaison, as well as > | subsequent e-mail exchanges on the CCAMP mailing list, and in order to > | ensure proper interoperability in legacy SDH/SONET networks as well as > | networks in which G.7714.1 is deployed, it will be recommended by the > | editors to the CCAMP community to support only the Jx trace correlation > | procedure and not the in-band Jx procedure. > > Please respond with one of the following: > - Agree with above change; OR > - Don't agree with above change [i.e., keep in-band Jx procedure as is]. > > Kireeti. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 05:44:56 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213ECD@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "'Jonathan.Lang@RinconNetworks.com'" Subject: FW: LMP Message ID Date: Tue, 13 May 2003 00:37:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi , Lmp drafts tells that Message ID should be monotonically increasing . Section 7 also tells that "Unacknowledge messages sent with Message_id object should be retransmitted until the message is acknowledged or until retry limit is reached." Do we have to sent all retransmitted messages with the same Message Id as sent previously or it should be in monotonically increasing order. Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 02:23:07 +0000 Date: Mon, 12 May 2003 22:19:43 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq-01.txt To: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Bert, Here is the ping that you requested. Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, April 28, 2003 11:54 PM > To: Ron Bonica; ccamp@ops.ietf.org; bwijnen@lucent.com > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Thanks... busy with other things now. Will check early next week. > Pls ping me if I do not answer by say Wed next week. > > Thanks, > Bert > > > -----Original Message----- > > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > > Sent: maandag 28 april 2003 18:58 > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Bert, > > > > I have spun a new version of draft-ietf-ccamp-tracereq. It is > > available at > > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. > > Please take a > > look. > > > > If you think that this version addresses the IESG concerns, I > > will post send > > it to the draft editor. > > > > Ron > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Ron Bonica > > > Sent: Monday, April 21, 2003 5:51 PM > > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > Bert, > > > > > > Sorry to have taken so long to respond. I have been away on > > vacation. > > > > > > Comments inline..... > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > > Behalf Of Wijnen, Bert (Bert) > > > > Sent: Wednesday, April 16, 2003 9:30 AM > > > > To: Ccamp-wg (E-mail) > > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > > > > Please consider these comments and let me know if they > > > > wrrant some additional text in the ID. > > > > > > > > Thanks, > > > > Bert > > > > > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > > > > > Token: Wijnen, Bert > > > > > Note: New revision Addresses comments. > > > > > Now on IESG agenda for April 17th > > > > > Responsible: Bert > > > > > > > > 1. this document looks like it might be the union of all the > > > > "i want it to do " requests. an important part of > > > > requirements documents is knowing what to not require. > > > > do they have any? > > > > > > This document specifies requirements for a new protocol. It > > specifies > > > requirements, primarily, by detailing the required capabilities of > > > applications that will use this protocol. The application > > may implement > > > some subset of those capabilities. It may also implement a > > superset of > > > the required capabilities. However, protocol designers are > > not required > > > to consider the additional capabilities when designing the protocol. > > > > > > I can add some text to this effect. > > > > > > > 2. i am concerned about the security stuff that they've buried in > > > > their requirements. nothing definite. it seems unwieldy. but > > > > then, so many security things do... > > > > > > Can you be more specific? Is there any particular requirement that > > > you feel cannot be implemented? > > > > > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > > > implementation in mind. requirements documents ought not > > > > specify solutions (eg, 4.2 talks about udp, why can't i use > > > > icmp?) > > > > > > Section 4 provides a few protocol requirements, stated as such. In > > > particular, Section 4.1 states that the new protocol will consist of > > > probes and responses, and that each probe/response pair will reveal > > > information regarding a network hop. (In this respect, the > > new protocol > > > will resemble TRACEROUTE). > > > > > > Had I remembered to include an application requirement to > > support partial > > > traces through broken paths, this requirement would have > > made much more > > > sense! > > > I will fix this. > > > > > > Section 4.2 requires that the protocol be implemented over > > UDP. I included > > > this > > > section primarily to rule out implmentations that were _not_ > > > acceptable. For > > > example, > > > ICMP should not be used, because carrying MPLS information > > over ICMP would > > > constitute > > > a layer violation. TCP should not be used, because this would > > > conflict with > > > the protocol's > > > requirement for statelessness. Tunnel specific mechanisms > > should not be > > > used, because > > > this would conflict with the requirement for generality. > > > > > > This leaves UDP and IP as the two most resonable candidates. > > > > > > I can add some words indicating how we arrived at this decision. > > > > > > > 4. justification of requirements might be nice. > > > > > > > > > > I can add a sentence or two after each requirement. > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 May 2003 00:56:11 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500B3@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Stephen Trowbridge' , John Drake Cc: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 17:58:05 -0700 MIME-Version: 1.0 Content-Type: text/plain Hi Folks, I'm hoping that the requirements draft does not imply that we will now define an alternative to 3474, that was not my intention when participating in the draft. I see no reason to rethink what was done in 3474, which has now been implemented and tested by a number of participants. It would be good to understand if people in the group are interested in supporting ASON, however, which seemed to be a controversial issue on the mailing list a while back. Also, as Stephen points out, it would be good to get feedback from ITU SG 15 on the draft, as it does represent only the authors' interpretation of ASON requirements and may not be complete. Cheers, Lyndon -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Monday, May 12, 2003 3:23 PM To: John Drake Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: ASON reqts John, Ahhhh.... This sounds like a whole new can of worms. The goal therefore does seem to be to develop yet another protocol solution, and I think we need to be VERY careful before taking this kind of step. Your assertion now seems to be that RFC 3473+3474 does NOT meet the ASON requirements. If this is the case: - Does G.7713.2 meet the requirements, and we missed something in the translation to RFC 3474? If so, then we need to supercede RFC 3474 with a better translation, not start over. - Do you think that even G.7713.2 does not meet the requirements? If you believe this to be the case, it seems like the obvious first step would be to inform ITU-T - after all, this is where the ASON requirements came from and it makes no sense to start a new protocol without fixing (and aligning) G.7713.2. If we made a mistake, lets fix it, but lets NOT start proliferating ASON extensions take 2; ASON extensions take 3; ... Regards, Steve John Drake wrote: > > I think that the problem is that RFC 3474, in addition to its technical > issues, doesn't address all of the ASON requirements. For example, it does > not address full call/connection separation. So we're following the post > 3474 procees of documenting the ASON requirements relevant to GMPLS > signalling in order to have a common understanding of what problem is to be > solved. > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Monday, May 12, 2003 2:27 PM > > To: John Drake > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > Bert & John, > > I think this document has nothing to do with the issue Bert > > mentioned. This was a protocol issue, not a requirements issue. > > A decision was made to leave the message out of 3474 with the > > belief that: > > - The protocol works without it; and > > - The presence of the message violates the protocol. > > The appropriate next step here would be a liaison back to ITU-T > > explaining what was done and why, and if the ITU-T agrees with > > the reasoning, they can align their protocol document (in this > > case, G.7713.2). > > > > Back to Bert's original questions: > > > > > > - is there or do we see any conflict? > > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > > and should not be advanced to a WG document until it is. > > However, before > > we do, I think we need to understand why this is necessary > > - see below. > > > > > > > > - are we duplicating some work? > > - Almost certainly. If we take the kind of alignment with ITU-T > > requirements that Zhi mentions as a "gate" for progressing > > this, then > > what is in this document that is different from G.8080 and > > G.7713 and > > why do we need this in place of a normative reference? > > > > > > > > - what is the purpose of this draft? > > Excellent question. > > > > > > - is it after the fact documenting of requirements? > > If it is, why bother? Also, we already have the requirements > > (developed > > before the protocol) in G.8080 and G.7713. > > > > > > > > - is it getting ITU-T documented requirements in RFC form? > > This could be a reasonable goal, if this document is to be an info > > track requirements document characterizing G.8080 and G.7713 for > > IETF folks in the same way that RFC 3474 does for G.7713.2 and > > RFC 3475 does for G.7713.3. But it is hard to understand why producing > > an IETF translation of the ITU-T question would be very high priority > > when we already have an IETF translation of the answer, but > > fundamentally > > there would be no problem if this were the objective. > > > > > > > > - is it extending ITU-T documented requirements? > > I don't think so. If it is, I hope we start with a liaison rather > > than trying to extend ITU-T requirements without talking to > > ITU-T first. > > > > > > > > - is it contrdicting them? > > This is my biggest worry. I don't think we should start the process > > over again and open the door that we come up with yet another > > protocol solution to address the same requirements. Vendors are > > already building to G.7713.2, G.7713.3 (and by extension, to > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > > start a new work item with an objective to develop a new protocol > > solution to the same problem. > > > > > > > > - is it meant to be used as communication to ITU? > > I haven't seen this proposed, but I think that if the goal is > > to capture ITU-T requirements in RFC form, it would be a good > > idea to ask ITU-T whether the proposed document accurately > > captures their requirements. > > > > /Steve > > > > > > John Drake wrote: > > > > > > Bert, > > > > > > I think so. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Monday, May 12, 2003 1:27 PM > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > I know that some people had issues with the way that ITU-T > > > > had defined the RSVP-TE extensions for ASON. In fact there > > > > was/is a claim that it is broken. So we removed the offending > > > > text from the RFC3474. > > > > > > > > The next thing we were going to do (as far as I understood it) > > > > is to document why we (or some of us in IETF) think that the > > > > ITU-T solution is broken, potentially with suggested fixes. > > > > That we would send to ITU-T SG15. > > > > > > > > Is this the first step of that process? > > > > > > > > Thanks, > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: John Drake [mailto:jdrake@calient.net] > > > > > Sent: maandag 12 mei 2003 22:24 > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > Bert, > > > > > > > > > > I thought that the post 3474/3475 process started with a > > > > requirements > > > > > document. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > > that those 2 RFCs point to, then I wonder: > > > > > > - is there or do we see any conflict? > > > > > > - are we duplicating some work? > > > > > > - what is the purpose of this draft? > > > > > > - is it after the fact documenting of requirements? > > > > > > - is it getting ITU-T documented requirements in RFC form? > > > > > > - is it extending ITU-T documented requirements? > > > > > > - is it contrdicting them? > > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > > > Thanks, > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > > To: ccamp@ops.ietf.org > > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > > > To take things one at a time, it would be very useful to > > > > > > > read and comment > > > > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > > > > important, and > > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > > coming to a common > > > > > > > > understanding over this should help get the IETF and the > > > > > > ITU working > > > > > > > > together. > > > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > > either that no > > > > > > > one cares, or that folks have read it and have no issues. > > > > > > > > > > > > > > I'd like to get a reading on whether this doc is > > ready to be a > > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > > with one of: > > > > > > > - "I have read this document and it is ready to be a CCAMP > > > > > > WG doc" OR > > > > > > > - "I have read this document, and it isn't ready to be a > > > > > > CCAMP doc". > > > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > > assumption is > > > > > > > that the document is either not of interest or not > > ready, and in > > > > > > > either case will not become a CCAMP WG doc. Note too > > > > > that this doc > > > > > > > is an attempt to bridge some gaps between the IETF and > > > > the ITU-T, > > > > > > > and as such is fairly important. It would be > > useful to give an > > > > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > > > Thanks, > > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 23:10:20 +0000 Message-ID: <023d01c318db$88222770$681810ac@movaz.com> From: "Adrian Farrel" To: "Stephen Trowbridge" , "John Drake" Cc: "'Wijnen, Bert (Bert)'" , "Kireeti Kompella" , Subject: Re: ASON reqts Date: Mon, 12 May 2003 19:09:25 -0400 > Back to Bert's original questions: > > > > > - is there or do we see any conflict? > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > and should not be advanced to a WG document until it is. However, before > we do, I think we need to understand why this is necessary - see below. Notwithstanding the immediate future of this document (WG or not WG) I would greatly appreciate a summary of the areas that are deficient. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 22:53:39 +0000 Message-ID: <023201c318d9$38414f80$681810ac@movaz.com> From: "Adrian Farrel" To: "Stephen Trowbridge" , Subject: Re: ASON reqts Date: Mon, 12 May 2003 18:52:52 -0400 > John, > Ahhhh.... > This sounds like a whole new can of worms. The goal therefore does > seem to be to develop yet another protocol solution, and I think > we need to be VERY careful before taking this kind of step. Steve, As one of the authors this is not my goal. It may transpire that this is a necessity, but it is not a goal. I apologise if anything I said gave rise to the false impression you have garnered. One of the problems from an IETF-participant viewpoint is/was that the requirements were not clear to me. If they weren't clear to me this may because - they were not readily accessible to me within the IETF - they were not couched in terms and formats with which I am familiar - I am a dunderhead. Only with the requirements clearly stated (in a form I can grok) is it possible for me to decide whether existing solutions are adequate. So the requirements draft is written and ITU-aware people are asked to comment on whether this seems to them a fair representation of the requirements coming out of the ITU. OK up to this point? The next step, is the analysis of whether the requirements have already been met. A subsequent draft has been written to identify how the signaling requirements are or are not met by existing protocols : draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt Where they are already met, the draft simply points out to another draft. Where they are not met, the draft explains the short-comings and offers solutions. This *second* draft I would expect to be the one that causes heart-burn. It is with the second draft that we can take issue - does it solve the problems? is it correct when it says other solutions are broken? etc. But the second draft is still in an early stage and is not being proposed for WG adoption (although we would still welcome comments on it). > Your assertion now seems to be that RFC 3473+3474 does NOT meet the > ASON requirements. If this is the case: > - Does G.7713.2 meet the requirements, and we missed something in > the translation to RFC 3474? If so, then we need to supercede > RFC 3474 with a better translation, not start over. Cannot answer this without an agreement on the requirements. > - Do you think that even G.7713.2 does not meet the requirements? Ditto. > If you believe this to be the case, it seems like the obvious > first step would be to inform ITU-T - after all, this is where > the ASON requirements came from and it makes no sense to start > a new protocol without fixing (and aligning) G.7713.2. It would certainly make sense to take the ASON reqts draft to ITU-T to formally request that they confirm that it is a full documentation of the requirements. I don't suppose Kireeti can do this unless the draft is a WG draft. > If we made a mistake, lets fix it, but lets NOT start proliferating > ASON extensions take 2; ASON extensions take 3; ... Depends on the scale of the mistake? Can we do the analysis step by step and discover what (if anything) needs to be done? First step - check we're all in synch on the requirements. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 22:31:27 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97255F@nimbus> From: John Drake To: 'Stephen Trowbridge' Cc: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 15:30:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Monday, May 12, 2003 3:23 PM > To: John Drake > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > John, > Ahhhh.... > This sounds like a whole new can of worms. The goal therefore does > seem to be to develop yet another protocol solution, and I think > we need to be VERY careful before taking this kind of step. > > Your assertion now seems to be that RFC 3473+3474 does NOT meet the > ASON requirements. JD: Actually that was my position all along. > If this is the case: > - Does G.7713.2 meet the requirements, and we missed something in > the translation to RFC 3474? If so, then we need to supercede > RFC 3474 with a better translation, not start over. JD: Excellent, glad you're on board > > - Do you think that even G.7713.2 does not meet the requirements? > If you believe this to be the case, it seems like the obvious > first step would be to inform ITU-T - after all, this is where > the ASON requirements came from and it makes no sense to start > a new protocol without fixing (and aligning) G.7713.2. > > If we made a mistake, lets fix it, but lets NOT start proliferating > ASON extensions take 2; ASON extensions take 3; ... > > Regards, > Steve > > John Drake wrote: > > > > I think that the problem is that RFC 3474, in addition to > its technical > > issues, doesn't address all of the ASON requirements. For > example, it does > > not address full call/connection separation. So we're > following the post > > 3474 procees of documenting the ASON requirements relevant to GMPLS > > signalling in order to have a common understanding of what > problem is to be > > solved. > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Monday, May 12, 2003 2:27 PM > > > To: John Drake > > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: ASON reqts > > > > > > > > > Bert & John, > > > I think this document has nothing to do with the issue Bert > > > mentioned. This was a protocol issue, not a requirements issue. > > > A decision was made to leave the message out of 3474 with the > > > belief that: > > > - The protocol works without it; and > > > - The presence of the message violates the protocol. > > > The appropriate next step here would be a liaison back to ITU-T > > > explaining what was done and why, and if the ITU-T agrees with > > > the reasoning, they can align their protocol document (in this > > > case, G.7713.2). > > > > > > Back to Bert's original questions: > > > > > > > - is there or do we see any conflict? > > > - As Zhi said, this is not (yet) fully aligned with ITU-T > requirements > > > and should not be advanced to a WG document until it is. > > > However, before > > > we do, I think we need to understand why this is necessary > > > - see below. > > > > > > > > > > - are we duplicating some work? > > > - Almost certainly. If we take the kind of alignment with ITU-T > > > requirements that Zhi mentions as a "gate" for progressing > > > this, then > > > what is in this document that is different from G.8080 and > > > G.7713 and > > > why do we need this in place of a normative reference? > > > > > > > > > > - what is the purpose of this draft? > > > Excellent question. > > > > > > > - is it after the fact documenting of requirements? > > > If it is, why bother? Also, we already have the requirements > > > (developed > > > before the protocol) in G.8080 and G.7713. > > > > > > > > > > - is it getting ITU-T documented requirements > in RFC form? > > > This could be a reasonable goal, if this document is to be an info > > > track requirements document characterizing G.8080 and G.7713 for > > > IETF folks in the same way that RFC 3474 does for G.7713.2 and > > > RFC 3475 does for G.7713.3. But it is hard to understand > why producing > > > an IETF translation of the ITU-T question would be very > high priority > > > when we already have an IETF translation of the answer, but > > > fundamentally > > > there would be no problem if this were the objective. > > > > > > > > > > - is it extending ITU-T documented requirements? > > > I don't think so. If it is, I hope we start with a liaison rather > > > than trying to extend ITU-T requirements without talking to > > > ITU-T first. > > > > > > > > > > - is it contrdicting them? > > > This is my biggest worry. I don't think we should start > the process > > > over again and open the door that we come up with yet another > > > protocol solution to address the same requirements. Vendors are > > > already building to G.7713.2, G.7713.3 (and by extension, to > > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > > > start a new work item with an objective to develop a new protocol > > > solution to the same problem. > > > > > > > > > > - is it meant to be used as communication to ITU? > > > I haven't seen this proposed, but I think that if the goal is > > > to capture ITU-T requirements in RFC form, it would be a good > > > idea to ask ITU-T whether the proposed document accurately > > > captures their requirements. > > > > > > /Steve > > > > > > > > > John Drake wrote: > > > > > > > > Bert, > > > > > > > > I think so. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Monday, May 12, 2003 1:27 PM > > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > I know that some people had issues with the way that ITU-T > > > > > had defined the RSVP-TE extensions for ASON. In fact there > > > > > was/is a claim that it is broken. So we removed the offending > > > > > text from the RFC3474. > > > > > > > > > > The next thing we were going to do (as far as I understood it) > > > > > is to document why we (or some of us in IETF) think that the > > > > > ITU-T solution is broken, potentially with suggested fixes. > > > > > That we would send to ITU-T SG15. > > > > > > > > > > Is this the first step of that process? > > > > > > > > > > Thanks, > > > > > Bert > > > > > > > > > > > -----Original Message----- > > > > > > From: John Drake [mailto:jdrake@calient.net] > > > > > > Sent: maandag 12 mei 2003 22:24 > > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; > ccamp@ops.ietf.org > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > > > I thought that the post 3474/3475 process started with a > > > > > requirements > > > > > > document. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > > > that those 2 RFCs point to, then I wonder: > > > > > > > - is there or do we see any conflict? > > > > > > > - are we duplicating some work? > > > > > > > - what is the purpose of this draft? > > > > > > > - is it after the fact documenting of requirements? > > > > > > > - is it getting ITU-T documented requirements > in RFC form? > > > > > > > - is it extending ITU-T documented requirements? > > > > > > > - is it contrdicting them? > > > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > > > > > Thanks, > > > > > > > Bert > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > > > > > To take things one at a time, it would be > very useful to > > > > > > > > read and comment > > > > > > > > > on the ASON reqts draft, as this was deemed > tremendously > > > > > > > > important, and > > > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > > > coming to a common > > > > > > > > > understanding over this should help get the > IETF and the > > > > > > > ITU working > > > > > > > > > together. > > > > > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > > > either that no > > > > > > > > one cares, or that folks have read it and have > no issues. > > > > > > > > > > > > > > > > I'd like to get a reading on whether this doc is > > > ready to be a > > > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > > > with one of: > > > > > > > > - "I have read this document and it is ready > to be a CCAMP > > > > > > > WG doc" OR > > > > > > > > - "I have read this document, and it isn't > ready to be a > > > > > > > CCAMP doc". > > > > > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > > > assumption is > > > > > > > > that the document is either not of interest or not > > > ready, and in > > > > > > > > either case will not become a CCAMP WG doc. Note too > > > > > > that this doc > > > > > > > > is an attempt to bridge some gaps between the IETF and > > > > > the ITU-T, > > > > > > > > and as such is fairly important. It would be > > > useful to give an > > > > > > > > update on its status at the interim T1X1 > meeting in June. > > > > > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 22:24:26 +0000 Message-ID: <3EC01ED4.839A40F6@lucent.com> Date: Mon, 12 May 2003 16:23:16 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, Ahhhh.... This sounds like a whole new can of worms. The goal therefore does seem to be to develop yet another protocol solution, and I think we need to be VERY careful before taking this kind of step. Your assertion now seems to be that RFC 3473+3474 does NOT meet the ASON requirements. If this is the case: - Does G.7713.2 meet the requirements, and we missed something in the translation to RFC 3474? If so, then we need to supercede RFC 3474 with a better translation, not start over. - Do you think that even G.7713.2 does not meet the requirements? If you believe this to be the case, it seems like the obvious first step would be to inform ITU-T - after all, this is where the ASON requirements came from and it makes no sense to start a new protocol without fixing (and aligning) G.7713.2. If we made a mistake, lets fix it, but lets NOT start proliferating ASON extensions take 2; ASON extensions take 3; ... Regards, Steve John Drake wrote: > > I think that the problem is that RFC 3474, in addition to its technical > issues, doesn't address all of the ASON requirements. For example, it does > not address full call/connection separation. So we're following the post > 3474 procees of documenting the ASON requirements relevant to GMPLS > signalling in order to have a common understanding of what problem is to be > solved. > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Monday, May 12, 2003 2:27 PM > > To: John Drake > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > Bert & John, > > I think this document has nothing to do with the issue Bert > > mentioned. This was a protocol issue, not a requirements issue. > > A decision was made to leave the message out of 3474 with the > > belief that: > > - The protocol works without it; and > > - The presence of the message violates the protocol. > > The appropriate next step here would be a liaison back to ITU-T > > explaining what was done and why, and if the ITU-T agrees with > > the reasoning, they can align their protocol document (in this > > case, G.7713.2). > > > > Back to Bert's original questions: > > > > > > - is there or do we see any conflict? > > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > > and should not be advanced to a WG document until it is. > > However, before > > we do, I think we need to understand why this is necessary > > - see below. > > > > > > > > - are we duplicating some work? > > - Almost certainly. If we take the kind of alignment with ITU-T > > requirements that Zhi mentions as a "gate" for progressing > > this, then > > what is in this document that is different from G.8080 and > > G.7713 and > > why do we need this in place of a normative reference? > > > > > > > > - what is the purpose of this draft? > > Excellent question. > > > > > > - is it after the fact documenting of requirements? > > If it is, why bother? Also, we already have the requirements > > (developed > > before the protocol) in G.8080 and G.7713. > > > > > > > > - is it getting ITU-T documented requirements in RFC form? > > This could be a reasonable goal, if this document is to be an info > > track requirements document characterizing G.8080 and G.7713 for > > IETF folks in the same way that RFC 3474 does for G.7713.2 and > > RFC 3475 does for G.7713.3. But it is hard to understand why producing > > an IETF translation of the ITU-T question would be very high priority > > when we already have an IETF translation of the answer, but > > fundamentally > > there would be no problem if this were the objective. > > > > > > > > - is it extending ITU-T documented requirements? > > I don't think so. If it is, I hope we start with a liaison rather > > than trying to extend ITU-T requirements without talking to > > ITU-T first. > > > > > > > > - is it contrdicting them? > > This is my biggest worry. I don't think we should start the process > > over again and open the door that we come up with yet another > > protocol solution to address the same requirements. Vendors are > > already building to G.7713.2, G.7713.3 (and by extension, to > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > > start a new work item with an objective to develop a new protocol > > solution to the same problem. > > > > > > > > - is it meant to be used as communication to ITU? > > I haven't seen this proposed, but I think that if the goal is > > to capture ITU-T requirements in RFC form, it would be a good > > idea to ask ITU-T whether the proposed document accurately > > captures their requirements. > > > > /Steve > > > > > > John Drake wrote: > > > > > > Bert, > > > > > > I think so. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Monday, May 12, 2003 1:27 PM > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > I know that some people had issues with the way that ITU-T > > > > had defined the RSVP-TE extensions for ASON. In fact there > > > > was/is a claim that it is broken. So we removed the offending > > > > text from the RFC3474. > > > > > > > > The next thing we were going to do (as far as I understood it) > > > > is to document why we (or some of us in IETF) think that the > > > > ITU-T solution is broken, potentially with suggested fixes. > > > > That we would send to ITU-T SG15. > > > > > > > > Is this the first step of that process? > > > > > > > > Thanks, > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: John Drake [mailto:jdrake@calient.net] > > > > > Sent: maandag 12 mei 2003 22:24 > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > Bert, > > > > > > > > > > I thought that the post 3474/3475 process started with a > > > > requirements > > > > > document. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > > that those 2 RFCs point to, then I wonder: > > > > > > - is there or do we see any conflict? > > > > > > - are we duplicating some work? > > > > > > - what is the purpose of this draft? > > > > > > - is it after the fact documenting of requirements? > > > > > > - is it getting ITU-T documented requirements in RFC form? > > > > > > - is it extending ITU-T documented requirements? > > > > > > - is it contrdicting them? > > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > > > Thanks, > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > > To: ccamp@ops.ietf.org > > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > > > To take things one at a time, it would be very useful to > > > > > > > read and comment > > > > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > > > > important, and > > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > > coming to a common > > > > > > > > understanding over this should help get the IETF and the > > > > > > ITU working > > > > > > > > together. > > > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > > either that no > > > > > > > one cares, or that folks have read it and have no issues. > > > > > > > > > > > > > > I'd like to get a reading on whether this doc is > > ready to be a > > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > > with one of: > > > > > > > - "I have read this document and it is ready to be a CCAMP > > > > > > WG doc" OR > > > > > > > - "I have read this document, and it isn't ready to be a > > > > > > CCAMP doc". > > > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > > assumption is > > > > > > > that the document is either not of interest or not > > ready, and in > > > > > > > either case will not become a CCAMP WG doc. Note too > > > > > that this doc > > > > > > > is an attempt to bridge some gaps between the IETF and > > > > the ITU-T, > > > > > > > and as such is fairly important. It would be > > useful to give an > > > > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > > > Thanks, > > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 22:18:15 +0000 Message-Id: <200305122217.h4CMH7u86332@merlot.juniper.net> To: kireeti@juniper.net cc: ccamp@ops.ietf.org Subject: Re: ASON reqts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10329.1052777827.1@juniper.net> Date: Mon, 12 May 2003 15:17:07 -0700 From: Yakov Rekhter > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. I have read this document and it is ready to be a CCAMP WG doc. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:54:22 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97255D@nimbus> From: John Drake To: 'Stephen Trowbridge' Cc: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 14:53:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I think that the problem is that RFC 3474, in addition to its technical issues, doesn't address all of the ASON requirements. For example, it does not address full call/connection separation. So we're following the post 3474 procees of documenting the ASON requirements relevant to GMPLS signalling in order to have a common understanding of what problem is to be solved. > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Monday, May 12, 2003 2:27 PM > To: John Drake > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Bert & John, > I think this document has nothing to do with the issue Bert > mentioned. This was a protocol issue, not a requirements issue. > A decision was made to leave the message out of 3474 with the > belief that: > - The protocol works without it; and > - The presence of the message violates the protocol. > The appropriate next step here would be a liaison back to ITU-T > explaining what was done and why, and if the ITU-T agrees with > the reasoning, they can align their protocol document (in this > case, G.7713.2). > > Back to Bert's original questions: > > > > > - is there or do we see any conflict? > - As Zhi said, this is not (yet) fully aligned with ITU-T requirements > and should not be advanced to a WG document until it is. > However, before > we do, I think we need to understand why this is necessary > - see below. > > > > > > - are we duplicating some work? > - Almost certainly. If we take the kind of alignment with ITU-T > requirements that Zhi mentions as a "gate" for progressing > this, then > what is in this document that is different from G.8080 and > G.7713 and > why do we need this in place of a normative reference? > > > > > > - what is the purpose of this draft? > Excellent question. > > > > > - is it after the fact documenting of requirements? > If it is, why bother? Also, we already have the requirements > (developed > before the protocol) in G.8080 and G.7713. > > > > > > - is it getting ITU-T documented requirements in RFC form? > This could be a reasonable goal, if this document is to be an info > track requirements document characterizing G.8080 and G.7713 for > IETF folks in the same way that RFC 3474 does for G.7713.2 and > RFC 3475 does for G.7713.3. But it is hard to understand why producing > an IETF translation of the ITU-T question would be very high priority > when we already have an IETF translation of the answer, but > fundamentally > there would be no problem if this were the objective. > > > > > > - is it extending ITU-T documented requirements? > I don't think so. If it is, I hope we start with a liaison rather > than trying to extend ITU-T requirements without talking to > ITU-T first. > > > > > > - is it contrdicting them? > This is my biggest worry. I don't think we should start the process > over again and open the door that we come up with yet another > protocol solution to address the same requirements. Vendors are > already building to G.7713.2, G.7713.3 (and by extension, to > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT > start a new work item with an objective to develop a new protocol > solution to the same problem. > > > > > > - is it meant to be used as communication to ITU? > I haven't seen this proposed, but I think that if the goal is > to capture ITU-T requirements in RFC form, it would be a good > idea to ask ITU-T whether the proposed document accurately > captures their requirements. > > /Steve > > > John Drake wrote: > > > > Bert, > > > > I think so. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Monday, May 12, 2003 1:27 PM > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > I know that some people had issues with the way that ITU-T > > > had defined the RSVP-TE extensions for ASON. In fact there > > > was/is a claim that it is broken. So we removed the offending > > > text from the RFC3474. > > > > > > The next thing we were going to do (as far as I understood it) > > > is to document why we (or some of us in IETF) think that the > > > ITU-T solution is broken, potentially with suggested fixes. > > > That we would send to ITU-T SG15. > > > > > > Is this the first step of that process? > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: John Drake [mailto:jdrake@calient.net] > > > > Sent: maandag 12 mei 2003 22:24 > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > Bert, > > > > > > > > I thought that the post 3474/3475 process started with a > > > requirements > > > > document. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: ASON reqts > > > > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > > that those 2 RFCs point to, then I wonder: > > > > > - is there or do we see any conflict? > > > > > - are we duplicating some work? > > > > > - what is the purpose of this draft? > > > > > - is it after the fact documenting of requirements? > > > > > - is it getting ITU-T documented requirements in RFC form? > > > > > - is it extending ITU-T documented requirements? > > > > > - is it contrdicting them? > > > > > - is it meant to be used as communication to ITU? > > > > > > > > > > Just wondering what is happening here. > > > > > > > > > > Thanks, > > > > > Bert > > > > > > > > > > > -----Original Message----- > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > > To: ccamp@ops.ietf.org > > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > > > To take things one at a time, it would be very useful to > > > > > > read and comment > > > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > > > important, and > > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > > coming to a common > > > > > > > understanding over this should help get the IETF and the > > > > > ITU working > > > > > > > together. > > > > > > > > > > > > I haven't seen many comments, so the assumption is > > > either that no > > > > > > one cares, or that folks have read it and have no issues. > > > > > > > > > > > > I'd like to get a reading on whether this doc is > ready to be a > > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > > with one of: > > > > > > - "I have read this document and it is ready to be a CCAMP > > > > > WG doc" OR > > > > > > - "I have read this document, and it isn't ready to be a > > > > > CCAMP doc". > > > > > > > > > > > > Note that if there aren't enough responses, the default > > > > > assumption is > > > > > > that the document is either not of interest or not > ready, and in > > > > > > either case will not become a CCAMP WG doc. Note too > > > > that this doc > > > > > > is an attempt to bridge some gaps between the IETF and > > > the ITU-T, > > > > > > and as such is fairly important. It would be > useful to give an > > > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > > > Thanks, > > > > > > Kireeti. > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:33:11 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97255B@nimbus> From: John Drake To: 'George Swallow' , Zhi-Wei Lin Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 14:32:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Monday, May 12, 2003 2:28 PM > To: Zhi-Wei Lin > Cc: Wijnen, Bert (Bert); Kireeti Kompella; ccamp@ops.ietf.org; > swallow@cisco.com > Subject: Re: ASON reqts > > > > As to what I think is the status, while I agree with many of the > > requirements in the document I believe there's still some > work to be > > done before this becomes a WG document. We've had some fair > amount of > > hashing through of the requirements, and I think many (but > not all) of > > the ASON needs have been reflected. We probably need > another sit-down > > with more ITU folks to make sure that all the critical ASON > > requirements are captured... > > A document does not need to be complete, nor should it be complete to > become a WG document. The purpose of a WG doc is just a baseline of > where the WG is on a topic. Further I think you are in a much better > position to sit down with the ITU if the document has some "official" > standing. So I think it *SHOULD* be a WG document. JD: Exactly right > > ...George > > ps. In case Kireeti has troble reading between the lines: > > "I have read this document and it is ready to be a CCAMP WG doc" > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:28:10 +0000 Message-Id: <200305122127.RAA25389@bifocal.cisco.com> To: Zhi-Wei Lin cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: ASON reqts Date: Mon, 12 May 2003 17:27:30 -0400 From: George Swallow > As to what I think is the status, while I agree with many of the > requirements in the document I believe there's still some work to be > done before this becomes a WG document. We've had some fair amount of > hashing through of the requirements, and I think many (but not all) of > the ASON needs have been reflected. We probably need another sit-down > with more ITU folks to make sure that all the critical ASON > requirements are captured... A document does not need to be complete, nor should it be complete to become a WG document. The purpose of a WG doc is just a baseline of where the WG is on a topic. Further I think you are in a much better position to sit down with the ITU if the document has some "official" standing. So I think it *SHOULD* be a WG document. ...George ps. In case Kireeti has troble reading between the lines: "I have read this document and it is ready to be a CCAMP WG doc" ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:28:04 +0000 Message-ID: <3EC011A9.D62C5364@lucent.com> Date: Mon, 12 May 2003 15:27:05 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bert & John, I think this document has nothing to do with the issue Bert mentioned. This was a protocol issue, not a requirements issue. A decision was made to leave the message out of 3474 with the belief that: - The protocol works without it; and - The presence of the message violates the protocol. The appropriate next step here would be a liaison back to ITU-T explaining what was done and why, and if the ITU-T agrees with the reasoning, they can align their protocol document (in this case, G.7713.2). Back to Bert's original questions: > > > > - is there or do we see any conflict? - As Zhi said, this is not (yet) fully aligned with ITU-T requirements and should not be advanced to a WG document until it is. However, before we do, I think we need to understand why this is necessary - see below. > > > > - are we duplicating some work? - Almost certainly. If we take the kind of alignment with ITU-T requirements that Zhi mentions as a "gate" for progressing this, then what is in this document that is different from G.8080 and G.7713 and why do we need this in place of a normative reference? > > > > - what is the purpose of this draft? Excellent question. > > > > - is it after the fact documenting of requirements? If it is, why bother? Also, we already have the requirements (developed before the protocol) in G.8080 and G.7713. > > > > - is it getting ITU-T documented requirements in RFC form? This could be a reasonable goal, if this document is to be an info track requirements document characterizing G.8080 and G.7713 for IETF folks in the same way that RFC 3474 does for G.7713.2 and RFC 3475 does for G.7713.3. But it is hard to understand why producing an IETF translation of the ITU-T question would be very high priority when we already have an IETF translation of the answer, but fundamentally there would be no problem if this were the objective. > > > > - is it extending ITU-T documented requirements? I don't think so. If it is, I hope we start with a liaison rather than trying to extend ITU-T requirements without talking to ITU-T first. > > > > - is it contrdicting them? This is my biggest worry. I don't think we should start the process over again and open the door that we come up with yet another protocol solution to address the same requirements. Vendors are already building to G.7713.2, G.7713.3 (and by extension, to RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT start a new work item with an objective to develop a new protocol solution to the same problem. > > > > - is it meant to be used as communication to ITU? I haven't seen this proposed, but I think that if the goal is to capture ITU-T requirements in RFC form, it would be a good idea to ask ITU-T whether the proposed document accurately captures their requirements. /Steve John Drake wrote: > > Bert, > > I think so. > > Thanks, > > John > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, May 12, 2003 1:27 PM > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > I know that some people had issues with the way that ITU-T > > had defined the RSVP-TE extensions for ASON. In fact there > > was/is a claim that it is broken. So we removed the offending > > text from the RFC3474. > > > > The next thing we were going to do (as far as I understood it) > > is to document why we (or some of us in IETF) think that the > > ITU-T solution is broken, potentially with suggested fixes. > > That we would send to ITU-T SG15. > > > > Is this the first step of that process? > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: John Drake [mailto:jdrake@calient.net] > > > Sent: maandag 12 mei 2003 22:24 > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > Bert, > > > > > > I thought that the post 3474/3475 process started with a > > requirements > > > document. > > > > > > Thanks, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Monday, May 12, 2003 1:14 PM > > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: ASON reqts > > > > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > > that those 2 RFCs point to, then I wonder: > > > > - is there or do we see any conflict? > > > > - are we duplicating some work? > > > > - what is the purpose of this draft? > > > > - is it after the fact documenting of requirements? > > > > - is it getting ITU-T documented requirements in RFC form? > > > > - is it extending ITU-T documented requirements? > > > > - is it contrdicting them? > > > > - is it meant to be used as communication to ITU? > > > > > > > > Just wondering what is happening here. > > > > > > > > Thanks, > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > > Sent: maandag 12 mei 2003 17:25 > > > > > To: ccamp@ops.ietf.org > > > > > Subject: Re: ASON reqts > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > > > To take things one at a time, it would be very useful to > > > > > read and comment > > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > > important, and > > > > > > a rich source of misunderstanding and cross-talk; and > > > > > coming to a common > > > > > > understanding over this should help get the IETF and the > > > > ITU working > > > > > > together. > > > > > > > > > > I haven't seen many comments, so the assumption is > > either that no > > > > > one cares, or that folks have read it and have no issues. > > > > > > > > > > I'd like to get a reading on whether this doc is ready to be a > > > > > CCAMP WG document. Please respond (preferably publicly) > > > > with one of: > > > > > - "I have read this document and it is ready to be a CCAMP > > > > WG doc" OR > > > > > - "I have read this document, and it isn't ready to be a > > > > CCAMP doc". > > > > > > > > > > Note that if there aren't enough responses, the default > > > > assumption is > > > > > that the document is either not of interest or not ready, and in > > > > > either case will not become a CCAMP WG doc. Note too > > > that this doc > > > > > is an attempt to bridge some gaps between the IETF and > > the ITU-T, > > > > > and as such is fairly important. It would be useful to give an > > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > > > Thanks, > > > > > Kireeti. > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:07:49 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2500AD@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Wijnen, Bert (Bert)'" , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 14:09:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Bert, IMHO, the requirements draft identifies a number of requirements for ASON that went into the definition of RFC3474 (with the exception of crankback, which has been worked separately), so it is not in conflict with the work in 3474. I don't see this as being tied to "fixing" the extensions in 3474, which in my view is not necessary. Some of the mailing list discussion revolved around requirements such as call and connection separation, and it would be helpful to see if there is actually agreement to support this. Other complaints were about the process that went into creating 3474, and hopefully the requirements document will help address those concerns as well. Lastly, the requirements draft has obviously been condensed down to some specific requirements with impact on signaling. There may be changes or additions as we go along (the ability to identify separately a transport node, connection controller and routing controller might be one to consider). Cheers, Lyndon -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, May 12, 2003 1:27 PM To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org Subject: RE: ASON reqts I know that some people had issues with the way that ITU-T had defined the RSVP-TE extensions for ASON. In fact there was/is a claim that it is broken. So we removed the offending text from the RFC3474. The next thing we were going to do (as far as I understood it) is to document why we (or some of us in IETF) think that the ITU-T solution is broken, potentially with suggested fixes. That we would send to ITU-T SG15. Is this the first step of that process? Thanks, Bert > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: maandag 12 mei 2003 22:24 > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Bert, > > I thought that the post 3474/3475 process started with a requirements > document. > > Thanks, > > John > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, May 12, 2003 1:14 PM > > To: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > that those 2 RFCs point to, then I wonder: > > - is there or do we see any conflict? > > - are we duplicating some work? > > - what is the purpose of this draft? > > - is it after the fact documenting of requirements? > > - is it getting ITU-T documented requirements in RFC form? > > - is it extending ITU-T documented requirements? > > - is it contrdicting them? > > - is it meant to be used as communication to ITU? > > > > Just wondering what is happening here. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: maandag 12 mei 2003 17:25 > > > To: ccamp@ops.ietf.org > > > Subject: Re: ASON reqts > > > > > > > > > Hi All, > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > To take things one at a time, it would be very useful to > > > read and comment > > > > on the ASON reqts draft, as this was deemed tremendously > > > important, and > > > > a rich source of misunderstanding and cross-talk; and > > > coming to a common > > > > understanding over this should help get the IETF and the > > ITU working > > > > together. > > > > > > I haven't seen many comments, so the assumption is either that no > > > one cares, or that folks have read it and have no issues. > > > > > > I'd like to get a reading on whether this doc is ready to be a > > > CCAMP WG document. Please respond (preferably publicly) > > with one of: > > > - "I have read this document and it is ready to be a CCAMP > > WG doc" OR > > > - "I have read this document, and it isn't ready to be a > > CCAMP doc". > > > > > > Note that if there aren't enough responses, the default > > assumption is > > > that the document is either not of interest or not ready, and in > > > either case will not become a CCAMP WG doc. Note too > that this doc > > > is an attempt to bridge some gaps between the IETF and the ITU-T, > > > and as such is fairly important. It would be useful to give an > > > update on its status at the interim T1X1 meeting in June. > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > Thanks, > > > Kireeti. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 21:07:31 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972556@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 14:06:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, In case you missed it: http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00451.html John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 12, 2003 1:27 PM > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > I know that some people had issues with the way that ITU-T > had defined the RSVP-TE extensions for ASON. In fact there > was/is a claim that it is broken. So we removed the offending > text from the RFC3474. > > The next thing we were going to do (as far as I understood it) > is to document why we (or some of us in IETF) think that the > ITU-T solution is broken, potentially with suggested fixes. > That we would send to ITU-T SG15. > > Is this the first step of that process? > > Thanks, > Bert > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: maandag 12 mei 2003 22:24 > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Bert, > > > > I thought that the post 3474/3475 process started with a > requirements > > document. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Monday, May 12, 2003 1:14 PM > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > that those 2 RFCs point to, then I wonder: > > > - is there or do we see any conflict? > > > - are we duplicating some work? > > > - what is the purpose of this draft? > > > - is it after the fact documenting of requirements? > > > - is it getting ITU-T documented requirements in RFC form? > > > - is it extending ITU-T documented requirements? > > > - is it contrdicting them? > > > - is it meant to be used as communication to ITU? > > > > > > Just wondering what is happening here. > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > Sent: maandag 12 mei 2003 17:25 > > > > To: ccamp@ops.ietf.org > > > > Subject: Re: ASON reqts > > > > > > > > > > > > Hi All, > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > To take things one at a time, it would be very useful to > > > > read and comment > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > important, and > > > > > a rich source of misunderstanding and cross-talk; and > > > > coming to a common > > > > > understanding over this should help get the IETF and the > > > ITU working > > > > > together. > > > > > > > > I haven't seen many comments, so the assumption is > either that no > > > > one cares, or that folks have read it and have no issues. > > > > > > > > I'd like to get a reading on whether this doc is ready to be a > > > > CCAMP WG document. Please respond (preferably publicly) > > > with one of: > > > > - "I have read this document and it is ready to be a CCAMP > > > WG doc" OR > > > > - "I have read this document, and it isn't ready to be a > > > CCAMP doc". > > > > > > > > Note that if there aren't enough responses, the default > > > assumption is > > > > that the document is either not of interest or not ready, and in > > > > either case will not become a CCAMP WG doc. Note too > > that this doc > > > > is an attempt to bridge some gaps between the IETF and > the ITU-T, > > > > and as such is fairly important. It would be useful to give an > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > Thanks, > > > > Kireeti. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:47:20 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC925BC8@nimbus> From: Ayan Banerjee To: "'ccamp@ops.ietf.org'" Cc: 'Kireeti Kompella' Subject: RE: ASON reqts Date: Mon, 12 May 2003 13:46:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Mine should read: "I have read this document and it is ready to be a CCAMP WG doc" Cut-and-paste from below did not work correctly. Thanks, Ayan -----Original Message----- From: Ayan Banerjee Sent: Monday, May 12, 2003 1:31 PM To: ccamp@ops.ietf.org Cc: Kireeti Kompella Subject: RE: ASON reqts "I have read this document, and it isn't ready to be a CCAMP doc" Thanks, Ayan > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:42:35 +0000 Date: Mon, 12 May 2003 16:41:02 -0400 From: Zhi-Wei Lin Subject: Re: RE: ASON reqts To: "Wijnen, Bert (Bert)" Cc: Kireeti Kompella , ccamp@ops.ietf.org Message-id: <41f7524238f8.4238f841f752@icomcast.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline Hi Bert, I believe the purpose of the document is to try and capture the ITU-T requirements and present in a IETF "friendly" way. So I support trying to get the requirements consistent between the two. As to what I think is the status, while I agree with many of the requirements in the document I believe there's still some work to be done before this becomes a WG document. We've had some fair amount of hashing through of the requirements, and I think many (but not all) of the ASON needs have been reflected. We probably need another sit-down with more ITU folks to make sure that all the critical ASON requirements are captured... So to answer Kireeti's comments, I'd like a third option: "I have read this document, and it's almost ready to be a CCAMP doc" Zhi ----- Original Message ----- From: "Wijnen, Bert (Bert)" Date: Monday, May 12, 2003 4:14 pm Subject: RE: ASON reqts > So if we look at RFCs 3474/3475 and the ITU-T documents > that those 2 RFCs point to, then I wonder: > - is there or do we see any conflict? > - are we duplicating some work? > - what is the purpose of this draft? > - is it after the fact documenting of requirements? > - is it getting ITU-T documented requirements in RFC form? > - is it extending ITU-T documented requirements? > - is it contrdicting them? > - is it meant to be used as communication to ITU? > > Just wondering what is happening here. > > Thanks, > Bert > > > -----Original Message----- > > From: Kireeti Kompella [kireeti@juniper.net] > > Sent: maandag 12 mei 2003 17:25 > > To: ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > Hi All, > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > To take things one at a time, it would be very useful to > > read and comment > > > on the ASON reqts draft, as this was deemed tremendously > > important, and > > > a rich source of misunderstanding and cross-talk; and > > coming to a common > > > understanding over this should help get the IETF and the ITU > working> > together. > > > > I haven't seen many comments, so the assumption is either that no > > one cares, or that folks have read it and have no issues. > > > > I'd like to get a reading on whether this doc is ready to be a > > CCAMP WG document. Please respond (preferably publicly) with > one of: > > - "I have read this document and it is ready to be a CCAMP WG > doc" OR > > - "I have read this document, and it isn't ready to be a CCAMP > doc".> > > Note that if there aren't enough responses, the default > assumption is > > that the document is either not of interest or not ready, and in > > either case will not become a CCAMP WG doc. Note too that this doc > > is an attempt to bridge some gaps between the IETF and the ITU-T, > > and as such is fairly important. It would be useful to give an > > update on its status at the interim T1X1 meeting in June. > > > > Please get your responses in by COB Friday May 16th. > > > > Thanks, > > Kireeti. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:31:33 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC925BC5@nimbus> From: Ayan Banerjee To: ccamp@ops.ietf.org Cc: Kireeti Kompella Subject: RE: ASON reqts Date: Mon, 12 May 2003 13:30:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" "I have read this document, and it isn't ready to be a CCAMP doc" Thanks, Ayan > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:31:00 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972551@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 13:30:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, I think so. Thanks, John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 12, 2003 1:27 PM > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > I know that some people had issues with the way that ITU-T > had defined the RSVP-TE extensions for ASON. In fact there > was/is a claim that it is broken. So we removed the offending > text from the RFC3474. > > The next thing we were going to do (as far as I understood it) > is to document why we (or some of us in IETF) think that the > ITU-T solution is broken, potentially with suggested fixes. > That we would send to ITU-T SG15. > > Is this the first step of that process? > > Thanks, > Bert > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: maandag 12 mei 2003 22:24 > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > Bert, > > > > I thought that the post 3474/3475 process started with a > requirements > > document. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Monday, May 12, 2003 1:14 PM > > > To: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: ASON reqts > > > > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > > that those 2 RFCs point to, then I wonder: > > > - is there or do we see any conflict? > > > - are we duplicating some work? > > > - what is the purpose of this draft? > > > - is it after the fact documenting of requirements? > > > - is it getting ITU-T documented requirements in RFC form? > > > - is it extending ITU-T documented requirements? > > > - is it contrdicting them? > > > - is it meant to be used as communication to ITU? > > > > > > Just wondering what is happening here. > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > > Sent: maandag 12 mei 2003 17:25 > > > > To: ccamp@ops.ietf.org > > > > Subject: Re: ASON reqts > > > > > > > > > > > > Hi All, > > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > > > To take things one at a time, it would be very useful to > > > > read and comment > > > > > on the ASON reqts draft, as this was deemed tremendously > > > > important, and > > > > > a rich source of misunderstanding and cross-talk; and > > > > coming to a common > > > > > understanding over this should help get the IETF and the > > > ITU working > > > > > together. > > > > > > > > I haven't seen many comments, so the assumption is > either that no > > > > one cares, or that folks have read it and have no issues. > > > > > > > > I'd like to get a reading on whether this doc is ready to be a > > > > CCAMP WG document. Please respond (preferably publicly) > > > with one of: > > > > - "I have read this document and it is ready to be a CCAMP > > > WG doc" OR > > > > - "I have read this document, and it isn't ready to be a > > > CCAMP doc". > > > > > > > > Note that if there aren't enough responses, the default > > > assumption is > > > > that the document is either not of interest or not ready, and in > > > > either case will not become a CCAMP WG doc. Note too > > that this doc > > > > is an attempt to bridge some gaps between the IETF and > the ITU-T, > > > > and as such is fairly important. It would be useful to give an > > > > update on its status at the interim T1X1 meeting in June. > > > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > > > Thanks, > > > > Kireeti. > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:28:01 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B91F1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 22:27:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I know that some people had issues with the way that ITU-T had defined the RSVP-TE extensions for ASON. In fact there was/is a claim that it is broken. So we removed the offending text from the RFC3474. The next thing we were going to do (as far as I understood it) is to document why we (or some of us in IETF) think that the ITU-T solution is broken, potentially with suggested fixes. That we would send to ITU-T SG15. Is this the first step of that process? Thanks, Bert > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: maandag 12 mei 2003 22:24 > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > Bert, > > I thought that the post 3474/3475 process started with a requirements > document. > > Thanks, > > John > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, May 12, 2003 1:14 PM > > To: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: ASON reqts > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents > > that those 2 RFCs point to, then I wonder: > > - is there or do we see any conflict? > > - are we duplicating some work? > > - what is the purpose of this draft? > > - is it after the fact documenting of requirements? > > - is it getting ITU-T documented requirements in RFC form? > > - is it extending ITU-T documented requirements? > > - is it contrdicting them? > > - is it meant to be used as communication to ITU? > > > > Just wondering what is happening here. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: maandag 12 mei 2003 17:25 > > > To: ccamp@ops.ietf.org > > > Subject: Re: ASON reqts > > > > > > > > > Hi All, > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > > > To take things one at a time, it would be very useful to > > > read and comment > > > > on the ASON reqts draft, as this was deemed tremendously > > > important, and > > > > a rich source of misunderstanding and cross-talk; and > > > coming to a common > > > > understanding over this should help get the IETF and the > > ITU working > > > > together. > > > > > > I haven't seen many comments, so the assumption is either that no > > > one cares, or that folks have read it and have no issues. > > > > > > I'd like to get a reading on whether this doc is ready to be a > > > CCAMP WG document. Please respond (preferably publicly) > > with one of: > > > - "I have read this document and it is ready to be a CCAMP > > WG doc" OR > > > - "I have read this document, and it isn't ready to be a > > CCAMP doc". > > > > > > Note that if there aren't enough responses, the default > > assumption is > > > that the document is either not of interest or not ready, and in > > > either case will not become a CCAMP WG doc. Note too > that this doc > > > is an attempt to bridge some gaps between the IETF and the ITU-T, > > > and as such is fairly important. It would be useful to give an > > > update on its status at the interim T1X1 meeting in June. > > > > > > Please get your responses in by COB Friday May 16th. > > > > > > Thanks, > > > Kireeti. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:23:57 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97254F@nimbus> From: John Drake To: "'Wijnen, Bert (Bert)'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 13:23:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, I thought that the post 3474/3475 process started with a requirements document. Thanks, John > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 12, 2003 1:14 PM > To: Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON reqts > > > So if we look at RFCs 3474/3475 and the ITU-T documents > that those 2 RFCs point to, then I wonder: > - is there or do we see any conflict? > - are we duplicating some work? > - what is the purpose of this draft? > - is it after the fact documenting of requirements? > - is it getting ITU-T documented requirements in RFC form? > - is it extending ITU-T documented requirements? > - is it contrdicting them? > - is it meant to be used as communication to ITU? > > Just wondering what is happening here. > > Thanks, > Bert > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: maandag 12 mei 2003 17:25 > > To: ccamp@ops.ietf.org > > Subject: Re: ASON reqts > > > > > > Hi All, > > > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > > > To take things one at a time, it would be very useful to > > read and comment > > > on the ASON reqts draft, as this was deemed tremendously > > important, and > > > a rich source of misunderstanding and cross-talk; and > > coming to a common > > > understanding over this should help get the IETF and the > ITU working > > > together. > > > > I haven't seen many comments, so the assumption is either that no > > one cares, or that folks have read it and have no issues. > > > > I'd like to get a reading on whether this doc is ready to be a > > CCAMP WG document. Please respond (preferably publicly) > with one of: > > - "I have read this document and it is ready to be a CCAMP > WG doc" OR > > - "I have read this document, and it isn't ready to be a > CCAMP doc". > > > > Note that if there aren't enough responses, the default > assumption is > > that the document is either not of interest or not ready, and in > > either case will not become a CCAMP WG doc. Note too that this doc > > is an attempt to bridge some gaps between the IETF and the ITU-T, > > and as such is fairly important. It would be useful to give an > > update on its status at the interim T1X1 meeting in June. > > > > Please get your responses in by COB Friday May 16th. > > > > Thanks, > > Kireeti. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:21:33 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Mon, 12 May 2003 15:21:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A67A6@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMYnRneCjgqT1VWTgmOUX0U8o7JbgAJhodQ From: "Ash, Gerald R (Jerry), ALABS" To: "Kireeti Kompella" , Cc: "Ash, Gerald R (Jerry), ALABS" > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". "I have read this document and it is ready to be a CCAMP WG doc" I agree with Deborah that the document is well aligned with the ITU = requirements, and has a good balance of ITU and IETF input. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 20:14:44 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B91EE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 22:14:05 +0200 MIME-Version: 1.0 Content-Type: text/plain So if we look at RFCs 3474/3475 and the ITU-T documents that those 2 RFCs point to, then I wonder: - is there or do we see any conflict? - are we duplicating some work? - what is the purpose of this draft? - is it after the fact documenting of requirements? - is it getting ITU-T documented requirements in RFC form? - is it extending ITU-T documented requirements? - is it contrdicting them? - is it meant to be used as communication to ITU? Just wondering what is happening here. Thanks, Bert > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: maandag 12 mei 2003 17:25 > To: ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to > read and comment > > on the ASON reqts draft, as this was deemed tremendously > important, and > > a rich source of misunderstanding and cross-talk; and > coming to a common > > understanding over this should help get the IETF and the ITU working > > together. > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 19:47:11 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Mon, 12 May 2003 14:46:21 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109AD33E7@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMYoPlnCPvvkB94QfWqukP4bYUoQQAHBMfw From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , I have read this document and it is ready to be a CCAMP WG doc. The document is very aligned with the ITU work. From an ITU perspective, = the document is easy to read. And considering the author list, it's a = balanced list of ITU and IETF participants. Following up on Adrian's = request, I would be interested to hear from IETF participants. As = Kireeti stated, this document is an attempt to bridge the gaps between = the IETF and ITU work. Most important for progressing this work is the = understanding level/interest by the IETF community involved in GMPLS. Thanks, Deborah -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Monday, May 12, 2003 12:03 PM To: ccamp@ops.ietf.org Subject: Re: ASON reqts > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". Unless you count the authors by default... "I have read this document and it is ready to be a CCAMP WG doc" > Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. In the light of which, we would be *very* pleased to have comments from = people who participate in the ITU-T work. From my perspective I would like to = know... - Does this draft represent a fair picture of the ASON requirements? - Has it left anything out? - Has it made up requirements that aren't there? - Does it give the right precedence to the requirements? - Does the draft give the right level of background without overly = restating material that is in the ITU documents? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 19:30:56 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97253D@nimbus> From: John Drake To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: ASON reqts Date: Mon, 12 May 2003 12:30:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" "I have read this document and it is ready to be a CCAMP WG doc" > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, May 12, 2003 8:25 AM > To: ccamp@ops.ietf.org > Subject: Re: ASON reqts > > > Hi All, > > On Fri, 2 May 2003, Kireeti Kompella wrote: > > > To take things one at a time, it would be very useful to > read and comment > > on the ASON reqts draft, as this was deemed tremendously > important, and > > a rich source of misunderstanding and cross-talk; and > coming to a common > > understanding over this should help get the IETF and the ITU working > > together. > > I haven't seen many comments, so the assumption is either that no > one cares, or that folks have read it and have no issues. > > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". > > Note that if there aren't enough responses, the default assumption is > that the document is either not of interest or not ready, and in > either case will not become a CCAMP WG doc. Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. > > Please get your responses in by COB Friday May 16th. > > Thanks, > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 18:39:11 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Mon, 12 May 2003 13:37:30 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109A0F0FB@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Proposed response to the Liaison Statement on LMP Link Verifi cation Thread-Index: AcMYT8R1bX10VEFORry31868TZ4ojAAZbE1Q From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Cc: , "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , Fine, send it as is, Deborah -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, May 12, 2003 2:23 AM To: ccamp@ops.ietf.org Cc: sob@harvard.edu; Wijnen, Bert (Bert); Ron Bonica (E-mail);=20 Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Hi All, On Tue, 29 Apr 2003, Kireeti Kompella wrote: > I will formulate a liaison statement in reply to T1X1 regarding > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. Sorry for the tardy follow-up. Here is the proposed response. Please send your replies to the list (if you wish to reply privately, include the Liaison Coordinator and the ADs in your reply). Ideally, your reply should say one of: - "Fine, send it as is"; OR - "Please make the following changes", with _specific text_; OR - "Do not send this response". Please respond by COB Friday, May 16th. Kireeti. =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=3D=3D=3D=3D=3D Dear Mr. Biholar, Regarding the following liaison: TITLE: Liaison from T1X1 to IETF ccamp regarding draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt TO: IETF ccamp Working Group CC: ITU-T Q.14/15 (for information) SOURCE*: T1X1 FOR: Action DEADLINE: 9 June 2003 PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic = Interconnection We thank the T1X1 and the ITU-T for their review and the incorporation of the LMP Test procedure into G.7714.1. Based on information contained in the ITU and T1X1 liaison, as well as subsequent e-mail exchanges on the CCAMP mailing list, and in order to ensure proper interoperability in legacy SDH/SONET networks as well as networks in which G.7714.1 is deployed, it will be recommended by the editors to the CCAMP community to support only the Jx trace correlation procedure and not the in-band Jx procedure. Pending agreement, the draft will be updated. See inline for more detailed responses to specific points. > Context of Application Space > It is currently our understanding that the use case > scenario for which this procedure is applied encompasses > both transport plane connectivity verification as well as > correlation of these entities with the control plane. > ITU-T G.7714.1 is focused on discovering the transport > plane link connection end point relationships and > verifying their connectivity. > This Recommendation defines two procedures for performing > the connectivity verification function, one of which > utilizes either the Jx or the DCC bytes of the server > signal (termed "in-service"). The other approach in > G.7714.1, termed as "out of service", corresponds to > inserting a test signal in the payload of the server > signal. Based on an analysis of the data link state > definitions in draft-ietf-ccamp-lmp-08.txt, we understand > that the approach defined in the LMP test for physical > connectivity occurs in the context of the "out of service" > state (as described in G.7714.1). > > Please confirm this. The subject document uses the Jx or DCC bytes to perform the LMP Test procedure, but the The LMP Test procedure is done as part of GMPLS link intialization, prior to the link being available to carry user traffic. > Usage of Jx Bytes > > In defining the Jx bytes within G.7714.1, the following > was taken into account: > 1. One consideration involved the case where the Discovery > Agent is located in an external system, and an external > interface is used by the Network Element to provision and > receive the Trail Trace message. As an existing text- > oriented Man-Machine Language, such as TL1, may be reused > to provide this interface, it was decided that the > discovery message be limited to printable characters. > Specifically, the TTI characters should be limited to > printable characters as per T.50 with trailing NULLs or > SPACEs. Use of arbitrary bit patterns in the lower 7 bits > of each byte could prematurely terminate the pattern or > trigger fault notification for certain hardware or > software implementations. The strategy chosen in G.7714.1 > avoids the danger by limiting the information content of > each byte to 6 bits (84 bits total) and uses a base 64 > coding according to RFC2045 to place the information in > the available bits. The LMP test procedure described in the subject document defines two usages of the Jx bytes. The first is termed the 'trace correlation transport mechanism' and it treats the Jx bytes as an opaque bit stream. This usage is completely consistent with the above. GMPLS identifiers are typically 32 bit numbers and as such are not printable characters. In networks that do not require that the Jx bytes be printable, it is also possible to carry the GMPLS identifiers directly in the Jx bytes. This is termed the 'Jx transport mechanism'. > 2. Another consideration involved providing a means for > distinguishing this use of the Jx bytes from the > traditional use for Trail Trace identifiers in new > equipments. As a result, G.7714.1 includes a > distinguishing character ("+") as the first non-CRC byte > that will never appear as the first character of a TTI. > This requires modification of the trail termination > functions to prevent the raising of TTI mismatch > alarms during the connectivity verification process. The selection of which LMP transport mechanism use in the LMP Test procedure for a given link as well as the time at which the Jx bytes are to be used for the LMP Test procedure is under control of the GMPLS nodes at either end of the link, so it is well understood by those nodes. It is our understanding, per G.806 section 6.1, that the LMP Test procedure would be performed when the link is in the NMON (not monitored state), and therefore intermediate SDH/SONET equipment would not be performing non-intrusive monitoring. > While the context for testing the transport plane > connectivity is different between the two documents, they > both use the Jx bytes of the server signal, and we invite > the IETF to determine the appropriateness of the above > aspects in their test signal definitions. The trace correlation transport mechanism is completely consistent with this. The JX transport mechanism requires additional identifiers (i.e., the Verify ID). > Even if these considerations are not relevant to this > context, it will be necessary to augment G.783 equipment > functions to recognize this new usage of Jx messages. We would be happy to provide assistance to T1X1/ITU-T in augmenting G.783 equipment functions to recognize the additional capability for supporting GMPLS networking elements. > Required Updates to SDH Equipment Specifications > > SDH equipment specifications as they currently exist reflect > the usage of the Jx bytes prior to the development of > G.7714.1. ITU-T Study Group 15 has as a work item to > revise these equipment functions to include support for > these new functions. Specifically, this will involve > updates to trail termination functions to generate and > receive the new messages and to avoid unnecessary alarms in > the case where the new messages are received. In addition, > non-intrusive monitoring functions will need to be revised > so that unnecessary alarms are not raised when the > messages are observed en-route. Whether or not there is > further alignment between the message formats used in > G.7714.1 and the subject draft, the new functions to > support the subject draft will also need to be reflected > in the atomic functions in G.783. The sending and > receiving of these messages can be reflected in the trail > termination functions in a similar way to what we plan to > do for support of G.7714.1 functions. We would be happy to provide assistance to T1X1/ITU-T in augmenting G.783 equipment functions to recognize the additional capability for supporting GMPLS networking elements. > Terminology Differences > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > the "up/free (in-service)" data link state appears to > correspond with what G.7714.1 refers to as "out-of- > service". This difference in terminology has resulted in > different interpretations of the context. Explaining the > scenarios further in the lmp test document would be > beneficial in establishing a translation between the > differing uses of the same terms. Within ITU-T, work is > being initiated of draft Rec. G.fame, Framework for ASON > Management, where control plane/management plane > interactions will be addressed. We agree that terminology differences between IETF and ITU-T wrt GMPLS have been confusing. There is an ongoing effort within CCAMP to work together with T1X1/ITU-T on bridging the terminology gaps. For example, there is a new Internet draft (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP to do this mapping for LMP. > Further Study Items > > Following are some areas where further contributions are > requested: > 1. For SDH equipment functions in G.783, it needs to > be understood whether the application of the lmp test > message requires revision of NIM (non-intrusive > monitoring) functions. The reason for this is that the > test procedure is initiated between control entities at > the end-points of the trail, and intermediate points are > not necessarily aware that the test is taking place. For > G.7714.1, it was felt important for any termination or NIM > function to easily distinguish between the various uses of > the Jx bytes. It may be necessary for the subject draft > to use a similarly easily recognizable format. If no > revision to NIM functions is required for the context of > this draft, the architecture of the context for this > application (demonstrating why the NIM functions are not > required) should be reflected in G.803 and/or G.807/G.8080. It is our understanding, per G.806 section 6.1, that the LMP Test procedure would be performed when the link is in the NMON (not monitored state), and therefore intermediate SDH/SONET equipment would not be performing non-intrusive monitoring. As described, the trace correlation procedure use of Jx bytes is consistent with the current standards. > 2.Determination of whether it would be possible to use the > identical message formats in the subject draft as in > G.7714.1 for the connectivity verification function. The trace correlation transport mechanism is completely consistent with this. The Jx transport mechanism requires additional identifiers (i.e., the Verify ID). > 3.Determination of whether it would be possible to use the > same overall structure (distinguishing character, 4 bit > message type, 80 bit message body) if a different message > format or information content is required. This is certainly possible (not applicable for the trace correlation procedure). > 4.Work is needed to clarify under what > configurations/states (for example: no VC-n signals > carrying client traffic) the lmp test message is > applicable over J0. If the signal can be framed and J0 > can be recovered, the Regenerator Section is considered > as "in service" from a transport plane perspective. So > unlike the J1/J2 case, the application of the lmp test > message at the Regenerator Section does not occur in an > "out of service" state (from a transport plane > perspective). Section 6.1 of G.806 refers to a "termination function part of a trail, which is in the process of set-up" as in the NMON state. LMP link verification is based on pre-service testing. Please let us know if we can be of any assistance in updating the appropriate Recommendations to support the GMPLS network element LMP capability. This is not applicable for the trace correlation procedure. > 5. Clarification of the usage of transport and control > names for transport resources in the subject draft, as > described in G.8080 Amendment The trace correlation transport mechanism supports a separation of the transport and control plane identifiers. > 6. Consideration of the ANSI 64-byte J1. This was mistakenly deleted from the latest version of the draft. This will be included in the next version. Sincerely, Kireeti Kompella and Ron Bonica, Chairs of the CCAMP WG/IETF. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 18:39:04 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed change to LMP Link Verification draft Date: Mon, 12 May 2003 13:38:27 -0500 Message-ID: <74745B5500AD8E4B9C48BC9CCECB6E0109A0F0FC@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Proposed change to LMP Link Verification draft Thread-Index: AcMYT+qGSB1A3r2GR4WpAu3jGkZssgAZbA8Q From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Agree with change, Deborah -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, May 12, 2003 2:28 AM To: ccamp@ops.ietf.org Subject: Proposed change to LMP Link Verification draft Hi All, | Based on information contained in the ITU and T1X1 liaison, as well as | subsequent e-mail exchanges on the CCAMP mailing list, and in order to | ensure proper interoperability in legacy SDH/SONET networks as well as | networks in which G.7714.1 is deployed, it will be recommended by the | editors to the CCAMP community to support only the Jx trace = correlation | procedure and not the in-band Jx procedure. Please respond with one of the following: - Agree with above change; OR - Don't agree with above change [i.e., keep in-band Jx procedure as = is]. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 16:03:52 +0000 Message-ID: <00d201c3189f$f40ff8e0$681810ac@movaz.com> From: "Adrian Farrel" To: Subject: Re: ASON reqts Date: Mon, 12 May 2003 12:02:56 -0400 > I'd like to get a reading on whether this doc is ready to be a > CCAMP WG document. Please respond (preferably publicly) with one of: > - "I have read this document and it is ready to be a CCAMP WG doc" OR > - "I have read this document, and it isn't ready to be a CCAMP doc". Unless you count the authors by default... "I have read this document and it is ready to be a CCAMP WG doc" > Note too that this doc > is an attempt to bridge some gaps between the IETF and the ITU-T, > and as such is fairly important. It would be useful to give an > update on its status at the interim T1X1 meeting in June. In the light of which, we would be *very* pleased to have comments from people who participate in the ITU-T work. From my perspective I would like to know... - Does this draft represent a fair picture of the ASON requirements? - Has it left anything out? - Has it made up requirements that aren't there? - Does it give the right precedence to the requirements? - Does the draft give the right level of background without overly restating material that is in the ITU documents? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 15:25:39 +0000 Date: Mon, 12 May 2003 08:24:37 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: ASON reqts Message-ID: <20030512081716.U68823@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Fri, 2 May 2003, Kireeti Kompella wrote: > To take things one at a time, it would be very useful to read and comment > on the ASON reqts draft, as this was deemed tremendously important, and > a rich source of misunderstanding and cross-talk; and coming to a common > understanding over this should help get the IETF and the ITU working > together. I haven't seen many comments, so the assumption is either that no one cares, or that folks have read it and have no issues. I'd like to get a reading on whether this doc is ready to be a CCAMP WG document. Please respond (preferably publicly) with one of: - "I have read this document and it is ready to be a CCAMP WG doc" OR - "I have read this document, and it isn't ready to be a CCAMP doc". Note that if there aren't enough responses, the default assumption is that the document is either not of interest or not ready, and in either case will not become a CCAMP WG doc. Note too that this doc is an attempt to bridge some gaps between the IETF and the ITU-T, and as such is fairly important. It would be useful to give an update on its status at the interim T1X1 meeting in June. Please get your responses in by COB Friday May 16th. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 14:50:46 +0000 Message-Id: <200305121446.KAA16995@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-recovery-terminology-02.txt Date: Mon, 12 May 2003 10:46:51 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-02.txt Pages : 20 Date : 2003-5-9 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-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-recovery-terminology-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-recovery-terminology-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: <2003-5-9123758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-9123758.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 14:10:39 +0000 Message-ID: <99EC34181384D611BE56000347227B2C213ECA@MAILHOSTNB> From: Manoj Agiwal To: "'Ccamp (E-mail)" Cc: "'jplang@calient.net'" Subject: LMP Message ID Date: Mon, 12 May 2003 09:02:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi , Lmp drafts tells that Message ID should be monotonically increasing . Section 7 also tells that "Unacknowledge messages sent with Message_id object should be retransmitted until the message is acknowledged or until retry limit is reached." Do we have to sent all retransmitted messages with the same Message Id as sent previously or it should be in monotonically increasing order. Regards , Manoj Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 11:27:40 +0000 Message-Id: <200305121122.HAA08334@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-recovery-terminology-02.txt Date: Mon, 12 May 2003 07:22:45 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-02.txt Pages : 20 Date : 2003-5-9 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-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-recovery-terminology-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-recovery-terminology-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: <2003-5-9123758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-9123758.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 06:28:58 +0000 Date: Sun, 11 May 2003 23:27:58 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Proposed change to LMP Link Verification draft Message-ID: <20030511232318.M66890@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, | Based on information contained in the ITU and T1X1 liaison, as well as | subsequent e-mail exchanges on the CCAMP mailing list, and in order to | ensure proper interoperability in legacy SDH/SONET networks as well as | networks in which G.7714.1 is deployed, it will be recommended by the | editors to the CCAMP community to support only the Jx trace correlation | procedure and not the in-band Jx procedure. Please respond with one of the following: - Agree with above change; OR - Don't agree with above change [i.e., keep in-band Jx procedure as is]. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 May 2003 06:27:31 +0000 Date: Sun, 11 May 2003 23:23:01 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , "" Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Message-ID: <20030511230845.C66890@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Tue, 29 Apr 2003, Kireeti Kompella wrote: > I will formulate a liaison statement in reply to T1X1 regarding > draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. Sorry for the tardy follow-up. Here is the proposed response. Please send your replies to the list (if you wish to reply privately, include the Liaison Coordinator and the ADs in your reply). Ideally, your reply should say one of: - "Fine, send it as is"; OR - "Please make the following changes", with _specific text_; OR - "Do not send this response". Please respond by COB Friday, May 16th. Kireeti. ======================================================================= Dear Mr. Biholar, Regarding the following liaison: TITLE: Liaison from T1X1 to IETF ccamp regarding draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt TO: IETF ccamp Working Group CC: ITU-T Q.14/15 (for information) SOURCE*: T1X1 FOR: Action DEADLINE: 9 June 2003 PROJECT: T1X1-01: Optical Interface Standard for Fiber Optic Interconnection We thank the T1X1 and the ITU-T for their review and the incorporation of the LMP Test procedure into G.7714.1. Based on information contained in the ITU and T1X1 liaison, as well as subsequent e-mail exchanges on the CCAMP mailing list, and in order to ensure proper interoperability in legacy SDH/SONET networks as well as networks in which G.7714.1 is deployed, it will be recommended by the editors to the CCAMP community to support only the Jx trace correlation procedure and not the in-band Jx procedure. Pending agreement, the draft will be updated. See inline for more detailed responses to specific points. > Context of Application Space > It is currently our understanding that the use case > scenario for which this procedure is applied encompasses > both transport plane connectivity verification as well as > correlation of these entities with the control plane. > ITU-T G.7714.1 is focused on discovering the transport > plane link connection end point relationships and > verifying their connectivity. > This Recommendation defines two procedures for performing > the connectivity verification function, one of which > utilizes either the Jx or the DCC bytes of the server > signal (termed "in-service"). The other approach in > G.7714.1, termed as "out of service", corresponds to > inserting a test signal in the payload of the server > signal. Based on an analysis of the data link state > definitions in draft-ietf-ccamp-lmp-08.txt, we understand > that the approach defined in the LMP test for physical > connectivity occurs in the context of the "out of service" > state (as described in G.7714.1). > > Please confirm this. The subject document uses the Jx or DCC bytes to perform the LMP Test procedure, but the The LMP Test procedure is done as part of GMPLS link intialization, prior to the link being available to carry user traffic. > Usage of Jx Bytes > > In defining the Jx bytes within G.7714.1, the following > was taken into account: > 1. One consideration involved the case where the Discovery > Agent is located in an external system, and an external > interface is used by the Network Element to provision and > receive the Trail Trace message. As an existing text- > oriented Man-Machine Language, such as TL1, may be reused > to provide this interface, it was decided that the > discovery message be limited to printable characters. > Specifically, the TTI characters should be limited to > printable characters as per T.50 with trailing NULLs or > SPACEs. Use of arbitrary bit patterns in the lower 7 bits > of each byte could prematurely terminate the pattern or > trigger fault notification for certain hardware or > software implementations. The strategy chosen in G.7714.1 > avoids the danger by limiting the information content of > each byte to 6 bits (84 bits total) and uses a base 64 > coding according to RFC2045 to place the information in > the available bits. The LMP test procedure described in the subject document defines two usages of the Jx bytes. The first is termed the 'trace correlation transport mechanism' and it treats the Jx bytes as an opaque bit stream. This usage is completely consistent with the above. GMPLS identifiers are typically 32 bit numbers and as such are not printable characters. In networks that do not require that the Jx bytes be printable, it is also possible to carry the GMPLS identifiers directly in the Jx bytes. This is termed the 'Jx transport mechanism'. > 2. Another consideration involved providing a means for > distinguishing this use of the Jx bytes from the > traditional use for Trail Trace identifiers in new > equipments. As a result, G.7714.1 includes a > distinguishing character ("+") as the first non-CRC byte > that will never appear as the first character of a TTI. > This requires modification of the trail termination > functions to prevent the raising of TTI mismatch > alarms during the connectivity verification process. The selection of which LMP transport mechanism use in the LMP Test procedure for a given link as well as the time at which the Jx bytes are to be used for the LMP Test procedure is under control of the GMPLS nodes at either end of the link, so it is well understood by those nodes. It is our understanding, per G.806 section 6.1, that the LMP Test procedure would be performed when the link is in the NMON (not monitored state), and therefore intermediate SDH/SONET equipment would not be performing non-intrusive monitoring. > While the context for testing the transport plane > connectivity is different between the two documents, they > both use the Jx bytes of the server signal, and we invite > the IETF to determine the appropriateness of the above > aspects in their test signal definitions. The trace correlation transport mechanism is completely consistent with this. The JX transport mechanism requires additional identifiers (i.e., the Verify ID). > Even if these considerations are not relevant to this > context, it will be necessary to augment G.783 equipment > functions to recognize this new usage of Jx messages. We would be happy to provide assistance to T1X1/ITU-T in augmenting G.783 equipment functions to recognize the additional capability for supporting GMPLS networking elements. > Required Updates to SDH Equipment Specifications > > SDH equipment specifications as they currently exist reflect > the usage of the Jx bytes prior to the development of > G.7714.1. ITU-T Study Group 15 has as a work item to > revise these equipment functions to include support for > these new functions. Specifically, this will involve > updates to trail termination functions to generate and > receive the new messages and to avoid unnecessary alarms in > the case where the new messages are received. In addition, > non-intrusive monitoring functions will need to be revised > so that unnecessary alarms are not raised when the > messages are observed en-route. Whether or not there is > further alignment between the message formats used in > G.7714.1 and the subject draft, the new functions to > support the subject draft will also need to be reflected > in the atomic functions in G.783. The sending and > receiving of these messages can be reflected in the trail > termination functions in a similar way to what we plan to > do for support of G.7714.1 functions. We would be happy to provide assistance to T1X1/ITU-T in augmenting G.783 equipment functions to recognize the additional capability for supporting GMPLS networking elements. > Terminology Differences > Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > the "up/free (in-service)" data link state appears to > correspond with what G.7714.1 refers to as "out-of- > service". This difference in terminology has resulted in > different interpretations of the context. Explaining the > scenarios further in the lmp test document would be > beneficial in establishing a translation between the > differing uses of the same terms. Within ITU-T, work is > being initiated of draft Rec. G.fame, Framework for ASON > Management, where control plane/management plane > interactions will be addressed. We agree that terminology differences between IETF and ITU-T wrt GMPLS have been confusing. There is an ongoing effort within CCAMP to work together with T1X1/ITU-T on bridging the terminology gaps. For example, there is a new Internet draft (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP to do this mapping for LMP. > Further Study Items > > Following are some areas where further contributions are > requested: > 1. For SDH equipment functions in G.783, it needs to > be understood whether the application of the lmp test > message requires revision of NIM (non-intrusive > monitoring) functions. The reason for this is that the > test procedure is initiated between control entities at > the end-points of the trail, and intermediate points are > not necessarily aware that the test is taking place. For > G.7714.1, it was felt important for any termination or NIM > function to easily distinguish between the various uses of > the Jx bytes. It may be necessary for the subject draft > to use a similarly easily recognizable format. If no > revision to NIM functions is required for the context of > this draft, the architecture of the context for this > application (demonstrating why the NIM functions are not > required) should be reflected in G.803 and/or G.807/G.8080. It is our understanding, per G.806 section 6.1, that the LMP Test procedure would be performed when the link is in the NMON (not monitored state), and therefore intermediate SDH/SONET equipment would not be performing non-intrusive monitoring. As described, the trace correlation procedure use of Jx bytes is consistent with the current standards. > 2.Determination of whether it would be possible to use the > identical message formats in the subject draft as in > G.7714.1 for the connectivity verification function. The trace correlation transport mechanism is completely consistent with this. The Jx transport mechanism requires additional identifiers (i.e., the Verify ID). > 3.Determination of whether it would be possible to use the > same overall structure (distinguishing character, 4 bit > message type, 80 bit message body) if a different message > format or information content is required. This is certainly possible (not applicable for the trace correlation procedure). > 4.Work is needed to clarify under what > configurations/states (for example: no VC-n signals > carrying client traffic) the lmp test message is > applicable over J0. If the signal can be framed and J0 > can be recovered, the Regenerator Section is considered > as "in service" from a transport plane perspective. So > unlike the J1/J2 case, the application of the lmp test > message at the Regenerator Section does not occur in an > "out of service" state (from a transport plane > perspective). Section 6.1 of G.806 refers to a "termination function part of a trail, which is in the process of set-up" as in the NMON state. LMP link verification is based on pre-service testing. Please let us know if we can be of any assistance in updating the appropriate Recommendations to support the GMPLS network element LMP capability. This is not applicable for the trace correlation procedure. > 5. Clarification of the usage of transport and control > names for transport resources in the subject draft, as > described in G.8080 Amendment The trace correlation transport mechanism supports a separation of the transport and control plane identifiers. > 6. Consideration of the ANSI 64-byte J1. This was mistakenly deleted from the latest version of the draft. This will be included in the next version. Sincerely, Kireeti Kompella and Ron Bonica, Chairs of the CCAMP WG/IETF. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2003 15:35:04 +0000 Message-ID: <3EB928CD.7010103@alcatel.be> Date: Wed, 07 May 2003 17:39:57 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Ccamp-wg (E-mail)" Subject: Re: FW: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized Multi-Protocol Label Switching Architecture to Proposed Standard Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed bert, this is the intention (taking also into account the previous set of ref's comment), here probably harald wanted to see a single sentence where the following words are included: GMPLS, control plane, protocol (suite), architecture, and another sentence (first sentence of the introduction) should be rephrased from "The architecture presented..." to "The architecture described..." since it is an "architecture descriptive" document; these together should address his hesitation(s) now of course there was a trade-off here between reproduce all the i-d's (this wasn't the ultimate intention) and give a fair level of details (intention was also to have a "structuring i-d"), thus here the reader is pointed to the appropriate reference when the level of the details wouldn't be suitable in the scope of this document (anyway if the iesg thinks some pointers are still missing well would you then just send them asap, and if the ccamp community thinks additional editorial changes are needed to address these comments input is welcome on this specific point) ps: i'd like to recap here also there was imho a very good i-d ("Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects" draft-awduche- mpls-te-optical-03.txt) which is the fundamental step between this i-d (gmpls and related) and rfc2702 (mpls-te), rfc3031 (mpls) unfortunately it has not been further progressed since april'01 thanks, - dimitri. Wijnen, Bert (Bert) wrote: > Dimitri, if for any reason (possibly on based on other comments > from IESG) you are going to do another rev, can you pls check > the below comments and see if some additional editorial changes > make sense? > > By the way, you can see that Harald also noted the "many Work in Progress" > documents that are listed as normative references. > > Thanks, > Bert > > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: zaterdag 26 april 2003 18:03 > To: IESG Secretary; Internet Engineering Steering Group > Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-architecture - > Generalized Multi-Protocol Label Switching Architecture to Proposed > Standard > > Harald Alvestrand has no Objection. > > note: this does not mean that I like it..... > > In particular, I don't like the fact that the document can't decide whether > it's an architecture, an introduction or a specification. It goes into lots > of details that are ALMOST specified, but then just says that these are > "finished elsewhere" - sometimes giving, sometimes not giving, the forward > pointers. > > It's just about right (although overly detailed, and lacking some pointers > to where the "real spec" is) for an introduction. > > It also *contains* an architecture description - the idea of a control > plane that is a fully connected IP network (with, apparently, manual link > configuration), a set of links that are not necessarily the control links, > and in many cases not even IP-capable links, and groupings of these that > can be manipulated and controlled in various ways, and a set of protocols > and ways to use those protocols that are defined in other documents. > > But the lenght and the level of detail means that it's very hard for me to > be sure I have grasped that architecture correctly and fully. > > And - note - I have said nothing about whether or not I *like* that > architecture. > > Note: It will be a while before this is published as an RFC. There are no > less than thirteen "works in progress" in its normative references. > > Harald > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2003 15:19:47 +0000 Message-ID: <3EB924FB.10202@alcatel.be> Date: Wed, 07 May 2003 17:23:39 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" , "Thomas Narten (E-mail)" , "Erik Nordmark (E-mail)" Subject: Re: draft-ietf-ccamp-gmpls-architecture-06.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed bert, if the RFC's that are in the queue might already receive a number this would help in aligning with the point 2 of the summary you have provided here (this said it was the intent to differentiate b/w the RFC's produced in the scope/directly related of/to GMPLS, for inst. RSVP-TE-GMPLS from the ones that were produced independently, for instance RFC 2750, this is probably not needed anymore) anyway what i'd suggest is to have a version "RFC ready" but in an IESG reviewed status as you have also suggested here below see below for some additional input concerning the i-d status (for the routing ones please refer to the editor(s) Wijnen, Bert (Bert) wrote: > During IESG review, Thomas/Erik both have raised the > question that this doc had so many normative references > that seem to be "Work in Progress". > So I have checked and found the below. > > Summary: > - Would be good to have the doc names spelled out, so that reviewers > (and RFC-Editor) can quickly find the normative ref. > - Would be good to change [SOME-DOC-NAME] to [RFCxxxx] if an RFC is > already published. Would be more consistent with other RFCs that > are being referenced, and makes it easier to see which docs are > already published > - We have some 5 docs in WGs still and it is not clear how quick > they will come out > - We have some 4 or 5 that are in various stages of IESG review > and seem to need work. > > So it looks, that when we approve this and put it in RFCed queue, > it will probably hang in that queue for a long time. > > WG and WG chairs, what do you want to do about that? > > ---- status of various normative references -- > > Here are the WiP docs that are normative and the status as I fas as I > could determine (updates from WG chairs will be appreciated): > > [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling > in MPLS Traffic Engineering," Work in Progress. > This is: draft-ietf-mpls-bundle-04.txt > in RFCed queue > > [CR-LDP-UNNUM] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling > Unnumbered Links in CR-LDP," Work in Progress. > Published as RFC3480 > > [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., > "Generalized MPLS Recovery Functional > Specification," Work in Progress. > This is: draft-ietf-ccamp-gmpls-recovery-functional-00.txt > Not sure where this stands in WG revision has to be submitted (soon) > [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling > Extensions for G.709 Optical Transport Networks > Control," Work in progress. > This is: draft-ietf-ccamp-gmpls-g709-03.txt > Not sure where this stands in WG provide a last revision of it and ask for a last call > [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the > Overlay Model," Work in Progress. > This is: draft-ietf-ccamp-gmpls-overlay-01.txt > Still in WG (did not get much content discussion yet, but yet > it seems WG chairs want to do WG Last Call) > > [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing > Extensions in Support of Generalized MPLS," Work in > Progress. > This is: draft-ietf-ccamp-gmpls-routing-05.txt > Went through IETF Last Call. > Quite some comments. Is back in WG to address comments > (been there for a while in fact. Wg chairs did not ye responde to > my repeated pinging on status) > > [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., > "Generalized MPLS Extensions for SONET and SDH > Control," Work in progress. > This is: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt > Is in RFCed queue > > [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with > Generalized MPLS TE," Work in Progress. > This is: draft-ietf-mpls-lsp-hierarchy-08.txt > Is in RFCed queue > > [LMP] J.P.Lang (Editor) et al., "Link Management Protocol > (LMP)," Work in progress. > This is: draft-ietf-ccamp-lmp-08.txt > Is in IESG evaluation. Has some DISCUSSes though. work is ongoing to provide a response to the DISCUSS points > [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for > WDM Optical Line Systems (LMP-WDM)," Work in > progress. > This is: draft-ietf-ccamp-lmp-wdm-02.txt > In: AD-Evaluation, revised ID needed well for this one it depends, how long it will take after the revised i-d submission to have the review from the iesg (do you expect further action on this ?) > [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions > in Support of Generalized MPLS," Work in Progress. > This is: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt > This had serious OETF Last Call comments, to be addressed by WG/authors > > [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic > Engineering Extensions to OSPF", Work in Progress. > This is: draft-katz-yeung-ospf-traffic-09.txt > IESG evaluation, point raised > > Thanks, > Bert > thanks, -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2003 12:56:57 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B8837@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Dimitri Papadimitriou (E-mail)" Cc: "Ccamp-wg (E-mail)" Subject: FW: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized Multi-Protocol Label Switching Architecture to Proposed Standard Date: Wed, 7 May 2003 14:40:57 +0200 MIME-Version: 1.0 Content-Type: text/plain Dimitri, if for any reason (possibly on based on other comments from IESG) you are going to do another rev, can you pls check the below comments and see if some additional editorial changes make sense? By the way, you can see that Harald also noted the "many Work in Progress" documents that are listed as normative references. Thanks, Bert -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: zaterdag 26 april 2003 18:03 To: IESG Secretary; Internet Engineering Steering Group Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-architecture - Generalized Multi-Protocol Label Switching Architecture to Proposed Standard Harald Alvestrand has no Objection. note: this does not mean that I like it..... In particular, I don't like the fact that the document can't decide whether it's an architecture, an introduction or a specification. It goes into lots of details that are ALMOST specified, but then just says that these are "finished elsewhere" - sometimes giving, sometimes not giving, the forward pointers. It's just about right (although overly detailed, and lacking some pointers to where the "real spec" is) for an introduction. It also *contains* an architecture description - the idea of a control plane that is a fully connected IP network (with, apparently, manual link configuration), a set of links that are not necessarily the control links, and in many cases not even IP-capable links, and groupings of these that can be manipulated and controlled in various ways, and a set of protocols and ways to use those protocols that are defined in other documents. But the lenght and the level of detail means that it's very hard for me to be sure I have grasped that architecture correctly and fully. And - note - I have said nothing about whether or not I *like* that architecture. Note: It will be a while before this is published as an RFC. There are no less than thirteen "works in progress" in its normative references. Harald Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 May 2003 12:39:22 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155018B8832@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Cc: "Thomas Narten (E-mail)" , "Erik Nordmark (E-mail)" Subject: RE: draft-ietf-ccamp-gmpls-architecture-06.txt Date: Wed, 7 May 2003 14:36:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" During IESG review, Thomas/Erik both have raised the question that this doc had so many normative references that seem to be "Work in Progress". So I have checked and found the below. Summary: - Would be good to have the doc names spelled out, so that reviewers (and RFC-Editor) can quickly find the normative ref. - Would be good to change [SOME-DOC-NAME] to [RFCxxxx] if an RFC is already published. Would be more consistent with other RFCs that are being referenced, and makes it easier to see which docs are already published - We have some 5 docs in WGs still and it is not clear how quick they will come out - We have some 4 or 5 that are in various stages of IESG review and seem to need work. So it looks, that when we approve this and put it in RFCed queue, it will probably hang in that queue for a long time. WG and WG chairs, what do you want to do about that? ---- status of various normative references -- Here are the WiP docs that are normative and the status as I fas as I could determine (updates from WG chairs will be appreciated): [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in MPLS Traffic Engineering," Work in Progress. This is: draft-ietf-mpls-bundle-04.txt in RFCed queue [CR-LDP-UNNUM] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling Unnumbered Links in CR-LDP," Work in Progress. Published as RFC3480 [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., "Generalized MPLS Recovery Functional Specification," Work in Progress. This is: draft-ietf-ccamp-gmpls-recovery-functional-00.txt Not sure where this stands in WG [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling Extensions for G.709 Optical Transport Networks Control," Work in progress. This is: draft-ietf-ccamp-gmpls-g709-03.txt Not sure where this stands in WG [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the Overlay Model," Work in Progress. This is: draft-ietf-ccamp-gmpls-overlay-01.txt Still in WG (did not get much content discussion yet, but yet it seems WG chairs want to do WG Last Call) [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS," Work in Progress. This is: draft-ietf-ccamp-gmpls-routing-05.txt Went through IETF Last Call. Quite some comments. Is back in WG to address comments (been there for a while in fact. Wg chairs did not ye responde to my repeated pinging on status). [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., "Generalized MPLS Extensions for SONET and SDH Control," Work in progress. This is: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt Is in RFCed queue [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE," Work in Progress. This is: draft-ietf-mpls-lsp-hierarchy-08.txt Is in RFCed queue [LMP] J.P.Lang (Editor) et al., "Link Management Protocol (LMP)," Work in progress. This is: draft-ietf-ccamp-lmp-08.txt Is in IESG evaluation. Has some DISCUSSes though. [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for WDM Optical Line Systems (LMP-WDM)," Work in progress. This is: draft-ietf-ccamp-lmp-wdm-02.txt In: AD-Evaluation, revised ID needed [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions in Support of Generalized MPLS," Work in Progress. This is: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt This had serious OETF Last Call comments, to be addressed by WG/authors [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic Engineering Extensions to OSPF", Work in Progress. This is: draft-katz-yeung-ospf-traffic-09.txt IESG evaluation, point raised Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 May 2003 14:30:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Mon, 5 May 2003 09:26:28 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A6791@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMRrwKabjUkSMvZS0izeIjdoWEOTwBYK60Q From: "Ash, Gerald R (Jerry), ALABS" To: "Yangguang Xu" Cc: , "Ash, Gerald R (Jerry), ALABS" , "Kireeti Kompella" , "Brungard, Deborah A, ALABS" Yangguang, > > SPC is required by ASON, it was included in the first=20 > > Recommendation on Requirements for the Automatic Switched=20 > > Transport Networks (G.807 published in 2001). For operators,=20 > > SPC support is considered as a critical application for ASON.=20 > > Until UNI/E-NNI support functionality is available (e.g.=20 > > billing systems/directory services), this will likely be the=20 > > first application for most operators of ASON. For example,=20 > > in ITU-T Rec'd G.7713.1 on ASON PNNI (consented January=20 > > 2003), it is only concerned with specifying soft permanent=20 > > connections. > I wasn't challenge SPC at all. I was just wondering the first=20 > requirement to GMPLS signaling in the draft is necessary.=20 > Because I know two solutions don't do that but can still=20 > provide full SPC service well. The 'first requirement' is for SPC, and as I pointed out is a MUST = requirement for ASON (see the summary of ASON requirements/'identified = gaps' at http://ietf.org/proceedings/02mar/slides/ccamp-4/sld005.htm.) > > Again, ASON requirements/'identified gaps' include=20 > > crankback as a MUST, inter-domain and intra-domain. It is=20 > > already included in G.7713.1 and G.7713.3. More information=20 > > on crankback is available in the draft=20 > > = http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt. > SPC is a service. Yet crankback is a mechanism. Not sure why=20 > requirement wants to enforce a mechanism/solution. I think they're both mechanisms that could possibly support a service. = The ASON requirements draft is identifying delta requirements in terms = of the GMPLS protocol capabilities, not necessarily limited to services. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 May 2003 20:03:52 +0000 Message-ID: <3EB42073.5D8791F2@lucent.com> Date: Sat, 03 May 2003 16:02:59 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" CC: ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry, > SPC is required by ASON, it was included in the first Recommendation on Requirements for the Automatic Switched Transport Networks (G.807 published in 2001). For operators, SPC support is considered as a critical application for ASON. Until UNI/E-NNI support functionality is available (e.g. billing systems/directory services), this will likely be the first application for most operators of ASON. For example, in ITU-T Rec'd G.7713.1 on ASON PNNI (consented January 2003), it is only concerned with specifying soft permanent connections. > I wasn't challenge SPC at all. I was just wondering the first requirement to GMPLS signaling in the draft is necessary. Because I know two solutions don't do that but can still provide full SPC service well. > > Again, ASON requirements/'identified gaps' include crankback as a MUST, inter-domain and inter-domain. It is already included in G.7713.1 and G.7713.3. More information on crankback is available in the draft http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt. > SPC is a service. Yet crankback is a mechanism. Not sure why requirement wants to enforce a mechanism/solution. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 May 2003 18:16:52 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON reqts Date: Sat, 3 May 2003 13:15:20 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A70C2@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON reqts Thread-Index: AcMRdkNzrtrUVOPATBO9RMEHwhoIRQAJUf+g From: "Ash, Gerald R (Jerry), ALABS" To: "Yangguang Xu" Cc: "Ash, Gerald R (Jerry), ALABS" , "Kireeti Kompella" , "Brungard, Deborah A, ALABS" , Yangguang, > Woke up too early. Thought reading this document may put me=20 > back to sleep, well, it didn't :-) So nice work, just some=20 > clarifications: >=20 > -- Support for SPC.=20 > I understand SPC but don't think the first requirement to=20 > GMPLS signaling is MUST. It depends on implementation, doesn't it? See the ASON requirements summary ('identified gaps') presented by ITU-T = (Steve Trowbridge) to CCAMP at IETF-53 (March 2002) = http://ietf.org/proceedings/02mar/slides/ccamp-4/sld005.htm. Note the = inclusion of SPC and crankback, both are MUST. SPC is required by ASON, it was included in the first Recommendation on = Requirements for the Automatic Switched Transport Networks (G.807 = published in 2001). For operators, SPC support is considered as a = critical application for ASON. Until UNI/E-NNI support functionality is = available (e.g. billing systems/directory services), this will likely be = the first application for most operators of ASON. For example, in ITU-T = Rec'd G.7713.1 on ASON PNNI (consented January 2003), it is only = concerned with specifying soft permanent connections. =20 > -- Support for crankback.=20 > I think we may want to separate fault localization and crankback,=20 > as the former may be more desirable. Also, not a big fan of=20 > crankback, I'd like to know more details about the crankback=20 > requirement. For example, is crankback a must or optional? is=20 > crankback a must at inter-domain interface or also a must at > intra-domain interface? (I hope requirement only document=20 > what must be done) Again, ASON requirements/'identified gaps' include crankback as a MUST, = inter-domain and inter-domain. It is already included in G.7713.1 and = G.7713.3. More information on crankback is available in the draft = http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt. Thanks, Jerry >=20 > That what I have so far. >=20 > Regards, >=20 > Yangguang =20 >=20 > Kireeti Kompella wrote: > >=20 > > On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote: > >=20 > > >=20 > = http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-= reqts-00.txt >=20 > To take things one at a time, it would be very useful to read and = comment > on the ASON reqts draft, as this was deemed tremendously important, = and > a rich source of misunderstanding and cross-talk; and coming to a = common > understanding over this should help get the IETF and the ITU working > together. >=20 > I think it would be very useful to progress this document in a timely > fashion, so I encourage folks to read and comment on it; and perhaps > in a week or two, to check for consensus to progress it. >=20 > > Good reading material for a weekend - >=20 > Agreed, for both documents. >=20 > Thanks, Deborah! >=20 > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 May 2003 13:15:50 +0000 Message-ID: <3EB3C09C.E89F3CA2@lucent.com> Date: Sat, 03 May 2003 09:14:04 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: "Brungard, Deborah A, ALABS" , ccamp@ops.ietf.org Subject: Re: ASON reqts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Woke up too early. Thought reading this document may put me back to sleep, well, it didn't :-) So nice work, just some clarifications: -- Support for SPC. I understand SPC but don't think the first requirement to GMPLS signaling is MUST. It depends on implementation, doesn't it? -- Support for crankback. I think we may want to separate fault localization and crankback, as the former may be more desirable. Also, not a big fan of crankback, I'd like to know more details about the crankback requirement. For example, is crankback a must or optional? is crankback a must at inter-domain interface or also a must at intra-domain interface? (I hope requirement only document what must be done) That what I have so far. Regards, Yangguang Kireeti Kompella wrote: > > On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote: > > > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt > > To take things one at a time, it would be very useful to read and comment > on the ASON reqts draft, as this was deemed tremendously important, and > a rich source of misunderstanding and cross-talk; and coming to a common > understanding over this should help get the IETF and the ITU working > together. > > I think it would be very useful to progress this document in a timely > fashion, so I encourage folks to read and comment on it; and perhaps > in a week or two, to check for consensus to progress it. > > > Good reading material for a weekend - > > Agreed, for both documents. > > Thanks, Deborah! > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 03 May 2003 01:20:38 +0000 Date: Fri, 2 May 2003 17:51:23 -0700 (PDT) From: Kireeti Kompella To: "Brungard, Deborah A, ALABS" cc: ccamp@ops.ietf.org Subject: ASON reqts Message-ID: <20030502174445.K22049@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 May 2003, Brungard, Deborah A, ALABS wrote: > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt To take things one at a time, it would be very useful to read and comment on the ASON reqts draft, as this was deemed tremendously important, and a rich source of misunderstanding and cross-talk; and coming to a common understanding over this should help get the IETF and the ITU working together. I think it would be very useful to progress this document in a timely fashion, so I encourage folks to read and comment on it; and perhaps in a week or two, to check for consensus to progress it. > Good reading material for a weekend - Agreed, for both documents. Thanks, Deborah! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 May 2003 19:33:14 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt Date: Fri, 2 May 2003 15:29:30 -0400 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA69F@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt Thread-Index: AcMOXEajh5wFgS80QJ6PmDK2Abvw7gCgst+g From: "Brungard, Deborah A, ALABS" To: All, We would appreciate any comments on the following draft to progress, and = also the previous draft on the requirements: http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-= reqts-00.txt Good reading material for a weekend - Deborah -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 29, 2003 7:40 AM Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network = (ASON) Author(s) : J. Drake, D. Papadimitriou et al. Filename : draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt Pages : 27 Date : 2003-4-28 =09 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-aso= n-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 May 2003 11:18:44 +0000 Message-ID: <000001c30fbe$27b6cc40$044aa8c0@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: "Jonathan Lang" To: "'Wijnen, Bert \(Bert\)'" , "'Ccamp-wg \(E-mail\)'" Subject: RE: draft-ietf-ccamp-lmp-08.txt Date: Thu, 1 May 2003 01:46:27 -0700 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Bert, Thanks for relaying these comments. We will address the comments and nits as you suggest. Thanks, Jonathan -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Wednesday, April 30, 2003 9:03 PM To: Ccamp-wg (E-mail) Subject: FW: draft-ietf-ccamp-lmp-08.txt Yet more IESG comments... I think this is the last set. I propose that the editors take a look at this and other IESG comments. See what we can do about the more serious things (DISCUSS stuff) and while they are at it, include clarifications for as many of the notes/nits as possible. Thanks, Bert -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: woensdag 30 april 2003 3:32 To: iesg@ietf.org; iesg-secretary@ietf.org Subject: draft-ietf-ccamp-lmp-08.txt DISCUSS In section 3.2.1, there is a recommendation for setting the default values for the HelloInterval to 150ms and the HelloDeadInterval to 500ms. The text seems to indicate that the same default is used when you pass the traffic over an IP network as when you are directly connected. This seems low in the presence of a multi-hop IP network, as you seem likely to end up in Degraded state unnecessarily. Language indicating how to judge a deviation from this default would be very useful. The draft does not seem to be clear on what happens if a TestStatusSuccess or TestStatusFailure message is lost in flight; the current language could be read to indicate that the same TestStatusAck message would be sent in both cases (5.0, just above 5.1) In section 8, Graceful Restart, it is not clear whether Multicast discovery is re-done on interfaces which have had Interface_Ids discovered through that method, or whether these are also assumed to remain stable. In section 12.1, how are bits which are currently reserved later assigned? Notes: In the introduction, paragraph 2 the use of "neighboring" is non-trivially different from the usual, so defining it would be a good idea. The first SHOULD occurs before the Terminology definition. In LMP overview the statement "All LMP packest are run over UDP with an LMP port number [except in some cases]" would be better if "Except in for test messages, which may be limited by the transport mechanism to in-band messaging, all LMP..." In section 3. there is a requirement for a unique 32-bit non-zero integer, but no specification for how to ensure uniqueness. In Section 3.0, is a unicast source address used for the multicast packet? In section 3.1, the nodes MAY continue to retransmit Config messages both when Node_Ids are equal and when a ConfigNack with unacceptable alternate values is received. Some justification for *why*it would seems useful. In Section 3.2.1, it notes that "if other methods are used to indicate bi-directional control channel connectivity", but there are no pointers to other methods; if none are currently specified, it might be useful to change the language to indicate that. Is the Verify_Id monotonically increasing, or random? In 6.0, "procedure can be used to rapidly isolate link failures" seems to mean data link failures, and it might be better to be more precise. In Section 7, the statement "Note that the 32-bit Message_Id value MAY wrap" does not need an RFC 2119 MAY, since it is a statement of fact, not an interoperability point. In 11.3.1, there is a ligatured ae in the text for Down: Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 May 2003 04:05:36 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C11AE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-lmp-08.txt Date: Thu, 1 May 2003 06:03:18 +0200 MIME-Version: 1.0 Content-Type: text/plain Yet more IESG comments... I think this is the last set. I propose that the editors take a look at this and other IESG comments. See what we can do about the more serious things (DISCUSS stuff) and while they are at it, include clarifications for as many of the notes/nits as possible. Thanks, Bert -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: woensdag 30 april 2003 3:32 To: iesg@ietf.org; iesg-secretary@ietf.org Subject: draft-ietf-ccamp-lmp-08.txt DISCUSS In section 3.2.1, there is a recommendation for setting the default values for the HelloInterval to 150ms and the HelloDeadInterval to 500ms. The text seems to indicate that the same default is used when you pass the traffic over an IP network as when you are directly connected. This seems low in the presence of a multi-hop IP network, as you seem likely to end up in Degraded state unnecessarily. Language indicating how to judge a deviation from this default would be very useful. The draft does not seem to be clear on what happens if a TestStatusSuccess or TestStatusFailure message is lost in flight; the current language could be read to indicate that the same TestStatusAck message would be sent in both cases (5.0, just above 5.1) In section 8, Graceful Restart, it is not clear whether Multicast discovery is re-done on interfaces which have had Interface_Ids discovered through that method, or whether these are also assumed to remain stable. In section 12.1, how are bits which are currently reserved later assigned? Notes: In the introduction, paragraph 2 the use of "neighboring" is non-trivially different from the usual, so defining it would be a good idea. The first SHOULD occurs before the Terminology definition. In LMP overview the statement "All LMP packest are run over UDP with an LMP port number [except in some cases]" would be better if "Except in for test messages, which may be limited by the transport mechanism to in-band messaging, all LMP..." In section 3. there is a requirement for a unique 32-bit non-zero integer, but no specification for how to ensure uniqueness. In Section 3.0, is a unicast source address used for the multicast packet? In section 3.1, the nodes MAY continue to retransmit Config messages both when Node_Ids are equal and when a ConfigNack with unacceptable alternate values is received. Some justification for *why*it would seems useful. In Section 3.2.1, it notes that "if other methods are used to indicate bi-directional control channel connectivity", but there are no pointers to other methods; if none are currently specified, it might be useful to change the language to indicate that. Is the Verify_Id monotonically increasing, or random? In 6.0, "procedure can be used to rapidly isolate link failures" seems to mean data link failures, and it might be better to be more precise. In Section 7, the statement "Note that the 32-bit Message_Id value MAY wrap" does not need an RFC 2119 MAY, since it is a statement of fact, not an interoperability point. In 11.3.1, there is a ligatured ae in the text for Down: Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 May 2003 03:42:15 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C11AD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Cc: "Steve Bellovin (E-mail)" Subject: FW: draft-ietf-ccamp-lmp-08.txt Date: Thu, 1 May 2003 05:38:24 +0200 MIME-Version: 1.0 Content-Type: text/plain More IESG feedback. Although it comes from Erik, Steve is the IESG member that has picked up this item to make sure we get a proper resolution. Thanks, Bert -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: woensdag 30 april 2003 18:45 To: iesg-secretary@ietf.org Cc: iesg@ietf.org Subject: draft-ietf-ccamp-lmp-08.txt I didn't see anything about autorization/access control in the document. Presumably there is something an implementation needs to do to associate authority for certain TE links with a particular IPsec SA. Nit: In two places it explicitly talks about 224.0.0.1 even though the document supports IPv6 for example: the control channel. This is done by sending the Config message to the Multicast address (224.0.0.1). The ConfigAck and ConfigNack How about at least saying "224.0.0.1 or ff02::1" instead. Erik