From extest-admin@lists.bell-labs.com Fri Aug 1 05:00:23 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03153 for ; Fri, 1 Aug 2003 05:00:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7190fj02214 for ; Fri, 1 Aug 2003 05:00:41 -0400 Date: Fri, 1 Aug 2003 05:00:41 -0400 Message-Id: <200308010900.h7190fj02214@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: ipo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ip-optical-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for ipo-archive@lists.ietf.org: List Password // URL ---- -------- ip-optical@lists.bell-labs.com archive http://lists.bell-labs.com/mailman/options/ip-optical/ipo-archive%40lists.ietf.org From ip-optical-admin@lists.bell-labs.com Thu Aug 7 17:18:10 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03401 for ; Thu, 7 Aug 2003 17:18:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h77LFKj14861; Thu, 7 Aug 2003 17:15:20 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h77LEZj14842 for ; Thu, 7 Aug 2003 17:14:35 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h77LEJHa076849 for ; Thu, 7 Aug 2003 17:14:19 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 63DC1443A5; Thu, 7 Aug 2003 17:14:14 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 35C6F443A4 for ; Thu, 7 Aug 2003 17:14:14 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h77LEC1u082280 for ; Thu, 7 Aug 2003 17:14:12 -0400 (EDT) Received: from relay1.alcatel.be (alc240.alcatel.be [195.207.101.240]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h77LHio5070516 for ; Thu, 7 Aug 2003 17:17:44 -0400 (EDT) Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay1.alcatel.be (8.12.9/8.11.4) with ESMTP id h77LDse0003199; Thu, 7 Aug 2003 23:13:54 +0200 (MEST) Received: from alcatel.be ([138.203.67.40]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003080723135374:2 ; Thu, 7 Aug 2003 23:13:53 +0200 Message-ID: <3F32C118.5030200@alcatel.be> From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Alex Zinin'" Cc: John Drake , ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements References: <9D42C6E086250248810DCADA39CE7EFC972676@nimbus> In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC972676@nimbus> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/07/2003 23:13:53, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/07/2003 23:13:55, Serialize complete at 08/07/2003 23:13:55 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 07 Aug 2003 23:14:00 +0200 Content-Transfer-Encoding: 7bit alex, all, if this i-d is progressed then real significant improvement on the content (and its consolidation) is to be expected here (and this without saying from an *ietf perspective*) imho as it stands now it does not help the developer community to understand the real functional/operational needs of the user community by reproducing pieces found here and there in other organization's repositories (it really mixes several dimensions altogether from modeling until system design aspects thus not serving any particular purpose - this is probably due to the several shifts this i-d has pass through since the london'01 meeting) in any case the following are my major concerns on this i-d: (1) Section 1.3 " This document is intended to be protocol-neutral, but the specific goals include providing the requirements to guide the control protocol development and enhancement within IETF in terms of reuse of IP-centric control protocols in the optical transport network." => the above sentence is unclear, i think the first part of the sentence means "requirements on functions to be delivered for controlling optical networks are intentionally provided independently of their actual protocol implementation" or something like this since strictly speaking it is impossible to be simultaneously protocol neutral and IP-centric in my view. (2) Section 1.3 "The Optical Internetworking Forum (OIF) carrier group has developed a comprehensive set of control plane requirements for both UNI and NNI [oif-carrier, oif-nnireq] and they have been used as the base line input to this document." => OIF being an implementation agreement body it is really questionable if these requirements weren't oriented to specific implementation issues and thus opposed to the above statement (on implementation neutrality) (3) Section 1.3 "This document provides further detailed requirements based on the ASTN/ASON framework." => ASTN is a meta-model, a model that includes using the itu terminology any connection oriented packet switching and circuit switching technology, this document should focus on ASON (focusing on optical switching technologies) since afaik the focus is on "IPO" here (4) Section 4.1 "The separation of control, management and transport function is required and it shall accommodate both logical and physical level separation." => clarification would be appreciated on what "logical level separation" means for "transport function" (5) Section 4.2 "The call control shall be provided at an ingress port or gateway port to the network such as UNI and E-NNI [see Section 6 for definition]." => some operators ask us to deliver this capability at the intra-domain level also, and the relationship with the port is unclear (here, clarifications would be more than appreciated) (6) 6.2. Control Domains and Interfaces "A generic carrier network reference model describes a multi-carrier network environment. Each individual carrier network can be further partitioned into sub-networks or administrative domains based on administrative, technological or architectural reasons." => the second sentence should clarify the relationship between partitioning into subnetworks and administrative domain "The demarcation between domains can be either logical or physical and consists of a set of reference points identifiable in the optical network." => the demarcation is logical by definition since discussing here control plane aspects (i.e. these reference points aren't related to the transport plane capabilities but to the control plane) "Figure.1" => it should be mentioned that illustrates one possible usage of these demarcation points and does not constitute a reference model a control domain does not have necessarily a one-to-one mapping with a given subnetwork (example dom B with a single sub-network) "An example of fully trusted interface is an I-NNI between two optical network elements in a single control domain." => a confusing example to be rephrased as "between two single control components (or simply controllers) ..." (7) Section 6.3.1 "It may be the result of using hierarchical layering, different technologies across access, metro and long haul (as discussed below), or a result of business mergers and acquisitions or incremental optical network technology deployment by the carrier using different vendors or technologies." => hierarchical layer stands then at the transport plane level, this should be clarified here (and as such expectations from the control plane perspective aren't clear) (8) Section 7.2 "All the bearer interfaces implemented in the ONE shall be supported by the control plane and associated signaling protocols." => there is a mismatch here, ONE should be replaced by control plane component "- Passive Optical Network (PON) based on ATM (APON) and Ethernet (EPON)" => not sure that in the scope of ASON (first time i heard about E/A/PON in the ASON context) (9) Section 7.3 "- The UNI shall support initial registration and updates of the client with the network via the control plane." => the word "registration" deserve some clarification here (9) Section 8.1 "For the signaled, either direct or indirect signaling methods can be used depending upon if the UNI proxy is utilized on the client side. The detailed discussion on the UNI signaling methods is in [oif-uni]." => being an implementation specific agreement, i don't understand the above reference wrt to the scope of this document (being stated as "implementation neutral") (10) Section 8.4.1 "- Transport Network Assigned (TNA) address: This is a routable address in the optical transport network and is assigned by the network." => TNA's has been defined at the OIF as an "enveloppe" to carry IPv4/ IPv6 and NSAP's - from this perspective nothing is provided to assess the need of such capability - (some claims that TNA's are names that are associated to TE Link numbered/unnumbered Id's & in such a case this address space is not a routable address space on the other side some are currently working on re-defining TNA's as TE Link addresses) but more importantly there is no evidence at all that there is any operational need for having an IP-based control plane that is capable to process NSAP's -> thus seriously questioning the reason for the introduction of this concept (in particular from an ietf perpective) (11) Section 8.4.2. "The directory service is essential for the implementation of overlay model." => seems like an assertion, overlay models can be implemented without any directory service (clarification on the directory service req's is more than appreciated) (12) Section 9.2 "The UNI control channel and proxy signaling defined in the OIF UNI 1.0 [oif-uni] shall be supported." => same remark as above concerning a reference to an implementation specific agreement (13) Section 9.3 "Data plane shall monitor and detect the failure (LOL, LOS, etc.) and quality degradation (high BER, etc.) of the signals and be able to provide signal-failure and signal-degrade alarms to the control plane accordingly to trigger proper mitigation actions in the control plane." => provide references since strictly speaking outside of the scope of both ASON control plane and also IPO WG requirements (14) Section 10.1 "Address resolution exchange over UNI is needed if an addressing directory service is not available." => this is quite confusing here "address resolution" between what and what ? (15) Section 10.2 "- The inter-domain signaling protocol shall be agnostic to the intra- domain signaling protocol for all the domains within the network." => the term agnostic should be clarified here (if this meant to say intra-domain signalling can be proprietary then better explain exactly that "interworking function between standard and proprietary protocols running at the intra-domain level shall be stictly confined at this level i.e. without impacting the standard inter- domain signalling protocol behaviour") (16) Section 10.3 "All three mechanisms (Hop-by-hop routing, explicit / source-based routing and hierarchical routing) must be supported." => does routing mean signalling here (hop-by-hop, source-based) ? and what hierarchical routing means in that context ? "- The exchange of the following types of information shall be supported by inter-domain routing protocols: - Inter-domain topology - Per-domain topology abstraction" => would be of interest to have a bit more information on what is expected with "inter-domain topology" concerning the second point is there any relevant reference that may help in defining "per-domain topology abstraction" - also it has been mentioned in Section 10.1 "Topology information shall not be exchanged across inter-carrier E-NNI and UNI." would it be possible to achieve consistance among these requirements ? "The routing protocol shall be able to support different levels of protection/restoration and other resiliency requirements. These are discussed in Section 11." => independently of the content of the Section 11 the first sentence is quite confusing what does "routing protocol protection/restoration" really means ? and what's expected ? (17) Section 10.4 "- Path selection algorithms shall provide carriers the ability to support a wide range of services and multiple levels of service classes. Parameters such as service type, transparency, bandwidth, latency, bit error rate, etc. may be relevant." => what latency means in the scope of "path selection" algorithms "Constraint-based routing in the optical network in significantly complex Compared to the IP network. There are many optical layer constraints to consider such as wavelength, diversity, optical layer impairments, etc. A detailed discussion on the routing constraints at the optical layer is in [ietf-olr]." => this said "optical layer impairments" such as described in [IETF-OLR] is not currently in the scope of the ITU ASON work (18) Section 10.5.1 "- Physical media adjacency that detects and verifies the physical layer network connectivity between two connected network element ports." => wise to clarify here what is expected from the control plane perspective here (19) Section 11.2 "The control plane failure shall only impact the capability to provision new services." => services meaning connections ? "Recovery from control plane failures shall result in complete recovery and re-synchronization of the network." => why recovery should impact the *whole* network is this requirement not in contradiction with robustness ? "There shall not be a single point of failure in the control plane systems design." => this is an implementation specific requirement (since "system design" is mentioned here) "Partial or total failure of the control plane shall not affect the existing established connections. It should only lose the capability to accept the new connection requests." => the second sentence is confusing in case of total failure of the control plane none of the control plane function will be accessible so not sure this is the only capability that will be lost (20) Section 12.1.1 "For enhancing integrity and confidentiality of data, it may be helpful to support scrambling of data at layer 2 or encryption of data at a higher layer." => is this really something that should be controlled by the ASON control plane ? ----- John Drake wrote: > Alex, > > I read this draft several months ago and I would agree with your > characterization of it. As such, it doesn't seem to serve any particular > purpose. > > Thanks, > > John > > >>-----Original Message----- >>From: Alex Zinin [mailto:zinin@psg.com] >>Sent: Friday, July 25, 2003 2:06 PM >>To: ip-optical@lists.bell-labs.com >>Subject: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements >> >> >>Folks- >> >> After reading the document, I was left with the feeling that it is >> not clear to me whether the document is simply a recompilation of the >> material found in other organizations (such as OIF and ITU), or >> something unique for the IETF. I asked several individual reviewers >> to read the document and give me their opinions. All of them >> mentioned similar concerns and indicated that the document should not >> go forward. >> >> Before I can take the document to the IESG, I need to make sure it >> represents wide consensus within the SUB-IP community and the WG in >> particular. With this in mind, I would like to ask the WG chairs to >> initiate another 2-week WG Last Call. I would also like the WG >> participants to express their opinion on the document, and >> specifically their support of the document going forward, and the >> reasons why (if at all) they believe the document would be useful >> with its current contents. Please make sure you've read the latest >> version of the draft. >> >> Regards >> >>-- >>Alex Zinin >>IETF SUB-IP Area co-Director >> >>_______________________________________________ >>IP-Optical mailing list >>IP-Optical@lists.bell-labs.com >>http://lists.bell-labs.com/mailman/listinfo/ip-optical >> > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- 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 _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From ip-optical-admin@lists.bell-labs.com Sat Aug 9 18:48:43 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09952 for ; Sat, 9 Aug 2003 18:48:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h79Ml6j32761; Sat, 9 Aug 2003 18:47:07 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h79Mkbj32747 for ; Sat, 9 Aug 2003 18:46:37 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h79MkLHa094715 for ; Sat, 9 Aug 2003 18:46:21 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 371E6443A5; Sat, 9 Aug 2003 18:46:16 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0E34A443A4 for ; Sat, 9 Aug 2003 18:46:16 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h79MkDF2067251 for ; Sat, 9 Aug 2003 18:46:13 -0400 (EDT) Received: from lakemtao03.cox.net (lakemtao03.cox.net [68.1.17.242]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h79Mngo5004031 for ; Sat, 9 Aug 2003 18:49:42 -0400 (EDT) Received: from LTPC01DELL ([68.98.160.63]) by lakemtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030809224606.OXC23518.lakemtao03.cox.net@LTPC01DELL>; Sat, 9 Aug 2003 18:46:06 -0400 Reply-To: From: "Yong Xue" To: "'Xue, Yong'" , Cc: , , , , Subject: RE: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements Message-ID: <003001c35ec8$1e4f4ed0$b07ba8c0@LTPC01DELL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 9 Aug 2003 18:46:47 -0400 Content-Transfer-Encoding: 7bit -----Original Message----- From: Xue, Yong [mailto:XueY@ncr.disa.mil] Sent: Friday, August 08, 2003 3:35 PM To: 'zinin@psg.com' Cc: 'ip-optical-admin@lists.bell-labs.com'; 'yxue@cox.net'; 'james_luciani@mindspring.com'; 'bwijnen@lucent.com'; 'awduche@isocore.com' Subject: RE: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements Alex and IP-Optical WG As the editor of the "Optical Service Requirements" Draft RFC document, I have collected some input from the authors of this document and want share them with you and the IP-Optical WG community. 1. We disagree with your and other's comments that this document is simply a recompilation of the contents from OIF and ITU. Most authors of this document are active participants and contributors of those requirements in both OIF and ITU. One of the initial objectives was to bring the carrier-driven requirements developed in OIF and ITU into IETF to help IETF/IPO community understand the carrier's needs (remember IETF and OIF/ITU did not have formal liaison relationship at the time this document was started). It also contains fair amount of the contents that are unique to this document. 2. This document was initiated by the IPO WG chairs to ask a group of people form major carriers to provide optical service requirements for IP layer, and we did that and more. However, we did not receive much constructive suggestion as to the suitability of the direction and contents of the document during past two years. If the problem was seen, it should have been brought to our attention earlier, not now. 3. This doc was intended to be an informational RFC and tried to reflect the major high-level functional requirements and architectural framework envisioned by the carrier community for the intelligent optical transport network relative to IP and other service networks. Those requirements are currently refined at OIF and ITU, a consolidated high level requirements combining ITU ASON, OIF NNI and UNI, and IP over Optical specific requirements will certainly be a good value this document can bring. 4. For all practical purpose, we see the following options for the document - Keep the existing scope, but clean up the document and incorporate the latest requirement development in OIF and ITU by carriers to improve the doc quality and move forward. Keep the document as a high-level document. - Reduce the scope of the document and expect major rewrite to focus on the detailed IP over Optical requirements. - Drop the document since it's not in the best interest of all the authors and others if it lacks the interest and support from IPO WG. 5. Appreciate Dimitri Papadimitriou's spending time to provide specific comments on the document. We will address all his comments and concerns if it is decided to progress the document. -Yong _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From ip-optical-admin@lists.bell-labs.com Sun Aug 10 06:31:08 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03296 for ; Sun, 10 Aug 2003 06:31:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7AAT4j08820; Sun, 10 Aug 2003 06:29:04 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7AASBj08801 for ; Sun, 10 Aug 2003 06:28:11 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AARuHa097584 for ; Sun, 10 Aug 2003 06:27:56 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id CE9E0443A5; Sun, 10 Aug 2003 06:27:50 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id A2FE9443A4 for ; Sun, 10 Aug 2003 06:27:50 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AARmF2090518 for ; Sun, 10 Aug 2003 06:27:48 -0400 (EDT) Received: from relay1.alcatel.be (alc240.alcatel.be [195.207.101.240]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AAVFo5010687 for ; Sun, 10 Aug 2003 06:31:16 -0400 (EDT) Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay1.alcatel.be (8.12.9/8.11.4) with ESMTP id h7AART3C006173 for ; Sun, 10 Aug 2003 12:27:37 +0200 (MEST) Received: from alcatel.be ([138.203.137.2]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003081012272773:992 ; Sun, 10 Aug 2003 12:27:27 +0200 Message-ID: <3F361E0E.8040803@alcatel.be> From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ip-optical@lists.bell-labs.com" Cc: Bala Rajagopalan , james_luciani@mindspring.com, daniel.awduche@mci.com X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/10/2003 12:27:28, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/10/2003 12:27:37, Serialize complete at 08/10/2003 12:27:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Subject: [IP-Optical] concerns on draft-ietf-ipo-framework-04.txt Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 10 Aug 2003 12:27:26 +0200 Content-Transfer-Encoding: 7bit all, there is imho a paradox in this i-d, it states: "The first is the adaptation and reuse of IP control plane protocols within the optical network control plane, irrespective of the types of digital clients that utilize the optical network. " note: the term "adaptation" must be followed by a statement that clearly mentions what it means here - imho it should reflect backward compatibility with proposed standard rfc's - and then it says: "Using a common signaling framework (based on GMPLS) from the beginning facilitates this type of evolution. For the domain services model, implementation agreement based on GMPLS UNI signaling is being developed in the Optical Interworking Forum (OIF) [5, 6]. This agreement is aimed at near term deployment and this could be the precursor to a future peer model architecture." thus without wanting to make any promotion ;-) it makes the apology of the non-GMPLS signaling compliant (ie RFC 3471/2/3) OIF (point-to- point signaling interface) implementation agreement which can not (by definition) be a peer model architecture precursor as defined in the scope of the IETF - it also refers to "near term deployment" taking mid'01 as baseline here what do we have to assume that the OIF UNI lost momentum ? but the most surprising is to come "In this evolution, the signaling capability and semantics at the IP-optical boundary would become more sophisticated, but the basic structure of signaling would remain. This would allow incremental developments as the interconnection model becomes more sophisticated, rather than complete re-development of signaling capabilities." something impossible since the OIF basic "structure of signaling" is not GMPLS compliant from the beginning it will give rise to the complete redevelopment of the (currently available) signaling capabilities when moving to more sophisticated interconnection models ... or does the conditional mode used here wasn't related to the "evolution" but just in case it would remain at its first stage ? thus, i think this i-d doesn't help anymore in detailing the current or any potential evolutionary path since starting from the OIF UNI developments. In particular by mentioning the latter it puts them under real questioning since this framework does not rationalize for any GMPLS RFC bias as currently promoted by OIF, as also reproduced in the following sections: 1. section 5.1.2 is confusing, separating control plane instances does not mandate the definition of brand new protocols as currently inferred by this paragraph 2. nothing in this document justifies the following as stated in the section 5.3.1 "In the case of the domain services model, these protocols can be adapted for UNI signaling as well [5, 6]." in particular (see 5.3.2) "While RSVP-TE and LDP can be adapted for UNI signaling, the full functionality of these protocols will not be used. For example, UNI signaling does not require the specification of explicit routes. On the other hand, based on the service attributes, new objects need to be signaled using these protocols as described in [5, 6]." all these assertions are closely related to the OIF UNI developments but no rationale are given in order to mandatorily do so. hence, would it be possible to reconsider the scope of this document by withdrawing any implicit reference to oif uni developments which are imho outside of the scope of a framework since clearly addressing implementation specific aspects (btw, overlay model does not imply oif uni only the reverse statement is true, the oif uni is only a very particular implementation of the overlay control plane inter- connection model using a non-gmpls compliant p2p signaling interface) 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 _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From ip-optical-admin@lists.bell-labs.com Sun Aug 10 10:45:25 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09036 for ; Sun, 10 Aug 2003 10:45:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7AEi5j10248; Sun, 10 Aug 2003 10:44:05 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7AEhoj10235 for ; Sun, 10 Aug 2003 10:43:50 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AEhYHa098301 for ; Sun, 10 Aug 2003 10:43:34 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 3CA6A443A5; Sun, 10 Aug 2003 10:43:29 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 16709443A4 for ; Sun, 10 Aug 2003 10:43:29 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AEhR1u059839 for ; Sun, 10 Aug 2003 10:43:27 -0400 (EDT) Received: from relay1.alcatel.be (alc240.alcatel.be [195.207.101.240]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7AEkro5047217 for ; Sun, 10 Aug 2003 10:46:54 -0400 (EDT) Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay1.alcatel.be (8.12.9/8.11.4) with ESMTP id h7AEgu3C015308; Sun, 10 Aug 2003 16:42:56 +0200 (MEST) Received: from alcatel.be ([138.203.137.2]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003081016425517:1354 ; Sun, 10 Aug 2003 16:42:55 +0200 Message-ID: <3F3659EB.3050903@alcatel.be> From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: yxue@cox.net Cc: "'Xue, Yong'" , zinin@psg.com, james_luciani@mindspring.com, bwijnen@lucent.com, awduche@isocore.com, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements References: <003001c35ec8$1e4f4ed0$b07ba8c0@LTPC01DELL> In-Reply-To: <003001c35ec8$1e4f4ed0$b07ba8c0@LTPC01DELL> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/10/2003 16:42:55, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/10/2003 16:43:02, Serialize complete at 08/10/2003 16:43:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 10 Aug 2003 16:42:51 +0200 Content-Transfer-Encoding: 7bit hi, see in-line... > Alex and IP-Optical WG > > As the editor of the "Optical Service Requirements" Draft RFC document, I > have collected some input from the authors of this document and want share > them with you and the IP-Optical WG community. > > 1. We disagree with your and other's comments that this document is simply a > recompilation of the contents from OIF and ITU. Most authors of this > document are active participants and contributors of those requirements in > both OIF and ITU. the second statement doesn't strictly speaking justify the first one nor rationalizes it from an ipo wg perspective > One of the initial objectives was to bring the > carrier-driven requirements developed in OIF and ITU into IETF to help > IETF/IPO community understand the carrier's needs (remember IETF and OIF/ITU > did not have formal liaison relationship at the time this document was > started). It also contains fair amount of the contents that are unique to > this document. then one possibility would be to point out to what's really specific compared to existing documents that are available elsewhere, but the scope must be clearly defined browsing from architectural until system design aspects doesn't seem to be the most appropriated way to do so > 2. This document was initiated by the IPO WG chairs to ask a group of people > form major carriers to provide optical service requirements for IP layer, > and we did that and more. be a "major carrier" doesn't give more merits to the technical argumentation (than coming from a "small carrier") here, the arguments are evaluated on their technical merits not from their origin (oif, etc.) or the affiliation of their editor(s) and/or contributor(s) > However, we did not receive much constructive > suggestion as to the suitability of the direction and contents of the > document during past two years. If the problem was seen, it should have been > brought to our attention earlier, not now. the scope of the document has shifted three times since its first version: - san diego'00: operators to define control plane req's under the ipo wg umbrella (as requested by the chairs) - london'01: organised as a list of numbered requirements trying to accommodate/direct ietf developments - and then shift at slc'01 towards the control plane requirements from the itu ason work (note most of this architectural/functional work had been consented by that time at the itu) and oif dvp's difficult to ask to an engineer community to follow your reasoning behind these continuous shifts (it also means that either the scope of the document wasn't well defined from the early beginning or that authors they didn't know what they really wanted from the early beginning) > 3. This doc was intended to be an informational RFC and tried to reflect the > major high-level functional requirements and architectural framework > envisioned by the carrier community for the intelligent optical transport > network relative to IP and other service networks. this statement seems contadictory to the one listed in point 1. > Those requirements are > currently refined at OIF and ITU, a consolidated high level requirements > combining ITU ASON, OIF NNI and UNI, and IP over Optical specific > requirements will certainly be a good value this document can bring. the same applies here. > 4. For all practical purpose, we see the following options for the document > - Keep the existing scope, but clean up the document and incorporate the > latest requirement development in OIF and ITU by carriers to improve the doc > quality and move forward. Keep the document as a high-level document. there is a clear contradiction here b/w "high level" and parts of its current content - how can a document claim to be high level and implementation/protocol neutral while referring to implementation agreements defined by the oif ? - so if it has to progress in that way there is imho an important clean-up & consolidation effort to be provided to make here consistent progress (*) note that this comment doesn't apply only to this ipo i-d (see also previous e-mail) > - Reduce the scope of the document and expect major rewrite to focus on the > detailed IP over Optical requirements. there are several levels of requirements: - architectural/models - service/functional - protocol and related - operational/management/etc. as long as the requirement level to be covered by this i-d is not agreed and clearly defined i don't know how it can really and efficiently progress in becoming useful for this community > - Drop the document since it's not in the best interest of all the authors > and others if it lacks the interest and support from IPO WG. depends on the previous points but if the situation doesn't improve quickly i don't think we will have any other choice > 5. Appreciate Dimitri Papadimitriou's spending time to provide specific > comments on the document. We will address all his comments and concerns if > it is decided to progress the document. thanks. - dimitri. > -Yong > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- 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 _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From ip-optical-admin@lists.bell-labs.com Thu Aug 21 20:17:21 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10614 for ; Thu, 21 Aug 2003 20:17:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7M0FGj03135; Thu, 21 Aug 2003 20:15:18 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7M0Ejj03116 for ; Thu, 21 Aug 2003 20:14:45 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7M0EUHa016810 for ; Thu, 21 Aug 2003 20:14:30 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 6B9E2443A5; Thu, 21 Aug 2003 20:14:25 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 48206443A4 for ; Thu, 21 Aug 2003 20:14:25 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7M0ENF2011997 for ; Thu, 21 Aug 2003 20:14:23 -0400 (EDT) Received: from psg.com (mailnull@psg.com [147.28.0.62]) by dusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7M0HKo5045046 for ; Thu, 21 Aug 2003 20:17:20 -0400 (EDT) Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19pzZN-000F9h-7d for ip-optical@lists.bell-labs.com; Fri, 22 Aug 2003 00:14:21 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4914921946.20030821171311@psg.com> To: ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements In-Reply-To: <3F3659EB.3050903@alcatel.be> References: <003001c35ec8$1e4f4ed0$b07ba8c0@LTPC01DELL> <3F3659EB.3050903@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 21 Aug 2003 17:13:11 -0700 Content-Transfer-Encoding: 7bit Folks- Now that the Last Call is over, my reading of what I've seen on the list is that the document clearly does not have sufficient support of the WG (in fact, I haven't seen any supportive comments except from the authors), and that there clearly are issues with it. Each of these alone would be enough for me to conclude that the document is not ready for publication. As such, I have to return the document back to the WG. I will also follow up with the WG chairs regarding further actions required wrt this document in particular and the WG milestones in general. Alex Zinin IETF Sub-IP Area Co-Director _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From ip-optical-admin@lists.bell-labs.com Thu Aug 28 08:42:49 2003 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09088 for ; Thu, 28 Aug 2003 08:42:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7SCaBj24396; Thu, 28 Aug 2003 08:36:12 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h7SCZkj24383 for ; Thu, 28 Aug 2003 08:35:46 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7SCZUHa089302 for ; Thu, 28 Aug 2003 08:35:30 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id B883B443A5; Thu, 28 Aug 2003 08:35:25 -0400 (EDT) Delivered-To: ip-optical@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 93B68443A4 for ; Thu, 28 Aug 2003 08:35:25 -0400 (EDT) Received: from rusty.research.bell-labs.com (rusty.research.bell-labs.com [135.104.2.5]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7SCZN2e083142 for ; Thu, 28 Aug 2003 08:35:23 -0400 (EDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by rusty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7SCZMaS076524 for ; Thu, 28 Aug 2003 08:35:22 -0400 (EDT) Received: from h-68-166-234-232.cmbrmaor.covad.net ([68.166.234.232] helo=DD22NQ21) by puffin.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 19sLzh-0003C3-00 for ip-optical@lists.bell-labs.com; Thu, 28 Aug 2003 05:35:17 -0700 From: "James Luciani" To: Message-ID: <000801c36d60$d7c64890$0200a8c0@DD22NQ21> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C36D3F.50B4A890" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-ELNK-Trace: 69d359d74ea5b89bb7006832b23cb2bad4c20f6b8d69d888bcc11f909756180461713ea7305a562d6d2d5e4f91a86666350badd9bab72f9c350badd9bab72f9c Subject: [IP-Optical] draft-ietf-ipo-carrier-requirements Sender: ip-optical-admin@lists.bell-labs.com Errors-To: ip-optical-admin@lists.bell-labs.com X-BeenThere: ip-optical@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 28 Aug 2003 08:35:17 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C36D3F.50B4A890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, After significant discussions with the ADs and given the input on draft-ietf-ipo-carrier-requirements to date, we will not be progressing the draft. Thank you very much to the authors who worked on this draft. Your efforts were very much appreciated! --Dan, Jim, Alex, Bert ------=_NextPart_000_0009_01C36D3F.50B4A890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

    After significant discussions with = the ADs and given the input on draft-ietf-ipo-carrier-requirements to date, we = will not be progressing the draft.  Thank you very much to the authors who = worked on this draft.  Your efforts were very much = appreciated!

--Dan, Jim, Alex, Bert

------=_NextPart_000_0009_01C36D3F.50B4A890-- _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical